I am playing around with the latest Entity Framework, and I would like to separate the generated classes into 1 file per class if possible.
I also want to be able to re-generate these files after splitting.
Although this question asks the question, it is old and the accepted answer is "maybe in the future." Split EDMX for Entity Framework - Breakout object layer into separate files - possible?
Is it possible to do this? If so, how do I go about doing this?
Thanks
Use EFv4 and T4 template (for entity objects or POCOs). It will create separate file for each created entity. I'm not sure why you want it. It is generated code which mustn't be manually modified because modifications will be lost during next regenerating.
Breaking EDMX insto separate files is somehow possible but pretty hard - it is manual work. Check these articles (part 1 and part 2). It is approach for working with large models.
Entity Developer for SQL Server provides some enhancements for large EF models handling, like multiple diagrams. As for the code generation, there is a File Per Class code generation option as well.
Forget the generation crap and start with the latest EF and use the code first approach. You then have complete control over the POCO. I am still a bit underwhelmed on EF, but the code first approach will allow you to create the classes as you like and then link them in to ORM bits. If you don't want to write your own classes, I know of no way to achieve what you desire.
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.
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)
In one of our environments, we have built a code generator where the power user can create models at runtime and deploy them. No need to mention that we are using EF 5.0 Code First.
Our application itself also has many models that it is using internally. So the dbContext may end up having at least 80 properties and more (80+ tables).
What we are observing is that the initial asp.net application load time is rather high and the memory consumption in the IIS process is high as well (600MB+).
What are the ways that we can configure EF to be more careful with performance and memory usage?
UPDATE:
Seems like the only way to do pre-compiled view generation for fixed entities. This way we can boost the performance since ratio of fixed models to dynamic ones is 60% to 40% in our projects
How do we generate per-compiled views for Code-First?
UPDATE:
Using EF Power Tools I was able to generate the views. Now i am wondering if I can have two separate Code-First Contexts in the same project. For one I intend to generate views since the models are fixed. The second one models can be changed by administrators, so for now I have no easy way of generating views for them.
Do you think this would be possible?
You have a very specific situation - given the dynamic nature of your code-gen vs code-first models -and as #Ladislav mentioned. I'm not sure there is an 'easy answer' if at all.
Normally you can make views at (pre)compile-time - e.g. EF Power Tools. That's not going to work for you.
'EdmGen.exe' is the utility that does most of that, so automating that somehow may be one option - but I haven't tried, and is probably a challenge given what you have.
T4 templates - is the other option.
This is the best source of info for what you require -
How to use a T4 template for View Generation
However I'm not sure if that's going to help you either. Problem is it needs the EDMX model generated in the first place - and that's usually done by hand.
Now, you could invoke a tool for that - or try to sort of 'reverse engineer' the EDMX model somehow - and see how it's constructed by EF in the first place. I'm not sure, it's a bit 'speculative'.
Here is the post I made about what I know on the EDMX reader/writer, and how you can use that. Not sure, but maybe expands your horizons a bit:)
EF 4.3 Code First Migrations - Uncompress __MigrationHistory Model
Also I can link in some more info about how to access metadata from code, via DbContext, but again I'm not sure if that is of any use to you, you probably need all that info 'before hand'.
And you'll probably need to engage into EF source code, to be able to follow and understand how it works, and how to do what you need, if you haven't already.
http://blogs.msdn.com/b/adonet/archive/2008/06/20/how-to-use-a-t4-template-for-view-generation.aspx
EF 4.3 Code First Migrations - Uncompress __MigrationHistory Model
http://edmxdom.codeplex.com/ (EF 6 but it overlaps, you can also find the EF5)
The method - Entity Framework Code-First - looks good. But its very difficult to create all the classes for a large database.
Is there any easy way to generate the Entity Framework Code-First classes?
You can use the recently released Entity Framework Power Tools CTP1. The tool gives you the ability to reverse engineer code first, meaning the Database will be mapped to Code.
Note that all tables in your large database will be mapped. There currently is no way to choose which tables will be mapped to code. Reading through the comments, this feature will most likely be implemented in a future release.
The point of EF Code-First is that you define your domain model in code, then your user-interface and database can be easily generated from that domain model. This has a number of advantages including reducing the amount of tedious code which needs to be written, and helping to ensure your database, your domain model, and your UI match each other.
However, at some point you are going to have to write your domain model - there's no way that can be "generated" (by which I assume you mean computer-generated) as it is personal to your application.
If I've misunderstood your question, please leave a comment and I'll update my answer.
If you want to use the code-first model, but already have an existing database, you can use the Entity Framework Power Tools to generate classes.
If you're reading this after May/2012, the above tool may be out of beta!
No there is no way to generate classes for you if you are using code-first. Code first means that there is no model and no database so you can't generate classes unless you have some upfront design in any case system (UML) which will autogenerate code for you. Simply generating classes without any input about how they should look like sounds like AI from Sci-fi, doesn't it?
If you already have databse you are not using code first but database first. In such case you can have your classes generated.
Check out the link below. It's a program that will generate POCO classes from your databases. I think that's what you're looking for.
http://msormcodegen.codeplex.com/
Generate the code from the database first using database first generation and then modify the resulting code to start your code first version