1

Following multilayered software architecture, a application should be consist of serveral layers.

(eg: Presentation layer, Business layer, Data access layer, ...)

For instance:

In a MV* application, we said "Presentation layer could see Model layer, but Model layer shouldn't be able to see Presentation layer".

OK, That's right!

But in a actual application (eg: a desktop application), there are some "Bootstrap System" code like: bootstrap application, application lifecycle management, load UI system, init resource, and so on...

It seems that the "Bootstrap System" could see everything in the application whether it is "model" or "presentation".

My quesiton is: Which layer the "Bootstrap System" should be in.

Very thank.

-----------------------Edit this problem-----------------------

Very thanks for @Mark Seemann 's reply.

IMO, "Composition Root" is the application's entry point where we can construct global object (or use DI Container).

Therefore the responsibility of "Composition Root" is composing object graphs.

But my question does not focus on composing object graphs, it focus on "Separation Concerns".

For instance:

In a MV* application, you have a ApplicationManager object which manage the application's lifecycle.

In the application's entry point (eg: Main), we could construct ApplicationManager.

In the same place (the application's entry point), we also construct some other objects (eg: UI Framework, ResourceManager, DB Respoistry, etc).

(Note: we also be able to use DI Container instead of Poor Man's DI, but it just technical details.)

When user click the "Button-Quit" in the view, the presenter will call ApplicationManager.Quit().

Then the application will quit.

Obviously, ApplicationManager.Quit() will release everything whether it is "model" or "presentation", so ApplicationManager could see everything in the application.

My question is Which layer the ApplicationManager should be in. (ModelLayer? Presentation Layer? Composition Root?)

Note: In this case: ApplicationManager is not Composition Root, the Main (or DI Container) is Composition Root.

chansey
  • 1,266
  • 9
  • 20
  • possible duplicate of [Ioc/DI - Why do I have to reference all layers/assemblies in entry application?](http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application) – Mark Seemann Aug 24 '15 at 08:12
  • In the [Composition Root](http://blog.ploeh.dk/2011/07/28/CompositionRoot). – Mark Seemann Aug 24 '15 at 08:14
  • @MarkSeemann Thanks for your replay. I have edited this problem. – chansey Aug 24 '15 at 14:54
  • 1
    There are no rules that dictate that a layered application must have a specific number of layers, or that they have to have specific names. It's up to you do decide where various concerns go, but perhaps this overall treatment can be helpful: http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same – Mark Seemann Aug 24 '15 at 15:00
  • @MarkSeemann After reading your blog post and some other article, I have learned a lot! You explained my confusion, thank you so much! – chansey Aug 26 '15 at 14:59
  • @MarkSeemann In my example, I think the ApplicationManager.Quit() should be a primary port which is called by presenter (primary adapter). (ApplicationManager.XXX() methods represent a group of UserCase for application lifecycle.) – chansey Aug 26 '15 at 15:00
  • The implement of ApplicationManager.Quit() will call some infrastructure interfaces, these infrastructure interfaces maybe at the same layer of the ApplicationManager (or inner layer). The implement of these interface are in the infrastructure layer which is the outer layer. – chansey Aug 26 '15 at 15:00
  • The infrastructure interfaces are secondary ports and the implement of these interfaces are secondary adapters. – chansey Aug 26 '15 at 15:00

0 Answers0