Is Ardalis Specifications and Repositories the right way to go?

[danielmackay]

By using Specifications we are able to keep our application layer clean from persistence concerns (i.e., not taking a dependency on EF Core).

However, from what I've seen so far, we lose the ability to select only the columns we need from the DB. We also lose the ability to select only the columns we need from joined tables.

Is there any way around this? If not, I believe we've lost more than what we've gained.

Pros:

• Cleanly encapsulates DB Access
• Ability to unit test handlers
• Can share DB queries
• Can Integration test DB access independently

Cons:

• Lose ability to select only the columns we need from the DB (performance implications)
• Lose ability to control transactions

[danielmackay]

Possible solution: https://stackoverflow.com/questions/73045877/select-only-needed-field-with-listasync-in-ardalis-clean-architecture

[danielmackay]

I'm totally on board with this (Jason has the same logic):

https://www.linkedin.com/posts/milan-jovanovic_should-you-abstract-away-ef-core-in-clean-activity-7042567386381594624-2LL6?utm_source=share&utm_medium=member_android

[danielmackay]

From @matt-goldman:

I think there’s a difference in the basis for the reasoning though. Abstracting away EF core isn’t about “being able to change the database” any more than Clean Architecture is. It’s about two of the core principles of CA; namely, being testable and being independent of frameworks.

He notes that you should write integration tests, and he’s right, you should. But by including EF in commands and quarries, you can only write integration tests.

I think compromise is a good thing (as long as they are “well considered”). But for me having EF in the commands and queries is not a compromise I like. It’s not just about “changing the database”, sometimes it’s about not having a database at all.

Here’s a more abstract example. The Domain layer is supposed to contain enterprise logic and types. By definition, this means logic and types that are (potentially) shared by more than one application. What happens when you want to start sharing this? One client has a DB that they need to be accessed by a new application. We discussed different options, but ultimately, the best course of action is to abstract it behind its own API so that the various other things using it can all access relevant data.

If the commands and queries in the applications that use this DB were accessing it via abstractions,
Switching to get the data via an API is trivial. Getting it direct from the DB with EF core requires a rewrite of all their commands and queries and all their tests.

By injecting EF core into commands and queries, in my view you’re not just violating the principles of clean architecture, but the practicalities too.

[danielmackay]

From @william-liebenberg:

I'm wondering that both approaches are totally fine. As long as we have considered them fit / unfit for a particular application. What works for different clients may be different.

So include EF when the ultimate flex is required, or don't include it when we're in control of the DB shape and when EF just isn't needed.

We also have a possible solution to using the specifications with a custom selector for doing projections.

We need to test drive that solution for sure

If we can be happy with that custom selector feature, then I think we have wins in many many ways.

Only writing integration tests vs "some" unit tests doesn't feel like a good balance.