Code templates for scaffolding entity types and DbContext from an existing database

[rowanmiller]

We have one seam at the moment where folks can get a hold of the IModel we build from the database and manipulate it. We haven't really done any usability testing on this to see if it is good for changing table name conventions, etc..

We will also want some higher level extensibility points, such as code generation templates.

[abelepereira]

Where is this IModel manipulation being allowed? I guess some sort of extension over the default ef command (EntityFramework.Commands) need to be implemented, but where? Also: does this "extension" for model customization implies creating a new command assembly or will the default EntityFramework.Commands allow some sort of DI?

Regards

[rowanmiller]

The seam we have at the moment is designed for providers to use... so yes, you probably need to implement at least some parts of the provider to use it. This issue is about creating some high level seams that can be used by the application developer.

[dazinator]

Just wanted to check my understanding - as of the present release there is no way for an application developer to customise the code generated via scaffolding (a provider writer can), although in earlier releases there was a razor based template approach which has since been pulled? So essentially to do stuff like pluralisation etc we are waiting for the resolution of this issue - is that correct?

[rowanmiller]

@dazinator yes, that is correct. Post the 7.0.0 release we plan to provide customizable code-gen templates and code based interception points where you can customize the reverse engineered model and how it is written out to code.

[idg10]

One problem with this approach is that the existing model seems to support just one Name for an entity, which is used for both the generated type, and also for the property on the context. This means that if you want an entity type called Customer but and you want the DbSet<Customer> on your context to be called Customers, it doesn't look like you can do it, because the code gen pulls the name of both the type and that property from the IEntitySet.Name property.

I've worked through an attempt to singularize some names. (I'm working with a database where all the tables have plural names. Leaving this as is produces correct-sounding dbset properties, but wrong-sounding entity types. E.g., new Customers is a weird way to create a single customer. Singular names produce wrong-sounding dbset props, but I find that slightly less disturbing.)

Having done this, I'm not sure the approach of modifying the model feels right, because the name you want depends on where the name is actually being used - a property referring to a collection of entities of some type typically wants a different name than one referring to a single property, and some people might want yet another convention again for the mapped table name. I'd prefer the ability to supply an interface (e.g., INameMapper) with methods such as GetSingularNavigationPropertyName, GetMultipleNavigationPropertyName, GetEntityTypeName, and maybe even GetContextDbSetPropertyName.

There's already a partial implementation of this concept in RelationalScaffoldingModelFactory, which has GetEntityTypeName and GetPropertyName methods you can override. My ideal solution to this would have this fleshed out so I can control everything, and for it to be separated out, so that I'm not obliged to derive from, say, SqlServerScaffoldingModelFactory just to be able to plug in my logic. (Pluralizing/singularizing of identifiers used in code doesn't feel like it should have a dependency on a database-specific type, but as far as I can tell, I needed to make my own derived SqlServerScaffoldingModelFactory to be able to use this extensibility point.)

[jjwilliams42]

I realize this is going on 2 years old, but was anything changed here that might make customization easier?