Abbreviations used in this issue

POCO: Plain old CLR (Common Language Runtime) Object DAL: Data Access Layer UI: User Interface DI: Dependency Injection

Whats a Command and a CommandService?

Command: A command in our case is a POCO that will be used as a Parameter Object in a CommandService
CommandService: A service that acts on a Command and returns nothing. Normally a CommandService is considered a write-only service, meaning that it only inserts, updates, or deletes data. (has side effects)

Whats a Query and a QueryService?

Query: A query in our case is a POCO that will be used as a Parameter Object in a CommandService
QueryService: A service that acts on a Query and returns some result. Normally a QueryService is considered a read-only service, meaning that it does NOT insert, update, or delete data. (Has no side effects)

Back to the issue

While reading Dependency Injection Principles, Practices, and Patterns I realized that I had created some badly coupled code.

Currently, our Dependency graph looks like this: Coupled-Graph

This is because our UI Layer uses a contract from the business layer to fetch POCOs from the database AND this returns the same POCOs that are used by the DAL.
- Also, our domain layer is practically non-existent. Most of it would currently be divided between the UI layer and the DAL with the way we are currently doing things.

To fix our Dependency graph and make it decoupled, we want it to look like this: Decoupled-Graph

Easier Parallel Development
We would be able to replace our entire DAL or UI layer without messing with any other part of the code-base
Testability
Maintainability
And probably a few more...

This design makes use of DI

Can be found here

Our UI Layer has many different dependencies on the domain layer.
The Domain layer depends on the Data Access Layer with its implementation of the SqlDatabase.

This design makes better use of DI

Can be found here

Advantages

Now our DAL is a bit more clear than it was before.
- It only implements query or command services that need Data Access by implementing a specific interface found within the Domain Layer.
Similar services within the domain layer are now put into one single interface that implements every single similar interface.
- This allows the UI Layer to only depend on that single service (It could still depend on the sub-services though if it wanted to)
We can replace either UI or DA Layers without changing anything in the Domain Layer.

Disadvantages