We have been using EF through several versions with SQL Server. We started with Model First since Code First was terrible early on, then Database First when Model First did not work well with views and sprocs, and now EF7 says both will be dropped so we are considering migrating to Code First in EF6 before eventually converting to EF7. Still I want a visual designer for creating and understanding relationships so am considering LLBLGen for our development team going forward.

Mainly I'm wondering why LLBLGen decided to support Code First at all since you have your own designer and support Model First and Database First, and what advantages there are to you supporting Code First, and what limitations there might be such as -

• Can I specify different schema concurrently for the same DbContext? We use this to clone and update large tables via schema transfers and that works well.
• Can I add my own model Data Annotation decorations to the CF models?
• Can I have multiple DbContext, each with only the needed relationships, for a large database, so I don't have to define the entire infrastructure for a small DbContext we want to run quickly?
• Can I define my own partial classes? Use class and interface inheritance?
• Will my CF customizations be overwritten by LLBLGen code generation?

Also, do these various approaches "round trip" at all? Iow, can I switch between using MF, DF and CF all on the same project as appropriate? E.G.

• Use DF for bringing in a new view
• Then use MF for defining a new relationship
• Possibly use CF for adding some methods or Data Annotations

Thanks. A prospective customer, Dave

CodeSlinger wrote:

We have been using EF through several versions with SQL Server. We started with Model First since Code First was terrible early on, then Database First when Model First did not work well with views and sprocs, and now EF7 says both will be dropped so we are considering migrating to Code First in EF6 before eventually converting to EF7. Still I want a visual designer for creating and understanding relationships so am considering LLBLGen for our development team going forward.

You're not alone in this

Mainly I'm wondering why LLBLGen decided to support Code First at all since you have your own designer and support Model First and Database First

It's about dependency on a tool like LLBLGen Pro. For some people it's important to be able to eventually move away from a tool used in development if they need to for whatever reason. Supporting code-first makes that possible as you simply pick up the code base you've generated all along and can continue from there. This is also the reason we support fluent-nhibernate. CF in EF is more limited though (due to EF, not us).

what advantages there are to you supporting Code First, and what limitations there might be such as -

• Can I specify different schema concurrently for the same DbContext? We use this to clone and update large tables via schema transfers and that works well.

You mean have 1 entity mapped to two schemas? (in which case this is not doable as EF doesn't support it), or do you mean, multiple schemas in one catalog? We support that.

• Can I add my own model Data Annotation decorations to the CF models?

Yes. LLBLGen Pro supports a sophisticated attribute assign system where you can assign attributes through rules so e.g. annotate all string fields with a string validation attribute, built using macros so it adapts to the field it's applied to. See: http://www.llblgen.com/documentation/4.2/Designer/hh_goto.htm#How%20To/AssignAttributesToElements.htm#projectlevel

• Can I have multiple DbContext, each with only the needed relationships, for a large database, so I don't have to define the entire infrastructure for a small DbContext we want to run quickly?

Yes, you can create multiple models inside 1 project mapped to the same database, and each model is then generated as a separate vs.net project. See element grouping: http://www.llblgen.com/documentation/4.2/Designer/hh_goto.htm#Functionality%20Reference/ElementGrouping.htm

• Can I define my own partial classes? Use class and interface inheritance?

All classes are generated partial. You can specify (with macros or manually per element) the base class for an entity so you can e.g. derive some or all entity classes from a class or classes you supply yourself. You can also specify additional interfaces on the entity classes if you want to, using macros and rules so you can define them once and they're applied to all elements matching the rule using the macros defined. See: http://www.llblgen.com/documentation/4.2/Designer/hh_goto.htm#How%20To/AssignInterfacesNamespacesToElements.htm#projectlevel

• Will my CF customizations be overwritten by LLBLGen code generation?

If you alter the generated CF file which contains the mappings: yes. But we added extension points so you don't have to You can create a partial class of the ModelBuilder class and supply additional mappings in code yourself. http://www.llblgen.com/documentation/4.2/Entity%20Framework/hh_goto.htm#V56/CodeFirstSupport.htm

It's all template based, so if you want to generate different code, you can always edit a copy of the template (you can edit it inside the designer), and use that instead to generate different or additional code.

Also, do these various approaches "round trip" at all? Iow, can I switch between using MF, DF and CF all on the same project as appropriate? E.G.

• Use DF for bringing in a new view
• Then use MF for defining a new relationship
• Possibly use CF for adding some methods or Data Annotations

Thanks. A prospective customer, Dave

DF and MF are used at the modeling level in the designer, and you can mix them, so yes, you can use DF and MF concurrently, we don't set the designer in 'df or mf' mode, you can do whatever you want: first read the meta-data of the catalog, then add an entity and forward map it and create a new table, export script, that's all possible, the designer takes care of that.

CF is a form of how to define your mappings. Microsoft uses CF to reverse engineer the entity model to the abstraction level you use in our designer from code at runtime. So in short: DF and MF when modeling / working with your model, then generate code and that's either in CF or DbContext + EDMX form (there's really no difference in EF6, besides that CF is more limited). You can generate the code however you want, so if you first start with CF and then switch to DbContext + EDMX, that's just selecting another preset in the code generator.

