2

The way I handle large projects using EF CF is by doing the following:

  • Create a data model (EDMX)
  • Disable the Model-First code generation feature for that model by clearing the Custom Tool property
  • Use Entity Framework POCO Generator extension to add the relevant template (t4) files to the project
  • Customize the template files to follow certain coding conventions we follow

This all looks good in concept but when we run the project, EF seems to think we are using the Model-First approach. This is not the case since we do not want the EDMX model mapped to any database. We expect the database to be created at runtime if the model has changed.

So how can we remove database mapping expectations of the EDMX?

Raheel Khan
  • 14,205
  • 13
  • 80
  • 168

1 Answers1

4

By not using EDMX. EDMX is the mapping. Once you use EDMX you are using either Model-first or Database-first. Code first means no EDMX and no code generators. The code in the approach name means that you are supposed to write that code. The only way to get entities and mapping generated in code first is when you have an existing database and you use EF Power Tools but if you don't have the database you don't have any such support.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Sounds like he has a database so can just use the EF Power Tools. It's a really easy process and you can tweak from there. – Keith Rousseau Apr 30 '12 at 14:50
  • I have to differ. Code generation is very much possible in Code-First. I myself have been writing code generators for a while and conceptually you should be able to generate entity-aware POCOs from your own classes. But in orer to avoid writing my VS extension, I have created a separate project in my solution, added an EDMX and custom templates, generated code, copied it into my master project as partial classes. – Raheel Khan Apr 30 '12 at 14:58
  • 1
    Yes you can use code generators, but in terms of EF you cannot use code generators from EDMX - at least not default ones because EDMX is not just a diagram. It is a mapping and you need to get that mapping out of EDMX to the code if you don't want to use EDMX at runtime - those default generators are not doing this. – Ladislav Mrnka Apr 30 '12 at 15:05
  • @RaheelKhan - you can beg to differ all you like, that doesn't change the fact you are NOT using code first. You're using Database First with Poco class generators. This still uses the EDMX as the model. If you want code first, then you need to either write it from scratch as code-first, or use EF Power Tools. – Erik Funkenbusch Apr 30 '12 at 15:17
  • @MystereMan: Please understand the following: I AM using an EDMX Model. I AM NOT using a database. I am using the EDMX to generate Code First classes, NOT Model First classes. The reason people prefer to do that is to have your classes more persistence agnostic than Model or Database First. – Raheel Khan Apr 30 '12 at 15:19
  • @LadislavMrnka: What you explained is exactly what I am doing. Custom generators for EDMX. I guess my only option is to keep the EDMX in an isolated project and manually copy generated files into the master project on every model change. – Raheel Khan Apr 30 '12 at 15:21
  • I think you don't understand EF basics. There are no model first or code first classes. There are either POCO classes which can be used with code, model and database first approaches or old EntityObject based classes which can be used only with database and model first approaches. The problem is that the POCO class itself is not enough unless your class exactly matches EF conventions for mapping. If it doesn't you need to define mapping either through EDMX, Fluent-API or data annotations. If you already have EDMX just use it and do it as model first with POCOs. – Ladislav Mrnka Apr 30 '12 at 15:27
  • @RaheelKhan - No, you are not. The EF Poco generator does *NOT* generate code first classes. It just generates Poco entities with a DbContext. This is not enough to be a code-first model. I know very well why people do this, and I know exactly how it works. So please stop arguing. You are NOT generating a code first model, you are only generating a model-first model with DbContext and POCO's. Here's a walkthrough from the ADO.NET team that describes it as "model first" http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-model-amp-database-first-walkthrough.aspx – Erik Funkenbusch Apr 30 '12 at 15:27
  • @RaheelKhan - Simply put, if you are using an EDMX file, you are NOT using code first. Disabling code generation on the EDMX file does not magically make it code first. In fact, the official "model first" recommendation is to use POCO generators and disable code generation. Your understanding of what is model first and what is code first is wrong. – Erik Funkenbusch Apr 30 '12 at 15:31
  • @MystereMan: My friend, I am NOT using the default POCO generators!!! I am simply using EDMX because it is easier to visualize programming inheritance along with entity relationships. Since we are in a reflective environment, I am generating my own POCO classes. Instead of arguing here, I am considering launching a new question with the concept pre-defined. My generated POCO classes have no resemblance whatsoever to Model First classes or behavior. – Raheel Khan Apr 30 '12 at 17:21
  • @LadislavMrnka: I was agreeing with your comments so far but strongly disagree now. MS themselves have made a distinct clarify between persistence friendly and persistence agnostic classes viz-a-viz, model-first and code-first approaches. Please read my comment above and I will invite both to the new question that tries to address a much broader problem. – Raheel Khan Apr 30 '12 at 17:24
  • @RaheelKhan - You are doing a very poor job of explaining your problem. What's more, you expect us to be able to psychically understand your custom T4 classes. We don't know how they work, therefore asking us questions about how it works is pointless – Erik Funkenbusch Apr 30 '12 at 17:29
  • @MystereMan: Now THAT I agree with! You see, I've been coding my own code generators since pre .NET and am still developing an approach that allows a more central approach than deciding between model-,database-,code-first approaches. My question can even seem to challenge the isolation of the DAL from the BLL. I do apologize for the confusion but I guess there was no way for me to present this more clearly without the feedback above (including yours). Like I mentioned, I will definitely repost after maturing the idea but your input is has been valuable. – Raheel Khan Apr 30 '12 at 17:40
  • I still don't understand why do you think that model first cannot be used to generate persistence agnostic classes? – Ladislav Mrnka Apr 30 '12 at 18:57
  • @LadislavMrnka: I am not saying that it cannot be done. In a way I am doing that. I still call the approach code first because POCO generation from the model is now an offline process. The customization of code generation templates allows me to make the classes more workflow aware than persistence aware. The database is created on the fly just like Code First. If this explanation does not convince you, then I probably AM mixing up some concepts. Please do clarify in that case. – Raheel Khan Apr 30 '12 at 21:47
  • Also, please do post your final comments as answers since there seems to be no better way to address the title of the question other than what both of you have suggested. Thanks again. – Raheel Khan Apr 30 '12 at 21:52