GRASP: Controller architecture, correct and wrong.
-
I've developed on an application for quiet long now, and it consist of 2 sub systems, 1 for Marketing and 1 for Management. They have an seperated DB each. Now I have an UI that have to pick information in both databases, and I wondered if my controller pattern was correct, since I somehow got the idea that a UI that have connection to both Controller Facades, must be somehow incorrect? My original setup was like this:
\[UI\]------Controllers------
\[Business Logic\]------Datacontext------
MarketingDB | ManagementDB
I don't know if it give you any sense? The controller on the drawing consist of the 2 controllers described above. Would it be right to make an on-top controller and call that one FrontController, so ALL UI's are connection to the FrontController no matter if they are Marketing UIs or Management UIs? Imo that gives you the ultimate of low coupling between UI and business layer, and lowest coupling between the Controllers and the UI layer, but I don't know if this is 'correct' or wrong? What is your oppinion??? I have two drawings to show the concept I wanted to do: http://img192.imageshack.us/i/controllerdomaincontrol.jpg/[^] ONLY FrontController: http://img62.imageshack.us/i/controllerfrontcontroll.jpg/[^] Which one would you prefer as correct architecture? And why?
-
I've developed on an application for quiet long now, and it consist of 2 sub systems, 1 for Marketing and 1 for Management. They have an seperated DB each. Now I have an UI that have to pick information in both databases, and I wondered if my controller pattern was correct, since I somehow got the idea that a UI that have connection to both Controller Facades, must be somehow incorrect? My original setup was like this:
\[UI\]------Controllers------
\[Business Logic\]------Datacontext------
MarketingDB | ManagementDB
I don't know if it give you any sense? The controller on the drawing consist of the 2 controllers described above. Would it be right to make an on-top controller and call that one FrontController, so ALL UI's are connection to the FrontController no matter if they are Marketing UIs or Management UIs? Imo that gives you the ultimate of low coupling between UI and business layer, and lowest coupling between the Controllers and the UI layer, but I don't know if this is 'correct' or wrong? What is your oppinion??? I have two drawings to show the concept I wanted to do: http://img192.imageshack.us/i/controllerdomaincontrol.jpg/[^] ONLY FrontController: http://img62.imageshack.us/i/controllerfrontcontroll.jpg/[^] Which one would you prefer as correct architecture? And why?
I prefer front controller because by adding a layer you can abstract your sub controllers and stimulating immagination
Piccadilly Yum Yum
-
I prefer front controller because by adding a layer you can abstract your sub controllers and stimulating immagination
Piccadilly Yum Yum
-
But won't it just be another class class with duplicated code, containing all the method's from sub-controllers? Or are there any smart way to do it?
It depends on what is the job of controllers, your architecture is not the only possible, i post a fragment from wikipedia about architectures : Architecture description languages Architecture description languages (ADLs) are used to describe a Software Architecture. Several different ADLs have been developed by different organizations, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga), and ByADL (University of L'Aquila, Italy). Common elements of an ADL are component, connector and configuration.
Piccadilly Yum Yum
