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
Related
Can we create table in database from our Web application dynamically using EF where user define fields for table.
I am working on MVC 4.
Is it possible ?
and if yes then how to do it.
Depends on what you understand by dynamic here. Changing the runtime version of the Context isnt possible.
Generating, compiling, loading NEW code is. So a new context, and POCO code can be declared. Compiled and loaded. All controlled by a piece of running code.
However, the ongoing lifecycle gets complicated.
The use of code first migrations becomes tricky.
How to manage chnages to extensions in Prod.
How to merge ongoing dev and prod.
Managing the mapping in Fluent API in generated code is awful.
You cant do it all in Attributes.
The context backflips and automated migrations nightmares have cost me many a night.
Dealing with main build natural extensions and production/localised implementation extension gets VERY hard. You need to make sure they are incorporated back into the build.
And a must is You need to know how to manage different contexts on the same DB at the same time.
I have exactly this UNFINISHED project at the moment. I have put it on hold until we are on EF6.
I expect to spend several weeks on this topic alone.
And Im still not sure i want to continue down this path.
I am seriously considering moving to a meta Data / bucket data approach.
So It is possible but difficult (In my opinion at least). It will be easier in EF6 due to the multiple context support. But it will still suffer from most of these issues and require code generation and compilation still.
Good luck...
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.
Supposedly this release includes 2 features I'm interested in.
Enums support
Model can be broken into multiple files.
I don't want to install it because of issues people report, so I will ask questins here :)
Is there any wild guess when we get production-ready version of this stuff?
My issue with EF right now is that it get's really slow after 100+ tables. Do I understand correctly that new feature with multiple diagrams will help with scalability?
Its in EF version 4.1
Code first method drops the EDMX designer all together, its all in code using classes, and if a slow designer is a a big thing for you, code first method is definitely for you.
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.
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.