AdaptiveClient.EntityFramework.Zamagon VS AdaptiveClient

I also wrote a demo app for AdaptiveClient. Take a look at the WPF UI and see my approach.

AdaptiveClient Demo

Demo App

For example in the Zamagon demo app the Autofac Module for the UI project and the Autofac Module for the API project both load common backend DI registrations:

Demo application is here.

See here.

This demo will also show how to structure your project dependencies.

Take a look at the fully functional demo application.

Zamagon demo application has been substantially updated and documentation has been improved.

Applications talk to each other differently than services within a single app. If you want App A to talk to App B you can use something like a REST API. I suspect you are asking about services within a single app. In this case Service B and Service C can actually be injected into Service A. Likewise Service A and Service C can be injected into Service B and so on. In reality it is a bit more tricky than this - I describe an object I call a Service Manifest which is simply an object with a property for each service. The manifest is injected into each service. So from within Service A you can do this: serviceManifest.ServiceB.DoSomething(); You can get sample code that shows this here.

I suggest AdaptiveClient as a simple approach to solving this problem. It uses standard dependency injection concepts to allow the developer to separate the service layer into logical business classes and access them as a collection via the AdaptiveClient object.

AdaptiveClient makes it easy to write granular services and inject shared dbContext.

I wrote a small library called AdaptiveClient that works well with WPF apps. Have not tried it on an Avalonia app yet - but I will be doing so in the next week or so.

You may want to check out a small library I wrote called Adaptive Client. It does what you want and greatly simplifies the process.

AdaptiveClient uses Autofac keyed registrations but abstracts the dirty work away.

You can get AdaptiveClient here.

I didn't read OP's entire article (sorry I've been working for 12 hours) but it looks like he is on the right track. I wrote a small library that (I think) ties nice nicely to what he proposes: AdaptiveClient. You can use this library to write loosely coupled components (not a monolith) using dependency injection, and DRY and SOLID design principals.

DI works. It adds complexity but it's worth it. The question of how to write granular, interdependent, testable services is a valid one. There are many dead-ends - for example how to wrap multiple service calls in a transaction. I wrote a small library called AdaptiveClient that attempts to answer these questions and simplify some of the complexity introduced by DI. Would love to hear your comments.

I wrote a small library to assist with this very problem. AdaptiveClient allows you to write granular services and inject DbContext. The same instance of DbContext is injected into all services so one service can call another and calls can be wrapped in transactions.

On a different but somewhat related note, you may run into a situation where you have services that are dependent on each other. This will give some DI containers fits. Look at AdaptiveClient for an easy way to resolve this.