I want to get rid of the big messy edmx file which has caused me nothing but pain when merging in svn.
I would like to move towards code first. For this, ideally I would generate the classes automatically based on the current edmx, then remove the edmx file completely.
I won't need a designer after that, I'll add columns and relations by hand.
How would you go about obtaining this? Would the new ef 4.2(?) be a better fit ?
Thanks
I would use the Entity Framework Power Tools CTP1
to generate the POCOs from your existing Database.
Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
After you have your POCOs and you Context generated, you dont need the
edmx file anymore.
I eventually generated the .cs files from the edmx changing the generator to "ADO.NET DbContext Generator" from http://visualstudiogallery.msdn.microsoft.com/7812b04c-db36-4817-8a84-e73c452410a2 .
Then added primary and foreign keys as they weren't generated (I am using a mysql db if it makes any differences).
Then I had to change a ton of queries because if before you could do :
from x in context.Table1
from y in context.Table2
where x.id = y.xid
and would translate to a join, this no longer works !
Quite a bit to change but eventually it seems to be working.
Related
When working with EF (v4,5,6) I have always used Database-first (I was mistakenly under the impression this was the only way to generate Entities from existing tables, EDMX, etc). But today I tryed Code-first, and it can also generate the POCOs (in a different way, no EDMX, different connection string, less cr8p lying around, etc..!)
So far, the usage of EF for CRUD appears to be exactly the same, can anyone who has used both please confirm there is nothing different (in usage), or gotchas I should be aware of?
And a supplementary question is, can I generate both in the same project ? (Not that i want to, but existing proj has EDMX within a folder, can I create another folder and generate Code-First Entities (different set of tables only), so i end up with DBContext and DBContext2 ?
Yes, the usage is the same. If you check the generated code you'll see they use the same System.Data.Entity.DbSet properties and they both inherit from the same System.Data.Entity.DbContext class.
Yes, you can generate both in the same project, but does not makes much sense, because you have to maintain both of them if the DB changes.
I currently use EF6 and use the model first approach. As I understand it, EF7 will be moving away from using an EDMX, and going from a more code-first approach. Now I know I will still be able to reverse engineer from my database into classes if need be.
However one thing I am not sure about is any manipulation I currently do with EF6 will be supported in anyway in EF7.
At the moment, I write T4 templates that read through the EDMX, pick up on the entities, and create new classes based on them. For example, I create partial classes for each entity that has deep clone methods in them. I also create repository classes based on the entities and create methods for finding by primary key, based on which properties in each class have been identified as the primary key.
If I lose the EDMX, does this mean I need to go back to manually creating these? Or is there another way?
If you want to keep using T4 templates, you can switch to something like CodeFirst -> ReverseEngeneer approach.
You update model in code, generate new migration, test it on a database and then use a reverse engeneer code first approach (http://msdn.microsoft.com/en-US/en-en/data/jj593170.aspx) to generate everything else. Theoretically it can be automated.
In my team we do it manually, but we do not need migrations, only a code first contexts and a lot of additional things, that T4 generates whery well.
Yes, you can still use T4 templates with Code First, We navigate Entity Classes instead of the EDMX Model, .
I have been looking at VS2015 recently and having some issues with T4 and asp.net 5 and related projects (FileManager hangs for multiple file outputs and you will need the latest version of Visual Studio, currently Update 1)
I have code first classes which are generated from my existing db using ADO.NET Entity Data Model. Now I've added some new tables to the database.
I want to know if its possible to create associated code classes from the new db tables without (re)creating the model again from scratch?
Yes it is, if you use Reverse Engineer Code First to do so. It will create POCOs exactly like Code-First, but it will do so based completely on the current database. No .edmx file and no T4 template. Just Code-First.
You should know, by the way, that this (along with regular Code-First) are going to be the only ones allowed in EF7. They are getting rid of many things to try to slim it down, and both Model- and Database-First got the ax (at least, for now). This blog post from Microsoft's ADO.NET blog explains that, along with some other features.
I'm trying to figure out what the best way to go would be for Entity Framework code generation with a "database first" approach. I want the complete master description of the model to be the actual database schema with annotations stored in database in tables or extended properties. Not interested in a model first or code first approach. Not opposed to writing custom code to implement if it will yield the highest quality solution. Here are some ideas:
(1) Generate EDMX from the database. Use custom code to add annotations to the EDMX regarding uniqueness and other constraints that are not currently built in to EF. Use T4 templates to generate code from the EDMX.
(2) Write a custom tool that generates "code first" classes from the database. No EDMX files in the solution.
(3) Something else?
It seems like #1 requires deeper knowledge of EF and more actual work than #2, which I am now opposed to if there are significant benefits.
Any advice?
Well, nothing is easier than just dragging the tables from the server explorer to the edmx designer surface. That is how I do it. I don't do any customizations to the model so I can just delete parts of it an regenerate.
You can import the model from your database with EF. Right-click on the EF designer and choose "update model from database" option.
If you want a little more you can try http://radarc.net . It's a code generation tool which creates scaffolding and CRUDs. It uses T4 templates and code first so you can customize the way it generates code.
I'm planning on using the Entity Framework 4.1 in my next project, but I'm having trouble finding a good way to go about it.
In short, I want to build a multi-tiered application in which the entities will be travelling through web services, and to keep it all as clean as possible I want to use POCO's rather than self tracking entities. Also, there already exists a SQL 2008 database that will be used to base the entities on.
From what I've read so far (from Julie Lerman's article on http://msdn.microsoft.com/nl-nl/magazine/hh148150%28en-us%29.aspx, amongst others), it seems that:
If you use the Database First approach, you get a beautiful .edmx to edit your model in, but you'll always end up with persistence-aware objects rather than POCO's, which is not useful in my situation.
If you use the Code First approach, the "ADO.NET DbContext generator" only partially helps you: it does generate entities from the .edmx, but it doesn't generate the code required to get the foreign keys and cardinality correct. This means that the code will not work out-of-the-box (-edit, not true, see my post below-), you either have to
a) use Data Annotations on your POCO's, which is ugly imo because it pollutes the POCO's with database information and also creates a dependency on the EntityFramework assembly.
b) use the DbModelBuilder passed to DbContext.OnModelCreating to set the correct foreign key, mapping etc. information (i.e. the 'fluent' API). And even though the API may be 'fluent', it's still pretty hard (and probably unmaintainable) to set all this information correctly so that it matches the existing database (see http://sessionfactory.blogspot.com/2011/04/conventions-in-entity-framework-41.html for some examples of this).
I realize that the reason why the "DbModelBuilder-way" requires so much effort is because it was designed to be used the other way around: you're supposed to generate the database from the Entity definitions, not try to tweak all Entities so that they (hopefully) match an already existing database. However, it seems to me that the "DbModelBuilder-way" will, in the end, produce the best result: pure POCO's with no database metadata in them.
Now, having said all this, my question is:
Does anyone know of a way to load an .edmx into the DbModelBuilder, so that the foreign key, column mapping and other information doens't need to be specified by hand through the fluent API?
I think that this would be the best of both worlds, because you can visually edit the mapping like you would in the Database First scenario, and still get clean POCO's because all required metadata is stored in the DbModelBuilder.
Man what are you talking about?
If you use the Database First approach, you get a beautiful .edmx to
edit your model in, but you'll always end up with persistence-aware
objects rather than POCO's, which is not useful in my situation.
That is not true. EDMX can produce almost everything code first can and even many things which code first can't.
If you use the Code First approach, the "ADO.NET DbContext generator"
only partially helps you: it does generate entities from the .edmx,
but it doesn't generate the code required to get the foreign keys and
cardinality correct. This means that the code will not work
out-of-the-box, ...
That is not true. Once you set up EDMX correctly it will create exactly entities you want.
Does anyone know of a way to load an .edmx into the DbModelBuilder
That way is DbContext T4 generator!
Anyway there is one more tool you can check: EF Power Tools CTP1. This tool can create code first mapping from existing database.
Of course every tool creates model which is 1:1 mapping to the database. If you want anything more you must modify the model or mapping manually!
Apparently, there are two ways you can use the generated code from the "ADO.NET DbContext Generator", depending on which type of connection string you use.
If you use an entity connection string, i.e.:
<connectionStrings>
<add name="MyDBEntities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.;Initial Catalog=MyDB;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
</connectionStrings>
the DbContext will be filled with all the metadata (column mappings, foreign key relations, etc.) from the .edmx. Also, the DbContext's OnModelCreating isn't executed. This is Database First using POCO's, and this is what I wanted to achieve.
What I did wrong was that I used a regular SQL connection string to pass into the DbContext. This causes a totally different type of behaviour: because the DbContext is now empty, it will try to explore all Entity classes and use conventions to generate a database schema for this. Now the OnModelCreating is called, expecting you to tweak this mapping and then generate a database from this.
In short, the solution was to use an entity connection string rather than a SQL connection string.
Read about the T4 POCO generation templates:
Walkthrough: POCO Template for the Entity Framework
POCO Template Code Generation Options
Using the POCO T4 Code Generation Template for Entity Data Models (video screencast with Julie Lerman)
Those T4 code generation templates allow you to use
database-first approach with EDMX model file
but: generate simple POCO (plain-old CLR objects) which have no inheritance from any EF specific class - they're just absolutely plain CLR classes.....
This gives you the best of both worlds - a nice EDMX model and persistence-ignorant POCO classes.