You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes it seems that the entity objects that EF creates get in my way from a naming perspective. For example, I may have a "Consumer" table in my database, and a "Consumer" domain object in my business objects. If I'm doing DB first, EF creates a Consumer entity object that eats up that name when I scaffold. There are some approaches to minimize the problem here, like just using namespaces, but of course there are drawbacks to that. Prior to Core I used partial classes to help address this type of thing and they worked pretty well. But with Core the built-in DI limits this since you can only have a single constructor on classes that use this container. Another sometimes concern is that I'm exposing my entities if I let users access my context directly, so I push these down a layer, which then adds another "name duplication concern". I am wondering if it makes sense to add something like a "POCO Convention" to EF. I'm not sure exactly how it would work, but I wanted to start a discussion.
In the most simple form the objects defined in a context could follow the naming convention ...Entity - ConsumerEntity. In this way we would know that the type definition for this class has some relationship to EF. Just like other convention-based approaches tooling/components can be aware if they want to and ignore if they don't. For the DB first people (like me) we could have a switch on Scaffold-DbContext called -EntitySuffix if present it would add the suffix "Entity" to the entity classes.
I think just adding a -suffix switch to scaffold would be valuable in some scenarios and may be an easy way to help get this started. If I could do Scaffold-DbContext ... -suffix Entity and have it add the suffix in the right places that would help with my naming extra work.
The text was updated successfully, but these errors were encountered:
Sometimes it seems that the entity objects that EF creates get in my way from a naming perspective. For example, I may have a "Consumer" table in my database, and a "Consumer" domain object in my business objects. If I'm doing DB first, EF creates a Consumer entity object that eats up that name when I scaffold. There are some approaches to minimize the problem here, like just using namespaces, but of course there are drawbacks to that. Prior to Core I used partial classes to help address this type of thing and they worked pretty well. But with Core the built-in DI limits this since you can only have a single constructor on classes that use this container. Another sometimes concern is that I'm exposing my entities if I let users access my context directly, so I push these down a layer, which then adds another "name duplication concern". I am wondering if it makes sense to add something like a "POCO Convention" to EF. I'm not sure exactly how it would work, but I wanted to start a discussion.
In the most simple form the objects defined in a context could follow the naming convention ...Entity - ConsumerEntity. In this way we would know that the type definition for this class has some relationship to EF. Just like other convention-based approaches tooling/components can be aware if they want to and ignore if they don't. For the DB first people (like me) we could have a switch on Scaffold-DbContext called -EntitySuffix if present it would add the suffix "Entity" to the entity classes.
I think just adding a -suffix switch to scaffold would be valuable in some scenarios and may be an easy way to help get this started. If I could do Scaffold-DbContext ... -suffix Entity and have it add the suffix in the right places that would help with my naming extra work.
The text was updated successfully, but these errors were encountered: