Musings: MVC Front Controller/Command and Controller Strategy

Question

Hi,
I am currently taking my first shot at implementing the Front Controller pattern, the Command and Controller Strategy flavor, in Java. When applying the pattern, my chosen point of focus is achieving as much isolation as possible of Client-specific implementation details from the rest of the framework (Web-based framework Clients, Swing-based framework Clients, queueing-based framework Clients, etc.) However, I am running into a lot of (apparent?) inconsistencies when it comes to CCS discussions "out there", so I have a feeling that perhaps I have misunderstood the Front Controller/Command and Controller Strategy pattern. Maybe the MVC gurus out there would have some thoughts on the matter.
My issues:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?
Any comments appreciated...
Thanks,
Gary

Answer 1

gniemcew wrote:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?It is hard to tell without reading the actual discussion, but my guess is that the posters were either conflating or being loose with the distinction between a FrontController and an ApplicationController. The former is (normally) intimately tied to the actual view being used (HTTP, Swing, etc.) whereas the ApplicationController typically is not. Both are involved in dispatch and event processing. The former normally renders a view whereas the latter does not.
gniemcew wrote:
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.Generic is fine. However, you can become generic to the point where your Request and Response interfaces are only acting as "marker" interfaces (think of java.io.Serializable). Writing a truly generic controller is possible, but personally, I have never found the effort justified.
gniemcew wrote:
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).A given service (if you ascribe to SOA) should be the fundamental unit in your architectural design. A good application controller would be responsible for determining how to dispatch a given Command. Whether a Command pattern is used or whether service methods are invoked directly from your FrontController, the ApplicationController should enforce common service aspects. These include authentication, authorization, auditing, orchestration, validation, logging, error handling, just to name a few.
The ApplicationController should ideally offload these aspects from a given service. The service would indicate how the aspects are to be applied (e.g., strong authentication required, x role required, fetching of existing process state, etc.) This allows services to be developed more quickly and to have these critical aforementioned aspects developed and tested centrally.
Your FrontController, in contrast, is responsible for transforming whatever input it is designed to receive (HTTP form data posts, XML-RPC, etc.) and ensure that it honors the contract(s) that the ApplicationController establishes. There are no cut-and-dry decisions though about when a given piece of functionality should be ApplicationController or FrontController. Take error handling. Should I emit just a generic ServiceException or allow the FrontController to decide what to do with a more concrete checked exception? (The FrontController, in any case, should present the error to the user in a manner dictated by the protocol it serves).
gniemcew wrote:
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.See above. Yes. However, the ApplicationController could easily 'hide' details about the failure. For example, any number of exceptions being mapped to a generic DataAccessException or even more abstractly to a ServiceFailureException. The ApplicationController could indicate whether the failure was recoverable and/or populate information necessary to speed up production support (e.g., mapping exceptions to error codes and/or providing a primary key in an error audit log table for support to reference). A given FrontController would present that information to the user in the method that makes sense (e.g., error dialog for Swing, error page for HTML, etc.)
gniemcew wrote:
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.See comment on marker interfaces above. Nothing, however, stops you from requiring a certain sub-type in a given service method. You can still pass in the interface and validate the proper type by an assert statement (after all, in the vast majority of situations, the proper service method should get the proper instance of a given Request object). IMO, the FrontController would create the Command instance which would be passed to the ApplicationController which would dispatch and invoke the proper service method. A model response would be received by the FrontController which would then render the appropriate view.
gniemcew wrote:
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?There are distinct kinds of flow management. For example, orchestration (or BPM) is properly at either the service or ApplicationController layers. However, determining which view to display is properly at the FrontController layer. The ApplicationController should receive a Command (with a populate Request) and return that Command (with a populated Response). Both the Request and Response are fundamentally model classes (within MVC). The FrontController is responsible for populating the Request and/or Command and rendering the Response and/or Command. Generic error handling is usually centralized for both controllers.
gniemcew wrote:
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?I am not 100% sure of what you are getting at here. However, it seems to be the method by which commands are dispatched. They are in effect allowing a FrontController to dictate which of n ApplicationControllers should receive the request. If we allow a FrontController to directly invoke a service method, then the ApplicationController is simply a centralized framework that should always be invoked for each service method (enforced via AOP or some other mechanism). If there is a single, concrete ApplicationController which handles dispatch, then all FrontControllers communicate directly with that instance. It is really just a design decision (probably based on your comfort level with concepts like AOP that allow the ApplicationController to exist solely behind the scenes).
I might have totally missed your questions, but those are my thoughts on a Monday. Best of luck.
- Saish