EF Core now has escape hatches that can do what Dapper does (especially with raw queries). Also mapping to DTO projections is now on par with Dapper... Let us see what more performance gimmicks they can come up with in subsequent versions.
This is all well and good, but how would you combine EF with something like DDD? In this talk you introduce a bunch of models that aren't really aggregate roots, if you have performance issues loading an aggregate like the User w/ Posts example, then it probably means the design is wrong, i.e. does a User aggregate REALLY need a collection of posts?
Why couple DDD with the ORM at all? It would be much cleaner (IMO) to have DDD-isms remain at the application layer and have your DDD models rely on repositories (black boxes to the DDD/application layer) handle persistence. Why should DDD entities concern themselves with persistence? Just my thoughts.
@@Wil_Bloodworth There is no definitive answers for this question. In some systems Domain models and database models will be same entity, while in other those will be disjointed and separated by layers, depends what is the use case.
@Ryan Woods there is nothing "good" about EF migrations. Literally nothing. I could do an entire 3-hour talk on why these suck and should never ever be used. They should die in a fire.
Creating joins using ef core is a terrible idea. the lambda syntax can get real messy. is there anyway we can ensure column name consistency if we run raw sql query using ef?
A very informative talk about stuff we really should care about when using EF Core! And + Dan is a good speaker.
According to this, I've done absolutely everything 100% wrong lol
EF Core now has escape hatches that can do what Dapper does (especially with raw queries). Also mapping to DTO projections is now on par with Dapper... Let us see what more performance gimmicks they can come up with in subsequent versions.
Some good points. Would be nice to know best approach on switching from code first to database first.
39:45 You can do SqlBulkCopy into a Temporary Table if you want to avoid the User Table Type.
Please share the link to slides presented in the video in description
Thank you very much , I got much useful information's ,you just opened my eyes to things I should care about it before start
This is all well and good, but how would you combine EF with something like DDD? In this talk you introduce a bunch of models that aren't really aggregate roots, if you have performance issues loading an aggregate like the User w/ Posts example, then it probably means the design is wrong, i.e. does a User aggregate REALLY need a collection of posts?
Why couple DDD with the ORM at all? It would be much cleaner (IMO) to have DDD-isms remain at the application layer and have your DDD models rely on repositories (black boxes to the DDD/application layer) handle persistence. Why should DDD entities concern themselves with persistence? Just my thoughts.
@@Wil_Bloodworth There is no definitive answers for this question. In some systems Domain models and database models will be same entity, while in other those will be disjointed and separated by layers, depends what is the use case.
Using migration in Django is not painful compare to add-migration in entity framework.hope they will fix that issue
@Ryan Woods yeah, its easy
@Ryan Woods there is nothing "good" about EF migrations. Literally nothing. I could do an entire 3-hour talk on why these suck and should never ever be used. They should die in a fire.
Creating joins using ef core is a terrible idea. the lambda syntax can get real messy. is there anyway we can ensure column name consistency if we run raw sql query using ef?
Use dapper
You could look into creating views on the DB side and use EF to select and read from the view