D
Dave Veeneman
I'm new to 3-tier architecture, and I am looking for some advice on how to
implement it in C#.
I am creating an app with a Presentation layer, a Domain layer, and a
DataServices layer. There is also an Application Services layer that sits
between the Presentation and Domain layers. This layer contains controllers
that act as intermediaries between the Presentation and Domain layers. It is
included to provide additional indirection, so that I don't end up wiring my
presentation objects directly to my domain objects.
The UI is an MDI interface similar to Microsoft Outlook. Each task area has
a separate MDI child form that is loaded into the parent when the task is
invoked. When a child form is loaded, its controller is instantiated in the
Application Services layer. The child form communicates with the controller
to get its work done.
Here's my question: Should the child form communicate with its controller
directly, or should it pass its requests through the parent form? On the one
hand, there are fewer lines of communication if the child form only needs to
know about its parent. On the other hand, if the parent has to manage
lifecycle and communications for several different controllers, the parent
starts looking bloated to me.
On the whole, it seems simpler to have the parent only be responsible for
loading its child. The child then instantiates its controller and
communicates directly with the controller, and closes the controller when it
is closed. The child notifies the parent of its events as needed.
Is there any strong reason not to follow this approach?
implement it in C#.
I am creating an app with a Presentation layer, a Domain layer, and a
DataServices layer. There is also an Application Services layer that sits
between the Presentation and Domain layers. This layer contains controllers
that act as intermediaries between the Presentation and Domain layers. It is
included to provide additional indirection, so that I don't end up wiring my
presentation objects directly to my domain objects.
The UI is an MDI interface similar to Microsoft Outlook. Each task area has
a separate MDI child form that is loaded into the parent when the task is
invoked. When a child form is loaded, its controller is instantiated in the
Application Services layer. The child form communicates with the controller
to get its work done.
Here's my question: Should the child form communicate with its controller
directly, or should it pass its requests through the parent form? On the one
hand, there are fewer lines of communication if the child form only needs to
know about its parent. On the other hand, if the parent has to manage
lifecycle and communications for several different controllers, the parent
starts looking bloated to me.
On the whole, it seems simpler to have the parent only be responsible for
loading its child. The child then instantiates its controller and
communicates directly with the controller, and closes the controller when it
is closed. The child notifies the parent of its events as needed.
Is there any strong reason not to follow this approach?