.NET Data Community Standup - Stop using Entity Framework as a DTO provider!

Chris Klug has some opinions about Entity Framework and wants you to know about them…

Featuring: Jiri Cincura, Chris Klug

#ef #efcore #community #dto

[alpsavasdev]

The presentation highlights a fundamental challenge with abstraction in software design. While we strive to separate database tables from our domain models, databases inherently do much more than simply store entities. This creates a cascading effect where each solution breeds new problems, eventually resulting in a complex web of workarounds and technical debt that must be remembered with each new feature.
After experiencing these issues firsthand, I've shifted to using DbContext directly in my handlers/services rather than relying on repository abstractions. This approach eliminates the cognitive overhead of constantly configuring tracking behavior, managing include statements, and handling other database-specific concerns that repositories often fail to fully abstract away.
Sometimes simpler and more direct approaches lead to more maintainable code in the long run.

[mtranchi]

19:20 Where is Scott Hanselman when we need him? INCREASE THE FONT

[jazzerbyte]

Nice exploration of ways to use EF. In my case, it's always been DB first and everything scaffolded.

[FastForward-is]

those smiles when Chris was summoning the hard coded migrations 🤣

[MarcelDevG]

Really nice conversation!
Would like more of those about the tradoffs and strategies from the real world

[obensunday]

Great content. Where’s the repository?

[VoroninPavel]

I disagree with Shay's comment about the price. This price is merely a lack of the needed functionality in the framework. The framework either supports working with the rich objects (dealing with the associated complexity of mapping and querying) or the team decides not to make it the main goal. But this should be explicitly stated in the philosophy of the product.

[svorskemattias]

I don't understand why you don't like separating data from behaviour. Functional programmers agree that such separation of data and operations has benefits. Not saying operations should be put in command handlers in an application layer.

Other than that, I agree with almost nothing else as well, but each to their own! :) :P

[VoroninPavel]

With value converters there's also a catch that if your type implements IComparable<T>, you can write a query with comparison operators, but they will be applied to the underlying type when translated to SQL, and in case your value type and the underlying one have different monotonicity, you are in trouble.

[VoroninPavel]

Quite an important thing Chris forgot to mention. Aggregate should not expose mutable entities it owns. It should work as a gateway to all the changes in the graph of objects it is responsible for.

[asombershade]

Silly question maybe but what software/platform did you use to compose the various webcams and screen share feed? Thanks!

[DavidSmith-efeh]

why not just extend the entity? Owner extends Person, you get all the columns from person and can have your owner logic there. Tbh, this looks like over engineering.

[VoroninPavel]

There's a significant distinction between Autoinclude and Owned entities is that in latter case EF is capable of detecting replacements. For regular navigations you'll get an error that EF cannot track multiple entities with the same key.

[BenjaminHuarez]

Left join is very appreciated, thanks!

[volodymyrliashenko]

I prefer using the dto approach vs dealing with all this more complicated EF configurations and later deal with less readable queries and shadow properties.
You still may need the vehicle id for some internal/administration features.
So, based on my experience it is easier to develop and support if you follow dto approach on the data layer and do mapping between layers.

DDD approach here, unfortunately, creates limitations on queries and updates.

And yes, big NO for EF migrations. It is nice but creates too many headaches for a big team because it is too smart.

[marschakra]

45:30 vehicle has VIN as the unique identifier but string is not good for primary key so we need the Id and it's not about the business logic but for DB only

[bananasba]

Wrapper object was used when there were no convenient ORMs, it does not matter how hard you try, you can not hide the fact that it's an object from DB. Look - you are using Vehicle properties in a queryable instead of VehicleDTO properties - loss of encapsulation. With all nice extensions, services, wrappers you just move a mess to another place, complexity has to live somewhere. Also, one thing is completely missing - no real business logic was shown, not a single use case where you actually use all these fancy objects and methods. The problem with all DDD examples I know is that they are oversimplified.

[marschakra]

25:00 I don't like the DTO class has the same name as wrapper entity class, it's confusing
I would use 'Vehicle' and 'VehicleDto', respectively

[DevelTime]

I know it was not main topic, but it was educational to see some tiny things EF can do, for example I use Include only when I need it, so I was not aware AutoInclude exists 🙂, For the main topic though, I am not sure if I understood -- the whole modeling stuff is made upon preference, correct? If yes, the direction is somewhat odd for me, because take for example VIN. It cannot have duplicates, but you won't model it in the data, but right in the database. But then where do you handle errors, like localizing the DB error? The VIN instance does not save itself, so IMHO it will be in the service somewhere. Actually this video inspired me to actually check if I could use EF entities for DTO, the reasoning is -- reducing the number of types.

[VoroninPavel]

SplitQuery is dangerous for fetching aggregates because it's not atomic in contrary to joins.