There is a lot to like in EntityFramework... and some less desirable parts.
The good
Automatic translation of C# Linq queries ...
For further actions, you may consider blocking this person and/or reporting abuse
I'm interested in understanding what you mean with migration problems with Dapper. I can't offer an opinion for Entity since I've never used it before, I've only used Dapper. Structuring your objects that will hold the database data and having the dapper functions in a .net standard library would allow you to migrate to a desktop,web,or any environment. Do you mind explaining what you mean by migrate?
In this case, migrations build/update a database instance based on a set of model classes in code. For example, if you added an Age property to a PersonModel.cs class, you could call 'Add-Migration AddPersonAge' in powershell, which would generate something like AddPersonAge_timestamp.cs to your project's Migrations directory. Calling Update-Database will apply the migration to your database (add an age field to the Person table).
EntityFramework support migration-driven database delivery as described in this article:
enterprisecraftsmanship.com/2015/0...
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:
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.
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.
"For example, the following is valid code... but it mistakenly assigns..."
Huh. I always thought using = was a compile error but apparently it's just a warning for bools.
This article highlights a lot of issues that are caused by bad architecture rather than EF. You can overcome every issue here by designing your code base well.
Could you elaborate?
I am eager to learn anything and everything that might help on this journey.
Of course, more than happy to help. I'm out at the moment but I'll chip in tomorrow 😊
A great discussion, however what's the End Game's Objective Possibilities and Procedures Process!!!
Wiltel49@gmail.com
AAS ITI MICHIGAN C#2018!!!
Currently I work on a largish project that isn't very well architectured, at least not any more.
I want to add a new architecture alongside the old one in order to start afresh without starting over. Then we can slowly port everything over from the old architecture.
As yet, I don't know what the new architecture might look like, so I am starting out by layout out the good and the bad in our current code base.
The code first mapping work is boring, tedious and confusing. Would be nice to bring back the mapping tool somehow.