I've seen this before but haven't found concrete reasons.

When you add Entities to your EF model, EF auto generates classes for these entities.

In terms of DataAccess, why is it preferred to not use these Auto Generated Classes, and instead use your own Data Models for Data Access.

Ex.

 EFAutoGeneratedClass = //query = BAD 

 SeparateModelClass = //query = Good 
  • 3
    Who says that it's bad? For what reason? Do the auto-generated classes do exactly what you need? If yes, then it would be unnecessary work to write your own, and hence unprofessional. You can always switch if the situation changes. – Kilian Foth Nov 24 '14 at 18:07

A database, being data and generally being optimized for storage efficiency and retrieval, does not necessarily map directly to business domain classes. The less perfectly an auto-generated class fits into a proper domain model the greater the code maintenance problems.

  • Database design is now driving domain design.
  • A Domain model should model your domain, not your database.
  • How the hell does one decouple from a data-store if the domain is the data store?
  • Extra code to get DB-classes to work with proper domain classes.
  • Good design tends to be given short shrift because... "click" - look! instant classes and their CRUD[1] code. Design done.
  • If you insist on ensuring correct, consistent storage of domain object data then you still must write CRUD code to integrate the instant-classes.
  • Rational might be: "Let's read all that data now - avoid using the sloooow I/O." This old, original, spiel about .NET "working disconnected" is @(#*$&; it makes for very slow UI response.
  • In the final analysis the database is just an implementation detail.

    [1]: Create Read Update Delete

  • The domain design and the database design should be considered as a whole. If a client can have multiple addresses how can this be achieved in the domain and in the database so that the two fit together. Looking at it solely from a domain perspective or solely from a database perspective will lock you onto solutions that might not be maintanable. – Bent Sep 13 '16 at 13:30

If you database changes, your auto-generated entities will change upon a refresh of it's schema. You don't want these changes to break your code, but if you depend on them, it might break your code (in many places as oppose to one place if you transfer the entity content over to your own model)

  • This doesn't really answer the question. And I personally do want the changes to break my code, that way I know all the queries I need to fix. – Andy Nov 25 '14 at 23:50

My problem with auto generated code is its lack of maintainability. If there is a small change in the database then you have to refresh the entire generated code section and make sure that only the intended change have gone in. And if you are not using any code repository which does not tell you the changes in the code then it is much more difficult to find the code changes. It also means that the entire component should be tested again fully for all scenarios.

Also, I have noticed that developers working on the legacy generated code sometimes make manual changes in the generated code instead of generating the auto generated code section again. After a period of time it becomes almost impossible to replace the auto generated code.

Code First of Entity Framework seems to me a much better option. The code change is localized to a certain file so less chances of breaking any existing functionality.

So in nutshell, if you have a very disciplined team who does not touch the generated sections and also diligently covers all the test scenarios using Unit Tests...then by all means you can go for generated code approach but try to have Code First approach as much as possible.

  • If there is a small change in the database then you have to refresh the entire generated code section and make sure that only the intended change have gone in. -- Which takes what, two minutes if your schema is really complicated? – Robert Harvey Nov 25 '14 at 23:50
  • Also, I have noticed that developers working on the legacy generated code sometimes make manual changes in the generated code instead of generating the auto generated code section again. -- Those developers are either not paying attention, or the generated code is not properly annotated with comments to alert the developers that the code should not be hand-modified. – Robert Harvey Nov 25 '14 at 23:51
  • 1
    My problem with auto generated code is its lack of maintainability. -- Auto-generated code does not have to be maintained; it only has to be generated. See the partial keyword in C# for a way to create maintainable code alongside the auto-generated code. – Robert Harvey Nov 25 '14 at 23:52
  • You should not be manually changing generated code to begin with; it defeats the purpose of using a code generator, which is to let it write the code for you. – Andy Nov 25 '14 at 23:54

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.