Felix M├╝hlenstedt (1) [Avatar] Offline
#1
Hallo Mark and Steve,

thank you for the great work in your first book Dependency Injection in .NET. Already purchased Second Edition which is also really great.

While reading the first book, I already started implementing what I have learned, my colleges joined me also. So most of the code was built like in the book descripted.
Had an WPF application as Client, Presentation Logic, a domain layer and data access (No WCF service).

The domain layer contained the repositories and services interfaces and their implementations, the POCO's for all the objects (e.g. order, products, customers, suppliers).
The Implementation of the repositories are contained in the data access layer.

Since now the company wants to move on, we want to improve our system more. While reading the second book, especially because of chapter 9 and 10, I get more and more confused.

I am not confused about what is written in these chapter. I am more confused how to implement it. What I did was first to split the ever-growing services into one Query service first, and all the commands into single implementations with the generic "ICommandService<TCommand>" interface.

After this I tried also to split up the Queries to single implementations with an interface "IQueryService<TQuery, TResult>" and "IQuery<TResult>". Later I also read about it in a blog from Steve.

First what I am missing is what happened now to the repository interfaces and implementations. Should these also change to SRP.

Then I am getting more confused. In the Listing in chapter 10 and the decorators. Like auditing security, there is no repository injected instead the CommerceContext is directly injected. This confused me because now the domain layer would have again a dependency to the data access layer.

The topic consumer owning the abstraction discussed to separate IService interface and Service implementation. The Discussion didn't mention the repository interfaces. I for my part think that service and repository interface should also be not in the same assembly, am I right?

The last problem I have is with implementation of POCO's, which depends on each other (e.g. order and items). What for me is important is especially an approach with Transaction in mind. So, when something went wrong there is a rollback for the order and all its items. Next to find and inform the right warehouse, inform the billings system when products are ordered, there has to already a change in the disposition within the scope of the transaction.

Thanks and best regards
Felix