0

Disclaimer: The technology I had in mind when thinking about and formulating this was .NET Core MVC. I was also thinking about using e.g. Simple Injector to integrate with .NET Core. That way, I don't think I have to write a custom HTTP controller activator like described here.

This might not make sense if Pure DI is used. In this post, the composition root would wire up the DI container.


I want to keep the parts of the composition root that's not tied to the specifics of the presentation technology when changing the presentation technology. For example, when going from a .NET Core REST API to a .NET Core Console Application, I would change the application's presentation technology and it's entry point. But, and this is an assumption, parts of the composition root will be agnostic to the presentation technology, and thus reusable.

The idea is to split the composition root in two, where one part would be reusable no matter what presentation technology the project is using. This is the architecture I have in mind, the arrows shows the direction of the dependencies:

enter image description here

  • The application's entry point calls on the presentation agnostic part of the composition root to compose its part of the application.
  • The application's entry point has itself the responsibility to compose all that is needed for the presentation specific technology to work.

The presentation agnostic composition root would likely get a container passed to it as an argument from the application's entry point. This way, the entry point can wire up the DI container with whatever framework is in use.

An underlying assumption is that anything which needs to be implemented in the presentation layer is specific to that technology, and needs to be changed with it.

To decouple the presentation agnostic composition root from .NET Core, one could use a 3rd party DI container, instead of the built in DI container.

Separating the presentation agnostic part out seems to make the application more loosely coupled to the presentation technology. Does the suggested approach make sense? Or will this lead to grief and pain?

  • What you described there is a simple wrapping of 3rd-party code into reasonably rich user-code interface. I see no connection with composition root. – Sereja Bogolubov Jul 22 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.