I am relatively new to the EF stable. I don’t know it’s best bits. I haven’t got years of tried and tested experience under my belt. But really, what the hell is this “fixing up” feature?
I have turned off change tracking, and it still bloats my carefully crafted eagerly-loaded – yet selective – queries. If I happen to be taking in a fair subset of my data, and following a number of relationships, then this monstrosity swells my object graph. It populates objects and collections in properties that I did not ask for.
Why didn’t I ask for them? Because I don’t need them, or want them. This data has to go to the client you know. It can swell to many times it’s necessary size with properties that I did NOT ask for.
It may be that this adds negligible overhead under the covers, slotting in entities that were intentionally retrieved to satisfy a demand that I did ask for. But it only uses (and do correct me if I’m wrong) the data that does come from my explicit query. Which means that the collections that it is populating and that I did not ask for, are not even complete! So I can’t use them. So what’s the flaming point of having them?
Maybe I am of a type that should be using an immutable methodology and framework. And maybe I will eventually find peace in such a solution. But EF isn’t just mutable, it’s mutant!
This bizarre behaviour may not have been so out-of-place in prior versions of EF (I’m using EF Core 2.0) because querying one of the partially-formed child collections may have lazy-loaded the rest of the content. But EF Core doesn’t support lazy loading, so it can’t even claim to self-heal the data. And I’m thankful, because lazy loading is another approach that I am considering to be an anti-pattern (see previous post).
I shall stop my whingeing. If I don’t like it then there are many other ORMs that I can use instead. And I expect I will. But still – partial child collections “fixed up” for me. Do you think you’re helping me here? Giving me this unusable result that I DID NOT ASK FOR?!?