Hope this helps

Thanks Frans. That helps a lot. Let me explain my question about the schema better.

When I create my database model, it uses the default dbo schema which is the only schema I import tables from. When I update certain R/O pricing tables that are large and which are actively read, the trick I use is to use a sql script to clone (copy) these tables into a new schema (e.g. D20150504), then use the same DbContext created for dbo but with the new schema name by editing the underlying edmx xml in memory (see below) so effectively dynamically switch the schema name the model was created with, edit the cloned tables, then alter the schema to move the old dbo tables to yet another schema for temporary backups, and move the new edited tables from the new schema to the production dbo schema. This lets me update the tables w/o bothering production transactions as updating takes a while and I don't want to lock out transactions for all that time. It is much less disruptive to just swap the newly updated tables from the new schema and this works well for us.

Swapping schema is a lot easier in Code First OnModelCreating than what I do now with Model First or Database First where I read the edmx xml into memory and modify the edmx file data in memory before creating the DbContext dynamically from that in-memory data (http://stackoverflow.com/questions/24769364/how-can-i-create-a-metadataworkspace-using-metadata-loading-delegates).

So what I'm wondering if LLBLGen using MF, DF or CF would somehow allow me to use the very model generated based on the dbo schema and dynamically create a DbContext for the same tables but a different schema than dbo so I can get at the cloned tables that were identical in regards to the model but merely using a different schema name than dbo. At worst, I should be able to keep doing what I'm currently doing but am thinking if I has LLBLGen generate CF I could add a better hook there to set the scehma name.

Thx, Dave

CodeSlinger wrote:

Swapping schema is a lot easier in Code First OnModelCreating than what I do now with Model First or Database First where I read the edmx xml into memory and modify the edmx file data in memory before creating the DbContext dynamically from that in-memory data (http://stackoverflow.com/questions/24769364/how-can-i-create-a-metadataworkspace-using-metadata-loading-delegates).

So what I'm wondering if LLBLGen using MF, DF or CF would somehow allow me to use the very model generated based on the dbo schema and dynamically create a DbContext for the same tables but a different schema than dbo so I can get at the cloned tables that were identical in regards to the model but merely using a different schema name than dbo. At worst, I should be able to keep doing what I'm currently doing but am thinking if I has LLBLGen generate CF I could add a better hook there to set the scehma name.

As LLBLGen can generate code for both scenarios, it's up to you how you want to manage that schema change on runtime. You can go with loading the EDMX, or intercepting the model creation at OnModelCreating, in a partial class (in case of CodeFirst).

So, LLBLGen would help you generating the code you want, but in the generated code you will face the limitations you already have due to EF.

Thx.