Conceptual question about the ORM specific implementations
k290 opened this issue · comments
One of the purposes of the specification pattern is to "avoid database notions leaking out of repositories." With respect to the problem where repositories that leak IQueryables to the application layer: "The implementation of IQueryable highly depends on what LINQ provider is used behind the scene, so the client code has to be aware that there potentially are queries which can’t be compiled into SQL." And so the specification pattern allows us to work with Expressions, instead of IQueryables which are sometimes intentionally implemented.
When one uses an ORM specific package, or a custom crafted one, we again start leaking ORM notions out of the repositories.
Of course there is a line we draw somewhere to be practical rather than purist. For example, we often say "our specifications work for ORMs that support LINQ".
As soon as I'm using things like SplitQueries in my specification (because I need them!), I'm back in a similar situation of leaking IQueryables. I cannot be sure my query will work if pass it into a repository that uses a different context, database or ORM.
I'm curious though what a more purist approach might look like? By purist I mean: "We accept a dependency on ORMs supporting LINQ, but not on ORM specific methods like AsNoTracking or SplitQueries". How would a purist push these methods back up into the repository layer?
As software developers we're often forced to make choices between the ideal and the pragmatic, and I think this is another example of this kind of choice.
If you wanted to be "more ideal" with regard to exposing features of underlying ORM and implementation details, you could either avoid using AsNoTracking and AsSplitQuery completely, or you could ensure they were abstract "hints" the specification could pass along to any implementation, which could leverage or ignore them as it saw fit.
Of course, in reality the real implementation of the query provider will make a difference in the actual behavior of the system, but the general goal is to limit the extent to which such differences impact our design of our system and its business rules / domain model.
Thanks for the thoughts. I'm satisfied with that. I'm going to leave this open for 24 hours in case anyone else chimes in and then will close the issue.