re: Imagining a better EntityFramework VIEW POST

FULL DISCUSSION
 

EF is like a half way from a simple object mapper like Dapper to a full-fledged ORM like NHibernate. You should read this post:
enterprisecraftsmanship.com/2018/0...

Some of your point is for a simple object mapper, it won't work in DDD perspective. For example (a as Author).Books[i].Author should be loaded and be the same with the instance 'a'. That's the correct behavior. You should separate 2 use cases here:

  1. Retrieve object to manipulate it during a business transaction: Object's properties should be fully-loaded or lazy-loaded in order to ensure the business constraints.
  2. Return the object to the presentation: it should be projected to a data transfer object to the outside world (docs.automapper.org/en/stable/Quer...).
 
  1. I disagree. In our code base we have disabled lazy loading for performance reasons, so we spend our time checking whether we have explicitly included everything we need. I this context the fact that EF sometimes includes entities that are not explicitly included is an unwelcome surprise.

  2. I believe that last time I tried using Automapper's ProjectTo I had a similar issue, even though I had correctly specified Explicit Expansion only. I am working on a minimal reproduction and if I can reproduce it I will file a bug.

 

Lazy load will work best if you work with single object, i.e. in business transaction. When you retrieve object to presentation layer, Linq projection will help you to avoid lazy loading, with or without Automapper. You don't have to use Automapper to have this ability. Automapper just reduces duplicated mapping in your code. If Automapper has bug, you can raise it (although I haven't seen any bug yet).

But in my experience, I also got some glitch with EF Core Lazy loading so I didn't use it too. I see NHibernate solving my problem better.

code of conduct - report abuse