Feedback from a long time EF user and experienced software developer

[patrickklaeren]

I saw a talk promoted on Jetbrains, controversially titled: "Stop using Entity Framework as a DTO provider!"

I googled the content and found this. I have matched this based on the author and speaker name.

Here's my take on what this sample demonstrates:

The sample code demonstrates the pitfalls of why people think Entity Framework is slow and champions downloading a lot more from your database server than is required in almost all scenarios. It encourages a lot of code to be written for very little gain. This sample code tries to bypass Entity Framework so much so that it starts replicating EF concepts in extension methods, and other domain. Change tracking being one example.

The consumer should not be able to pass in one bool and change the behaviour of the resulting entity. This is effectively building a repository and leaking Entity Framework outside.

All of the mappings require the "full fat" Entity Model be downloaded from your database. There is no partial hydration or projection, which is where the time and performance can come from. You are stopping Entity Framework from being what it is, over reaching and not allowing the database to do what it's good at: data processing.

Further to this, the sample code demonstrates tight coupling between DTOs and Entities. There is no way for me to reliably transport DTOs between layers without these having knowledge of domain entities that shouldn't leave my domain layer.

This codebase demonstrates a non-scalable, non-ideal usage of Entity Framework.

[ChrisKlug]

Hi Patrick! You are absolutely correct that I am the one doing the talk, and that this is the repo for the code I use for the demos. And I do appreciate your feedback. But I don't really understand how you think you are in a position to give feedback without having seen the talk. You have no idea what I am saying in the talk, and the code is demo code used to demonstrate concepts I talk about. And, being demo code, it is written in a way that shows some concepts and can be shown quickly. So there are definitely areas that could be better in different ways. But writing code that has enough complexity to show concepts, but is simple enough to show quickly is pretty hard to be honest...

However, I disagree with quite a few of your comments regarding how the code is bypassing EF etc. Once again, you have not seen the talk, but retrieving objects in the manner that I am doing is not bypassing EF in any way. It is on the other hand very much in line with the way that DDD works with aggregates.

I also have no clue where you are seeing me bypassing or replicating EF's features, like change tracking in any way. I am using features built in to EF to enable mapping my data to entities that are properly object oriented classes instead of just DTOs...

And as for the coupling between DTOs and Entities, I completely agree that there is coupling there in this case. But I also say that for pure reads you should probably be using read specific models with simpler mapping. Once again, exactly what a lot of DDD proponents advocate. But for the writes, I want DDD-style entities that give me a good object oriented API... That's just the way I work, and it works fine for me.

You are more than welcome to have your way of doing things. I do too. But I don't go around telling people that what they are doing is wrong because I do it in a different way. Especially not based on a tiny GitHub repo with a bit of EF code that is connected to an hour long talk that I haven't seen.

But if you really do think everything I am doing is wrong, why are you not on a stage somewhere showing how to use it properly according to you? I am pretty sure there is room for a talk like that as well. Especially considering how many different ways there are to write code. Looking forward to seeing your talk at a .NET conference in the future!

[patrickklaeren]

I do speak, I am a Microsoft MVP and admin on the biggest C# Discord where there are also recorded talks I give of EF. But I don't think an argument of authority is very productive, here, so please accept this as my response to you trying to expose me as some arbitrary viewer.

I am giving this feedback because you are telling people how to use EF with your title.

I think I know where the talk is going based on the code, notes and your blog.

I think it's disingenuous to say otherwise.

This is a public website, with public code and open to scrutiny.

I think the fact you haven't been able to address the fact you download everything from the database, which is akin to doing SELECT * FROM Table to bring everything into memory gives me enough of an indicator where priorities lie.

Thank you for your response.

[ChrisKlug]

I'm sorry to say, but I do see you as an arbitrary viewer. I have had my MVP title for a long time, and I am well aware of the fact that that has got nothing to do with how good you are. It has to do with how much you do for the community. So I don't see that as something that should change my way of viewing your feedback. But once again, that's me.

I am also not telling people how to use EF. I am telling people how I am using it, and how to use it in a DDD manner. Does that come with performance hits, yes it does. And it is not for CRUD applications. DDD never is.

I don't see where I am downloading everything from the database. Yes, I fetch entire entities. I don't see how that is wrong. Having that said, I have the smallest tables in the world in the demo. In a real scenario I would very likely not map everything from the table to my entity unless I needed it. But sure, because I select all columns in my table with 5 columns, I obviously am doing it wrong...

Sure, this is a public website with public code. And you are more than welcome to scrutinize it. I have no problem with that. But you have not heard the talk, and are telling me that I am doing it wrong because I am doing it in a different way than you.

I assume you have read Eric Evans book. And if you look at the way that DDD uses entities and aggregates, this fits into that idea. At least according to me. But once again, there are lots of different ways to do things, and one is not necessarily wrong because there is another one. At least according to me. There are trade offs to each one, and I have chosen my trade offs in this way...

For optimal perf, I would probably stay away from EF completely. But this talk isn't about perf. It is about showing how you can use EF to map to proper OOP classes with functionality and data instead of data bearers that spread the business logic across the entire solution.

[patrickklaeren]

Quite a pity to react in such a way to criticism where one has to provide credentials and in the face of doing exactly what the other person thinks brings value to the table is still dismissed.

Every day is a learning experience :)

Edit: I believe the matter was not about experience, but you questioned why I don't speak or am in the community. The fact I am an MVP proves quite the latter. People should be more optimistic about others and their intentions, rather than defensive.

[ChrisKlug]

So, you coming here without having seen my talk, telling me that everything I am talking about is wrong and the reason people dislike EF is constructive criticism? Not really in my opinion. That kind of feedback requires context...at least in my mind.

And no, I did not question you being in the community, or in ANY WAY ask for credentials as a reason for me to listen to you. I believe credentials like that are completely unnecessary. Unless you happened to work for the EF PG. I just said that if you have the "right" way of doing implementing EF for all situations, I think you should do a talk about it at a conference. I get to do my talk at different conferences, so there is obviously room for EF talks at confs. So it should be possible for you to go and show the world that I am wrong, and educate them on the only right way to do it correctly.

I think you are missing a lot of context by looking at the code. And my blog to be honest. There is much more to it in my opinion. And as I said, there are trade offs to any solution you build. Including one with EF. These are the trade offs that I have chosen for my way of building things.

The difference in that is that I am aware of the fact that there are trade offs, and open to the fact that there are a ton of ways to use EF. The fact that you basically just stepped up and said that my way is plain wrong makes me less inclined to listen to be honest. Anyone that believes that there is only one way to do something, and all other ways are always wrong, have probably got some learning left to do in my opinion.

[patrickklaeren]

That's right, the way you're using EF is wrong.