After having used NHibernate for several years, I am now learning Entity Framework for use on my next project. At the moment, I am trying to decide between the code-first or model-first approaches. The model-first approach appeals to me, but the result would have to be ORM-agnostic. To this end, I am pondering the following. Would it be possible and practical to create T4 templates that generate classes and .hbm.xml files (for use with NHibernate) from the CSDL and C-S mapping content of a .edmx file?
No mapping is ORM agnostic because it is part of that ORM API or did you see Entity framework using NHibernate's hbm files? EDMX is XML representation of EDM (Entity Data Model) which is MS asset and it is mainly used for MS APIs. Moreover not all API for EDM processing provided by MS is accessible (internal implementation). EDMX is not ORM agnostic. The worse part is that it is even not database agnostic.
Anyway you can create any custom tool or transformation taking EDMX as input and providing other mapping as output. You just need to understand input and output format. I'm not sure if it will directly be possible with T4 but it is definitely possible. But it will not be practial. Practical is using single ORM to its full power and use tools available for that ORM.
It is possible and practical to create T4 templates that generate classes for Fluent NHibernate from an .edmx file. I am on a project at AMD where we are doing just that. (I am not the author myself.) See: http://tom-jaeschke.blogspot.com/2011/08/use-entity-framework-and-nhibernate.html
Related
In our company we have a lot of legacy applications which use an edmx file together with EF4.
We would like to migrate to EF6 (or EF core). Is there a way that we can generate the code first objects (dbcontext, entities) from this edmx with the mappings.
How can we do this?
Maybe the best solution for this will be scaffold (reverse engineer your model) from current database.
EF Core has nice powershell tools for this scaffolding https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db
You can also split the whole (maybe big) DbContext to more DbContexts with specified Table parameter
https://learn.microsoft.com/en-us/ef/core/miscellaneous/cli/powershell
EF 6 has also some options for scaffold actual database Entity Framework - Generating Classes
Why would you bother generating anything from .edmx? What if you created new project with code first from existing database?
What are the benefits of using ADO.Net Entity Model and EF?
Can we use both of them together in a project. I came across an example where, the user had used both edmx and ef for his application. I am not sure what is the purpose of that.
Thanks
Edmx artifact (either in the form of a file on the disk for Model First and Database First approaches or being generated by the EF runtime - Code First approach) describes your model, your database and the mapping between these. At the moment EF always needs it to work. The only nuance is that for CodeFirst applications (or, in general, applications using DbContext) this file is generated on the fly from your classes and you don't deal with it directly while in case of Model First/Database First where you use the ObjectContext the file is on your disk and (usually) is split and embedded in your assembly.
EDIT
EF6 no longer creates and uses artifacts internally (at least for CSDL and SSDL parts). However you can still dump the model in form of EDMX using EdmxWriter.WriteEdmx
Is it possible to auto generate the POCO classes and the mapping with the database defined separately using Fluent API (instead of annotations) for an existing database? Instead of coding all these entity classes manually, I find it easier if they are auto generated and then I can change them as required if the names are not incorrect (plural or singular) or the some of the relationships are not correctly mapped etc. This will save lot of time for me compared to coding all the entity classes and relationships from scratch and I am not that familiar with the fluent API syntax as well.
Yes, i encourage you to use Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
hope this helps
The Power tools are incredibly slow to generate files. It takes over an hour to work on my companies database (has a lot of tables).
Instead take a look at this visual studio extension http://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
It generates cleaner code, WCF serialisation classes, and includes the database default constraints as part of the POCO ctor.
Disclaimer: I should mention that I am the author of this extension
We are about to start using EF as our ORM. We have our own MetaData representing the databse stracture and we will generate whatever we need off of that.
We are wondering whether to use the "old" EDMX approace, or to use the new EDMX free approach (wiht DbSet and DbContext). As we do our own code/edmx generation it seems odd to generate an EDMX and then generate objects and context off of it.
The thing is I don't see much talk about about the EDMX free approach. Is it being used by anyone? Can someone with experience share their impressions? Are there known limitations? Are there pros and cons?
Asher
Are you asking if anybody is using code-first? :) By checking the number of questions in entity-framework-4.1 and code-first and ef-code-first I guess people are using it a lot. There were several questions about code-first x non code-first. Some of I answered:
EF POCO code only VS EF POCO with Entity Data Model
EF Model First or Code First Approach?
EF 4.1 Code-first vs Model/Database-first
Generally there are four approaches:
Model first (database generated from EDMX)
Database first (EDMX generated from database)
Code first (database generated from code mapping)
Database first with code mapping (code mapping manually created for existing database or manually updated mapping generated by EF Power Tools CTP)
Selection of the approach usually depends on the way how you want to develop application (as described in linked answers). It also depends if you want to use ObjectContext API or DbContext API. The former one is usually used with first two approaches (but the secret is it should work with code-first as well) the later one with all of them.
Code first has some limitations - it doesn't support all mapping features EDMX does for example:
Stored procedures mapping (it doesn't mean you cannot execute SP when using code first)
SQL functions mapping
Advanced EDMX features like defining queries, query views, model defined functions
etc.
What I don't understand is why are you trying to combine your code generation tool with EF. Either use your stuff or use EF's stuff. You will avoid complications and incompatibilities.
I have not hardly touched EF4, but I've used Linq to sql quite a lot. I would like to start into one of the EF templates but I have no idea what situations make sense for each or what their intent was.
I have the following possibilities:
Data templates
ADO.NET Entity Data Model
Service-based Database (is this even related to EF?
Code templates (I am familiar with T4)
ADO.NET EntityObject Generator
ADO.NET Self-Tracking Entity Generator
Online Templates
ADO.NET C# POCO Entity Generator
I have no idea what situations make
sense for each or what their intent
was
Not meaning to sound rude, but did you have a look on MSDN/ASP.NET to find out? There is plenty of information around. And there is a lot to each of those templates, more than i can go into here. There is a MSDN page for each of these.
That being said, i'll give you a quick summary, so people who stumble here have some info.
ADO.NET Entity Data Model
This is the file you create to use Entity Framework as your ORM, and it is mandatory for using EF. You need this before you use any of the others. You can create your EDM with a number of different approaches, including database-first (generate from DB), code-first, model-first, etc.
Service-based Database
I have never heard of this term, and given i've been working with EF a lot lately (and reading), i doubt this will be related to EF.
ADO.NET EntityObject Generator
Generates classes for entities which inherit from the EntityObject class. Identical to the default EF code generator, except instead of putting output code into the Model.edmx.designer.cs (default) file, the code gets put into seperate files. I personally don't see any benefit in this template.
ADO.NET Self-Tracking Entity Generator
Generates classes for entities when you want to develop N-Tier applications (ie if you wanted to allow a WCF/Silverlight app to work with your model). Entities are setup to be 'trackable' by the EF Graph, in order to handle persistence operations from various applications.
ADO.NET C# POCO Entity Generator
My favourite. :) Generates classes for entities which inherit from nothing. They have no idea that they are being used for persistence. Use this for applications when you want persistence-ignorance, testability and loose-coupling of your domain/persistence layers.