What is a valid reason for using the ‘ADO.NET EntityObject Generator’ with EF? In case you don’t know, it generates a T4 file that does the building of the entities from the edmx. You can then change the T4 file to change how the entities are generated.
My question is: other than changing the base class in which entities are derived (also implementing interfaces) and changing the accessibility of entities and/or the context objects and naming conventions, what use does this have? Considering the existing features of EF and partial classes.
I’ve come up with 2
- Grab the table/column descriptions from the database and populate the summary on the entities and properties
- Generate light wieght DTO’s and do auto mapping.
1 seems like too much work considering it only updates the comments on the models, not the edmx itself (although it could do so)
2 Is this even useful?
We have done a few things with the T4 templates. The first one is to split out the generated code into one class per file, instead of one massive file. This just makes it easier to navigate and browse through the entities.
The second, and more important one, is to automatically generate data annotation validation attributes such as StringLength and Required. This lets us validate our entities with a single function call, and it makes sure that their validation attributes are always in sync with the database (since if we change a column length in the DB, for example, the generated StringLength() attribute is then updated when we do ‘Update model from database’).
At a previous job, we also added base classes and interfaces to the entities, as you mentioned in your question.
Here’s a snippet from our T4 template that checks for required columns and string lengths and adds the necessary validation attributes: