I am using Entity Framework at my work and faced some problems.
Usually I hear about creating tiny Edmx´s files containing tables related to some Domain ie.: Help Desk Edmx, HR Edmx, etc. Instead of load all tables in one big Edmx, what would be much simpler, but for performance considerations(at design and build time mainly), it isn´t feasible.
It took me to some troubles, first about the commom tables, ie.: Employees Tables, it is at all Edmx´s, conflicting when I use a Employee class reference and have a using to both namespaces, then I have to reference the Empoyee class by the full name MyCompany.HelpDesk.Employee.
It doesn´t look natural.
I find myself repeatedly adding the same tables at all EDMX´s, it´s a rework, and I spend some minutes adding a table to entity framework design since I have 2k tables at Add Table Dialog.
Maybe VS2012 could be a solution to load 2k Tables at the same Edmx file(since the designer could be splitted), but I don´t believe that, because it delay to compile too, not only to open the designer.
Another option could be the Code First, but it doesn´t have a decent tool to Reverse Engineer the database to classes, since it tries to load all the tables from database, tooking about 2 hours!
There is generally no solution for your problem. EF supports some way to share common entities across multiple CSDL files but it has a lot of disadvantages:
It is not supported by designer (I didn't try if VS2012 designer support this) -> you are going to maintain EDMX files as XML
It is supported only on CSDL level (classes) -> you still have single SSDL (tables) and MSL (mapping) and you must maintain them manaully
Only unidirectional relationships to shared entities (shared entity can have navigation properties only to other shared entities).
VS2012 will allow you working with multiple diagrams in single EDMX but I really don't know how fast this will be with 2k tables.
IMHO 2k tables doesn't sound like use case for EF mapping features - especially not for features where you expect the code to be generated for you. Large scale development usually involves large scale coding or developing your own tools. Your current way (by mapping shared entities again) is the best approach with default EF tooling.
If you use T4 generator for POCO classes you can even modify T4 template to use always the same class for all EDMX files. POCO classes are mapped only by class names - namespace doesn't make any difference. This will require you to put some effort into T4 generator to make sure that shared classes are generated only once and correctly referenced from all your model specific classes.
Btw. how much time does it take to start your application and load all your mappings? Are you using pregenerated EF views?
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.
Is there a way to combine code-first and database-first in the same context? We are running into massive development-time performance problems when editing the EDMX file (it takes 1.5 minutes to save). I've moved our non-insert/update/delete UDFs/stored procs to some custom T4 templates that automatically generate model-first code, but I can't seem to get OnModelCreating to be called when EDMX is involved.
Other things we've considered, but won't work for one reason or another:
We can't (reasonably) separate our code to multiple contexts as there is a lot of overlap in our entity relationships. It also seems like quite a people who have gone this route regret it.
We tried having 2 different contexts, but there are quite a few joins between Entities & UDFs. This may be our last hope, but I'd REALLY like to avoid it.
We can't switch to Dapper since we have unfortunately made heavy use of IQueryable.
We tried to go completely to Code-First, but there are features that we are using in EDMX that aren't supported (mostly related to insert/update/delete stored procedure mapping).
Take a look at the following link. I answered another question in a similar fashion:
How to use Repository pattern using Database first approach in entity framework
As I mentioned in that post, I would personally try to switch to a Code First approach and get rid of the EDMX files as it is already deprecated and most importantly, the maintenance effort is considerable and much more complex compared with the Code First approach.
It is not that hard switching to Code First from a Model First approach. Some steps and images down below:
Display all files at the project level and expand the EDMX file. You will notice that the EDMX file has a .TT file which will have several files nested, the Model Context and POCO clases between them as .cs or .vb classes (depending on the language you are using). See image down below:
Unload the project, right click and then edit.
See the image below, notice the dependencies between the context and the TT file
Remove the dependencies, the xml element should look like the image below:
Repeat the procedure for the Model classes (The ones with the model definition)
Reload your project, remove the EDMX file(s)
You will probably need to do some tweeks and update names/references.
I did this a few times in the past and it worked flawlessly on production. You can also look for tools that do this conversion for you.
This might be a good opportunity for you to rethink the architecture as well.
BTW: Bullet point 4 shouldn't be a show stopper for you. You can map/use Stored Procedures via EF. Look at the following link:
How to call Stored Procedure in Entity Framework 6 (Code-First)?
It also seems like quite a people who have gone this route [multiple contexts] regret it.
I'm not one of them.
Your core problem is a context that gets too large. So break it up. I know that inevitably there will be entities that should be shared among several contexts, which may give rise to duplicate class names. An easy way to solve this is to rename the classes into their context-specific names.
For example, I have an ApplicationUser table (who hasn't) that maps to a class with the same name in the main context, but to a class AuthorizationUser in my AuthorizationContext, or ReportingUser in a ReportingContext. This isn't a problem at all. Most use cases revolve around one context type anyway, so it's impossible to get confused.
I even have specialized contexts that work on the same data as other contexts, but in a more economical way. For example, a context that doesn't map to calculated columns in the database, so there are no reads after inserts and updates (apart from identity values).
So I'd recommend to go for it, because ...
Is there a way to combine code-first and database-first in the same context?
No, there isn't. Both approaches have different ways of building the DbModel (containing the store model, the class model, and the mappings between both). In a generated DbContext you even see that an UnintentionalCodeFirstException is thrown, to drive home that you're not supposed to use that method.
mostly related to insert/update/delete stored procedure mapping
As said in another answer, mapping CUD actions to stored procedures is supported in EF6 code-first.
I got here from a link in your comment on a different question, where you asked:
you mentioned that code-first & database-first is "technically possible" could you explain how to accomplish that?
First, the context of the other question was completely different. The OP there was asking if it was possible to use both database-first and code-first methodologies in the same project, but importantly, not necessarily the same context. My saying that it was "technically possible" applies to the former, not the latter. There is absolutely no way to utilize both code-first and database-first in the same context. Actually, to be a bit more specific, let's say there's no way to utilize an existing database and also migrate that same database with new entities.
The terminology gets a bit confused here due to some unfortunate naming by Microsoft when EF was being developed. Originally, you had just Model-first and Database-first. Both utilized EDMX. The only difference was that Model-first would let you design your entities and create a database from that, while Database-first took an existing database and created entities from that.
With EF 4.1, Code-first was introduced, which discarded EDMX entirely and let you work with POCOs (plain old class objects). However, despite the name, Code-first can and always has been able to work with an existing database or create a new one. Code-first, then is really Model-first and Database-first, combined, minus the horrid EDMX. Recently, the EF team has finally taken it a step further and deprecated EDMX entirely, including both the Model-first and Database-first methodologies. It is not recommended to continue to use either one at this point, and you can expect EDMX support to be dropped entirely in future versions of Visual Studio.
With all that said, let's go with the facts. You cannot both have an existing database and a EF-managed database in a single context. You would at least need two: one for your existing tables and one for those managed by EF. More to the point, these two contexts must reference different databases. If there are any existing tables in an EF-managed database, EF will attempt to remove them. Long and short, you have to segregate your EF-managed stuff from your externally managed stuff, which means you can't create foreign keys between entities in one context and another.
Your only real option here is to just do everything "database-first". In other words, you'll have to just treat your database as existing and manually create new tables, alter columns, etc. without relying on EF migrations at all. In this regard, you should also go ahead and dump the EDMX. Generate all your entities as POCOs and simply disable the database initializer in your context. In other words, Code-first with an existing database. I have additional information, if you need it.
Thank you to everyone for the well thought out and thorough answers.
Many of these other answers assume that the stored procedure mappings in EF Code-First work the same, but they do not. I'm a bit fuzzy on this as it's been about 6 months since I looked at it, but I believe as of EF 6.3 code first stored procedures require that you pass every column from your entity to your insert/update stored procedure and that you only pass the key column(s) to your delete procedure. There isn't an option to pick and choose which columns you can pass. We have a requirement to maintain who deleted a record so we have to pass some additional information besides just a simple key.
That being said, what I ended up doing was using a T4 template to automatically generate my EDMX/Context/Model files from the database (with some additional meta-data). This took our developer time experience down from 1.5 minutes to about 5 seconds.
My hope is EF stored procedure mappings will be improved to achieve parody with EDMX and I can then just code-generate the Code-First mappings and remove the EDMX generation completely.
We are starting a new large corporate project. The database will be 100+ tables and we will be using Entity Framework, Web API and MVC.
My question is specifically related to the Entity Framework aspects of the solution.
I am trying to make a choice between the following:
Code first to an existing Database
EF Designer to an Existing Database (Database First)
I know we can use EF to generate the database from code first or from the EF designer, but we prefer to have full control over the database and develop that in the traditional way, so we have excluded the EF options that allow us to auto-generate the database.
Most of what I can find on the internet relating to Code First deals with creating a new database and then using code migrations. And when the discussions deal with Database first then the discussions favour the EF Designer. Example here: Code-first vs Model/Database-first
My preference is to go with the combination of Code First to an existing database.
The following are my considerations for favouring this option and I'm wondering if there is anything else I need to consider, and whether my assumptions/thoughts are correct.
Code first to an Existing database
There will be a large number of classes to construct at the start, but we could do the initial generation from the EF Model Wizard.
The classes could then modified with any custom properties or to remove anything we don't need, rather than the EF Designer that would require us to extend any classes.
The disadvantage is that any changes to the database would have to be manually added to our classes, unlike using the designer which will allow easy updating.
Edit:
I think I was confused in this area. From reading, it appears that the correct way to do Data First is to create partial classes for all the auto generated classes, and then to make any modifications to the partial classes as part of the 'business' layer.
My thought has therefore changed from favouring the Code First from Database, to using the EF Designer to existing database and then creating the partial classes.
In any case you'll have to synchronize the EDM (entity data model) and the DB. You have to make sure that the EDM is fully compatible with your database. If not, it will fail, no matter if it's Code First or you use a Model.
The only difference is that:
using the designer you can do it graphically, and easyly set properties, column names, and so on
using Code First, you have to set these properties, columns names, data types and so on using conventions, Fluent API or attributes
With Code First the only advantage is that once you've synchronized the Code First model (see "Code First is also an EDM, but somewhat limited") and the database, you can start using Migrations, and evolve your model using them, which later makes it easier to apply changes to the production DB (whenever a new version is released). With graphic model you cannot use migrations, and have to upgrade the Db directly from Visual Studio, or creating SQL DDL scripts by hand.
Code First is also an EDM, but with a few missing functionalities
It doesn't matter if you use Code First or draw a model, an EDM (entity data model) will be generated. If you're used to design databases, probably you'll be more comfortable using the designer. Beware of the notes on EF Core (former EF7) below!.
However, the EDM generated by Code First has a few limitations that the designer doesn't have.
The most outstanding limitations of Code First is that in the designer you can easily map user defined functions from the BD, for example scalar and table value functions, and stored procedures. With Code First there are much more limitations.
in EF 6.1 most of this limitations dissapear, but it's still a bit difficult to make the mappings.(In fact, as of today, 2014, there's only a sample, and a simple Nuget package on how to do it.).
As of march 2017, non-Core EF, i.e. EF 6.1, is no longer being updated. MS will probably solve bugs if they appear, (this was wrong: but don't expect further changes)
New features appeared in 6.2: What's new in EF 6.2, which includes definition of indices with Fluent API, support for Like, support for non-identity DB generated keys, like SEQUENCE and some other changes
Changes on EF Core, former EF7 (as of may 2015)
At this time Microsoft is developing EF 7, but it's also maintaining EF 6.x. The current recommendation is to keep using EF 6 for some time, because EF 7 is not mature enough.
EF 7 is being developed from scratch to overcome the inherited ObjectContext which was posing terrible limitations to implemente new features. But it implements the most widely used DbContext with little changes. So, if you use DbContext you'll have an easy migraiton path to incoming new versions of EF.
However there is a very important change: in EF Core (former EF7) the EDM model dissapears in favor of Code First models. So, if you want to use the technology of today and assure an easy upgrade to new versions, don't use Model First or Database First: use Code First. There are important reasons for Microsoft to have taken this decision: Code First works much better in a team environmet with version control, and allows to work with Migrations. Anyway tou can still see the model in a graphical way (with Power Toools) or use a third party tool to create the model using a designer (several of the current commercial solutions will support this for EF7).
NOTE: Why is much better Code First in team environments? If several team members modify the model it's much easier to merge changes in several code files, than in a big XML file, with lots of lines which defines the model. It's also much harder to understand the changes between versions in this hugh XML file. For medium or big projects, I recommend you to move to Code First ASAP
I'm new to the MVC way of developing applications and for the most part am enjoying. One thing I'm a bit confused about is the use of the Entity Framework. The EF usually (at least in my experience) defines multiple tables and relationships through the .edmx table. A couple of questions:
Why would I define a separate class file for a specific table if EF is building all of the classes that I need in the background?
From some of the validation approaches that I've seen, they want to define validation logic in the class related to a model for a table. If I'm using EF, will I have a .cs file describing the model and a .edmx describing that same table (in addition to its associated tables)?
If yes, how do you connect the .cs file to the .edmx definition so that CRUD flows easily from the EF?
Sorry if these seem like easy questions but I'm just trying to get my head wrapped around these fundamental concepts. Too many examples out there use only a single table where in my business, I NEVER write an application that uses a single table. There are always multiple tables in relation to each other with foreign keys. Thanks for your prompt responses.
For a tutorial that shows the use of partial classes -- in a Web Forms application but for MVC the same technique would be used -- see Adding Metadata to the Data Model in this tutorial:
http://www.asp.net/web-forms/tutorials/getting-started-with-ef/the-entity-framework-and-aspnet-getting-started-part-8
From your comment "The EF usually (at least in my experience) defines multiple tables and relationships through the .edmx table." it sounds like you are familiar only with Database First and Model First -- for an introduction to Code First and an explanation of the differences, followed by a series of tutorials with an MVC example using Code First, see this tutorial:
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
Good questions, Darryl. Here are my responses to your bullet points:
Defining separate model classes that match the data models that EF creates is generally a good idea for the simple sake of separating your data access "stuff" from your business model objects that will get used throughout your app. Some people don't like this approach because it creates some amount of overhead when it comes to mapping your entities to POCOs but, if you use a tool such as AutoMapper, the overhead is minimal. The benefit lies in you creating a layer of separation between you and your (likely) evolving data model.
You could define validation logic in a buddy class (just a partial class that sits along-side your entity) but that would mean that you would be using that entity across your app and some would debate that that isn't the best idea. The alternative method, as mentioned above, is to create your own POCOs to mirror the entities that EF creates and place your validation attributes on the POCOs.
I mentioned this in the previous item but the way to do this would be to define buddy classes. Give EF buddy classes a Google and you should find plenty of examples on how to do that.
Just to add to all of this, if you choose to create POCO classes that mirror your EF entities, tools like AutoMapper can handle fairly complex relationships when it comes to mapping classes. So, if you have foreign key relationships in your data model, AutoMapper can understand that and map your POCO classes accordingly (i.e.: You have an entity that has a 1-to-many relationship and a POCO with a list of objects to mirror that relationship.)
I hope some of that helps...
I'm developing a data access layer for a database with over 700 tables. I created the model including all the tables, which generated a huge model. I then changed the model to use DBContext from 4.1 which seemed to improve how it compiled and worked. The designer didnt seem to work at all.
I then created a test app which just added two records to the table, but the processor went 100% in the db.SaveChanges method. Being a black box it was difficult to accertain what went wrong.
So my questions are
Is the entity framework the best approach to a large database
If so, should the model be broken down into logical areas. I did note that you cant have the same sql table in multiple models
I have read that the code only approach is best in these large cases. What is that.
Any guidance would be truly appreciated
Thanks
Large database is always something special. Any technology has some pros and cons when working with a large database.
The problem you have encountered is the most probably related to building the model. When you start the application and use EF related stuff for the first time EF must build the model description and compile it - this is the most time consuming operation you can find in EF. Complexity of this operation grows with number of entities in the model. Once the model is compiled it is reused for the whole lifetime of the application (if you restart the application or unload application domain the model must be compiled again). You can avoid this by precompiling the model. It is done at design time where you use some tool to generate code from the model and you include that code into your project (it must be done again after each change in the model). For EDMX based models you can use EdmGen.exe to generate views and for code first based models you can use EF Power Tools CTP1.
EDMX (the designer) was improved in VS 2010 SP1 to be able to work with large models but I still think the large in this case is around 100 entities / tables. In the same time you rarely need 715 tables in the same model. I believe that these 715 tables indeed model several domains so you can divide them into multiple models.
The same is true when you are using DbContext and code first. If you model a class do you think that it is correct design when the class exposes 715 properties? I don't think so but that is exactly what your derived DbContext looks like - it has a public property for each exposed entity set (in the simplest mapping it means one property per table).
Same entity can be used in multiple models but you should try to avoid it as much as possible because it can introduce some complexities when loading entity in one context type and using it in other context type.
Code only = code first = Entity framework when you define mapping in the code without using EDMX.
take a look this post.
http://blogs.msdn.com/b/adonet/archive/2008/11/24/working-with-large-models-in-entity-framework-part-1.aspx