Question about MVC and modeling use cases

[James Jurach]

I have a question about the proper pattern which to use when modeling what I expect should be straight-forward and common concepts in web application development.

I have requirements in the form of use cases. If I were to model this with an MVC pattern, I would have a request which gets directed from a view to a controller, which effects changes in the model, pulls whatever from the model the next view will need, and then forwards to a view. Here is a simplistic representation:


The use cases I have are reasonably focused on a business process. The use cases describe a form (view) which produces inputs for the business process, and then the behavior of the business process once the form is submitted. A series of these use cases effectively describe the steps in a wizard.

What I find if I were to model this as MVC, is that half of the processing in a given controller call would be for the business process of a use case, but then the next half of the controller call would satisfy the requirements for the view in the subsequent use case. In other words, the functionality in my controllers are split between two different use cases; there is not a clean division between 2 use cases and their associated model elements.

I want a standard pattern with two separate elements: one for handling the prior request, and a separate one for preparing the next view. This would allow me to decouple the 2 processes in my model. Here might be a representation of what I'm talking about:


I see in Spring WebFlow, there is a concept of a "render-action" which probably does what I need, but what I'm looking for is a well-developed pattern which I can invoke in my analysis. Is this de-coupling expressed in the Application Controller pattern? Does anyone have examples of stereotypes which might be useful for these elements?

[Stan James]

I don't know about Swing, but I've written and used several "front controller" implementations where all requests come into one servlet controller. It gets an identifier from the request (hidden form field(s), part of the URL, etc) and uses that to look up a) a POJO handler for the request and b) the default next page to send back. The handler can override the next page; the application controller or flow controller in that link would be fine to make that decision. A state machine kind of thing might be nice.

See Post Redirect Get for a nifty way to implement "forward" to another page after a POST. It also makes the back button work more naturally without double posting.

Any of that fit your app?
[ December 10, 2007: Message edited by: Stan James ]

[Ilja Preuss]

Originally posted by J Jurach:
What I find if I were to model this as MVC, is that half of the processing in a given controller call would be for the business process of a use case, but then the next half of the controller call would satisfy the requirements for the view in the subsequent use case.

Uh, this sounds wrong to me - or at least not at all like MVC. In MVC, the sole responsibility of the controller is to decode the incoming request in terms of the business model. It's the model's responsibility to do the actual business processing, and the view's responsibility to encode the result in terms of the presentation layer.

So it sounds to me as if your controller implementation might have way too much knowledge of business rules here.