I'm starting a new project and I'm interested in using Entity Framework. However, since this is a new project, there isn't an existing model or database yet, so I could either use database-first or model-first in this situation.
When starting with a blank slate like this, is it recommended to use model-first and let EF determine the database design or design the database yourself? I'm comfortable designing normalized databases so I'm not afraid of that aspect, but I'm not sure if there are maintainability and performance benefits from letting EF handle all the database design.
Thanks in advance guys!
In a green field project my choice would be code first, or possibly model first. As your project progresses over time you should only be dealing with code and have EF manage database schema changes for you. Using other approaches can lead to moving focus from core activities to model maintenance. On a project I worked on we were coerced by management to use a database created by a dedicated schema developer who only knew how to use SQL Server Management Studio. Therefore every change in database meant we had to regenerate code. This eventually caused us to spend 2 days to develop tooling for automatic importing of DB schema and generation of object model (this was in EF 3.5 days).
I'd leave database first approach for brown field and maintenance projects.
Check out: link1 and link2, then decide it's up to you
Well, as a developer, comfortable with any old way to build databases, I've found that code first lets me concentrate on my task. Your mileage may vary.
I've used it many time and have been able to maintain my databases using code first style without difficulty.
Related
I am currently working on a project where I want to use the Entity Framework
for the first time. I read much information in the books of Lerman/Miller,
in MSDN, the ADO.NET blog and here on stackoverflow about the most recent
developments regarding the DbContext API and the Code First Migrations
capabilities available since EF 4.3.
Since especially the latter are really great, I wondered whether in the meantime
it is possible to do the same working "Model First" centered? Is it possible to
do migrations based on the visual EDMX designer (instead of the code) after
creating the code and the database from it?
I found a pretty recent link (2012-04) saying that it is not (in EF 4.3):
Using EF4 migration tool with model-first approach
Secondly, I found information that old code and database tables are
overwritten when trying to regenerate them from the EDMX designer?
But the info I refer to is about the Power Tools:
http://blogs.msdn.com/b/adonet/archive/2012/04/09/ef-power-tools-beta-2-available.aspx
Reverse Engineer Code First
This command allows one-time generation of Code First mappings for an existing database. [..]
• Running this command multiple times will overwrite any previously generated files, including any changes that have been made to generated files
Is this restriction only specific to the Power Tools Reverse Engineer Code First
or does it expand to the EDMX designer in general, especially the "Model First"
approach, too?
Furthermore, in the above article I found:
View Entity Data Model (Read-only)
Displays the Code First model in the Entity Framework designer.
• This is a read-only representation of the model; you cannot update the Code First model using the designer.
And the same question applies here.
So is there currently a way with full round-trip modelling without data-loss
(code and database) and keeping the EDMX file writable, preferrable following
"Model First"?
From which verson of EF on is this (already or planned to be) supported, which
version of .NET should I target then (4.0 sufficient?) and will this work with
Visual Studio 2010 Professional? Could you give a rough estimate for the date
you may will have implemented this?
This would of course be awesome and a huge breakthrough! I think I can only
roughly imagine how much work this would be and am aware that you are fully
working at your limit already. I want to thank you for your great work so far
and encourage you to keep it up.
If I understand your question correctly you are after Migrations for the EF Designer (i.e. update the model in the designer and have the database incrementally changed). This isn’t currently supported, it is on our backlog to address but we don’t have specific plans for a particular release. One of the things we need to work out is whether we should just integrate/extend the existing Code First Migrations feature to work with the EF Designer or whether we need something that is a bit more designer focused.
Obviously things can change, but at this stage I wouldn’t be expecting us to start working on this feature in the next 6 months. Beyond that it’s going to depend on what features we see folks asking for… so I would create a new feature on http://data.uservoice.com and get folks voting on it.
~Rowan
Because of specifics of my current project, I have to keep using .NET 2.0. Are there any Entity Framework-like ORMs for .NET 2.0?
I'm absolutely OK with non-LINQ interface. Syntax like users.Where(u => u.Age > 100).Count() is fine.
I need to use DB-first approach: I already have a DB with about 30 tables and just considering the ways of simplifying work with it. So, I'd really appreciate if it's possible to generate the required code from existing DB.
It's also OK if it won't generate all the required code but provide the way to describe DB structure manually (using attributes, for instance). Basically, I just want to be able to build more or less sophisticated queries without messing with real SQL, SqlParameters and DataSets/DataTables with all these int.Parse(row[12].ToString()) (that's a legacy code I'm trying to get rid of)
Also, that would be great if I'm be able to "override" some particular "queries" with calls to existing stored procedures.
The most important is p.2 - DB first. Is there anything of this kind? Or am I absolutely wrong with my thoughts? Will appreciate any ideas.
Your best option is to check out NHibernate. Many (most?) people consider consider it more feature complete and powerful than EF 4.1, plus there are plenty of resources here on stackoverflow and the rest of the web to guide your development process.
Be sure to look into Fluent NHibernate to make mapping from your database to C# objects easy. The alternative of editing XML files is complex, clunky, and time consuming.
Note that you might need to use an older, but still completely functional, version of NHibernate that is compatible with .NET 2.0 (I think, but am not positive, that the more recent versions require .NET 3.5).
There is plenty of available ORMs but some of them are commercial (LLBLGen Pro). The good choice for you is probably NHibernate 2.1 (I think NHibernate 3.x requires .NET 3.5).
You should also thing about moving forward to a newer .NET version. Starting a new development on .NET 2.0 should be avoided and involving a new technology to existing old code base IMO spoils application's architecture and maintainability.
Edit:
So, I'd really appreciate if it's possible to generate the required code from existing DB.
The most important is p.2 - DB first.
ORM and code generation are two different areas. DB first doesn't mean code generation - it means mapping to existing database without needs to change the database. It is not point of ORM to generate code for you. The point of ORM is to allow you to map DB to classes and abstract querying. If the most important point for you is code generation you should look for something else then ORM. NHibernate doesn't have such code generation included but there are some additional projects which add similar features.
When Linq-to-Sql was first released, I used it quite a lot for small and medium sized projects where a true multi-tier architecture wasn't required.
NHibernate, Small Middleware, Overkill
Where I work, we now almost exclusively use NHibernate for true Domain Driven development.
I'm working on a small temporary (a lifetime of probably a year, maybe less) middleware component where NHibernate feels slightly overkill in terms of configuration and keeping the entities up to date. Especially because I haven't got any control over the DB, it sometimes changes, and it's a little bit "legacy".
Some changes were recently made to the DB, and the NHibernate mappings are not very complete.
Linq-to-Sql? Or EF?
I thought it might be easier just to rip out the IRepository implementation I have and replace it with a Linq-to-Sql implementation. Then I can just use lambdas for my simple queries, and just drag and drop the tables in.
RAD But Dead?
In this scenario the RAD elements of Linq-to-Sql make sense. But it's essentially old technology. Should I not use it? I've never used the Entity Framework. Should I use that, is it as easy and quick to use?
cheers
Is it still OK to use Linq-to-sql?
Yes. It is OK to use any technology which allows you delivering the product in time, with required functionality and quality. You can still find projects using ASP, ADO, VB6. One reason why Microsoft technologies have very hard time in many international corporations is that their products have very short lifetime. Linq-to-sql was on the market less then 2 years and was deprecated by Microsoft but companies / community argued about that and Microsoft changed their strategy little bit. Linq-to-sql doesn't have new features but it is still supported and a fully functional technology.
Will Linq-to-sql or EF solve your problems?
It depends. Perhaps yes and perhaps no. Don't believe to marketing announcements about RAD. Sometimes I feel that people think that RAD is about designer. No. Tools supporting RAD are about well defined API which is easy to understand, easy to use and doesn't contain unexpected behavior (Principle of least surprise) - you will use the API to quickly prototype the application but it still requires understanding and practice. NHibernate's mapping is still prototyping when you compare it with manually doing whole data access. We can even follow the basic rule of good framework: Easy things are easy to do and hard things are possible. That is something that NHibernate accomplish much better then EF or Linq-to-sql.
If you know NHibernate but you don't have any real world experience with EF or Linq-to-sql, you can be sure that neither Linq-to-sql or EF will increase your productivity in first one or two projects where you use it. If you don't have too much experience with NHibernate changing to EF or Linq-to-sql will probably don't cause temporary lose of productivity.
I also don't think that EF or Linq-to-sql will generally help you in situations where database changes. As I remember Linq-to-sql designer doesn't have update mapping functionality at all and because of that it is very often used completely without designer so you must still manually modify mapping. EF's updating model from database can be helpful here but it is not a silver bullet. Some updates can require manual modification of EDMX file (huge XML).
At last be aware that NHibernate's mapping features are much more powerful especially when working with legacy databases. Linq-to-sql's mapping features are very limited, it is mostly 1:1 mapping of tables to classes with some exceptions (basic TPH inheritance). EF offers more complex mapping features but it somehow expects a correct design of the database.
If you (and your coworkers) are comfortable with NHibernate, then it should be just as RAD as Linq to SQL. There's no reason not to use L2S as long as you understand it's not going to get much in the way of updates and improvements from Microsoft, but in my experience if you know how to use both frameworks already, no need in re-doing the work just because L2S might be a little more RAD
Some good discussion on NHibernate vs L2S/EF
Entity Framework vs LINQ to SQL
MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)
in your specific case, you should go with technology you are most comfortable with. Though Linq2Sql is relatively straight forward - and build right into the language - it does have a slight learning curve and its own set of gotchas!
I was surprised to find a public letter proposing a vote of no confidence in the entity framework (see http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/)
Would the reasons stated in the letter keep you from using the current version of the entity framework? Would you rather wait for v4.0? Or rather use another ORM?
The current version of EF is definitely not perfect, and has lots of gotchas and drawbacks. I probably wouldn't use it right now - but the upgrade path to EF v2 (or is it EF4?) sure looks pretty rosy!
complete persistence ignorance - you can use your straight up POCO classes
deferred loading configurable as an option
much improved designer with support for pluralization/singularization (even in multiple languages!)
ability to do "domain first" design and create database from your model
ability to have self-tracking entities across multiple layers that allow you to send data to the client and get back changes and apply them to your entity context
All in all, EF v2 looks very promising and I'm very eager to give it a serious spin. If it really keeps all the promises out there right now, it's definitely a winner!
Check out the ADO.NET team blog for a flurry of recent blog posts on EF v2.
Marc
Another ORM.
Don't get me wrong you should get flamed with responses, but currently only nHibernate is functionally complete.
I'm a TDD fan, so want an easily testable POCO ORM solution. If that's your bag then EF3.5 is out. EF4.0 is introducing it (http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx) , but it still has at least 1 big drawback -> doesn't support inheritance.
NHibernate is more complete, but EF could be easier to use. As ever, best tool for the job... but if it's an Enterprise-scale TDD developed app, go nHibernate.
Also -> there's a profiler that makes nHibernate dev much easier -> http://www.nhprof.com/
I tried using it for my current project, which basically involves rewriting our current mess of a data layer.
It just doesn't work.
First, if you're trying to base an Entity off of a View, the designer tries to force every NOT NULL property to be an entity key... which is pretty much never what I wanted. To work around that you have to edit the xml in at least two places, and do it every time you add an object because it refreshes and re-adds the EntityKey properties. Must specify mapping for all key properties in Entity Framework?
Second, when you are creating associations you MUST use every entity key - How can you make an association without using all entity keys in entity framework?
Those two things held me up for 3 days, then I went back to Linq to SQL and had it done in a couple hours. (Well, at least the part of the system I was struggling with... ) I don't know if those are in the Vote of No Confidence, but it's just not ready in my opinion.
Also with the lack of answers I got here on every EF question I've asked, I have to assume current usage is so low that getting help and support is going to be difficult... which is possibly the BIGGEST reason not to use something.
Let's hope the next version is better...
EDIT: OUr current plan is to stick with Linq 2 SQL (I have to finish a project by Friday) and then evaluate all the other ORMs to see if anything else is better. The other developer hates L2S for the record, but I've never had any major problems using it...
EF has some rich design time support, but I have to agree that nHibernate is the way to go, despite the learning curve. If you need to make something fast and don't care about TDD or serialization (which is a large weakness of all of MS's ORM offerings) go EF.
Well My experience of Version 1 was interesting. I wanted to use POCOs but it didn't support it. After reading around I came across some code from a bod at microsoft that did this.
It was a bit messy to generate the code but on the whole this part of the process was not so bad.
A real nasty part that I came across was the lack of Concurrency checking built in, for N-tier development. You have to manage this yourself which after looking at the problem was not so bad, especially if you want to hand back the versioning back to the client for user intervention.
Second nasty and absolutely stupid thing missing was the IN keyword for LINQ queries. Not supported and so needs to be worked around. I found a solution but was a real mess bringing in some other code that quickly patched up the omissions.
Would I use EF 4.0 (2.0). Yes, absolutely, why not? In fact on stage 2 I will be using this. It looks like it supports POCOs, it looks like my concurrency model will move straight across with no problems (basically delta copy stuff). Its all good so far and I hope this time round that the Big guys at Microsoft have seen the errors of their ways and provided a solution that works.
If your buying into entity development and the whole Concept Model first thing, then its the only way to go for a complete Microsoft solution. Although the stuff being done on the M language might eclipse the idea and move the whole modelling thing back to the Database.
If you not buying into the Entity stuff then I would strongly go Enterprise Library. Its a proven technology that works every time built on a solid code foundation and Database centric paradigm. I would also go this route if you think that Stored Procedures are the bees knees and like what they bring to the table.
If your feeling really exotic and feel a bit frisky I would go with a NO-SQL approach such as CouchDB. This however does take some getting used to. Its damn weird and feels really really wrong. But things get developed in super quick time and the solutions seem to be robust and faster than expected. I would not got for this type of solution though if your big into Normalization and think that it can be applied to a NO-SQL approach. The whole model needs to be shifted on its head and the application will be needed to be modelled in a way that is driven by the technology applied.
I find the CouchDB way a bit dirty and very very wrong. But it has so many compelling reasons to use it, that I think it will seep into the psyche of every programmer, and it will definitely go mainstream in the next couple of years.
My biggest gripe still with the whole Entity thing though even in the new version 4 is that there really has not been much thought into N-tier environments. It still got a feel about it being a 2 tier solution with a lot of boiler plate code still needed to be done by the end user (developer), to get it working in a robust and dependable N-Tier way.
We been having some discussions on approaches to using the entity framework at work recently. We have a fairly large and complex n-tier web based application, which is due for a major overhaul.
The question is: If we where to starting using the entity framework, would it be better to create one big model, or a set of smaller functional/acivity based models.
I have my own opinions on this, but would be interested to hear what some other people think.
Update (17th November 2008):
I have been creating one model, wiping it out and re-creating, etc for small projects at home. Although I haven't tried, I suspect that this approach will be a bit more challenging when there are a large number of entity types involved.
Also, does anyone have any experience of using ef with a large team using TFS or similar?
In my experience with it, I would just make one big model of the database. Otherwise, it might be hard to track what tables changed where. When I make changes to the database, I just delete all the tables in the model and regenerate it.
Of course, I also didn't customize my model by adding "entity" functionality to it (not sure how that works exactly).
So I'm no expert in it, but I usually end up using the LINQ-To-SQL models/objects instead of the Entity Framework - it's worked better for me so far.