Re: [Springframework-developer] About MVC

[William G. T. Jr. <wg...@ru...>]

You seem to be describing a Portal which has two parts, 1) Portal 
Application which is responsible for aggregating Portlets (your screen 
parts) and targeting a request to a Portlet and 2) Portlet Container 
which is responsible for the lifecyle of Portlets.

Spring could be used to implement the Portal Application which would be 
very close to your Sequence Diagram and would call down into the Portlet 
Container to invoke a Portlet and get the SP.

Each Portlet is in essence a separate web app and could use the standard 
Spring MVC model with some slight modifications (e.g. only return markup 
fragment instead of a whole page).

Talk a look at Portlet API and uPortal.
http://www.jcp.org/aboutJava/communityprocess/review/jsr168/
http://mis105.mis.udel.edu/ja-sig/uportal/

later.
Bill


yan...@ne... wrote:

> All:
> 
> I read "Expert One-on-One - J2EE Design and Development" recently. It is one of the most excellent books I have ever read about enterprise app design.
> 
> But, as I think, there is a problem in its decision on MVC implementation. The proposed solution works very well in simple applications. But when it comes to complicated real application requirement, it seems it can not work properly at least according to current description. It needs extension.
> 
> The Problem:
> In such complication applications as portal, every web page (I call it "Screen" in contrast with View in the MVC) must display a lot of information. Information is grouped in several independent parts (I call it a Screen Part, SP). Views are just SPs, not Screens.
> When the user submit a form (or link to another Screen). Another Screen will be displayed as a response to the input. This new Screen may have a SP display the result of the user action and may have other SPs unrelated to this user action. The spring framework works very good at creating the result SP while not provide good mechanism to produce other unrelated Screen.
> I will describe it in detail.
> 
> 1. Let's examine what the "model" means. 
> The "true", traditional model refers to domain model (DM). 
> As explained in the "The MVC Triad" part of the book, "A model contains data displayed by a view. Models in web applications (as opposed to "true," traditional MVC) are usually dumb storage objects, such as value objects, that represent the result of a complete business operation. Once a controller completes its processing and selects a view to generate content, the model should contain all the data to display. " (I call this kind of model in web app view model, VM).
> 
> 2. Who create the VM?
> As DM always exists in the back ground, the only problem remain is who should take the responsibility to create the VM from DM. 
> (Assumption: Every View has a VM. Every VM could be displayed by several kind of View.)
> A user action (submission a form or following a link) is mapping to a controller. Does the controller know what the user expects to see in the result Screen? No. The controller only knows the result of the action (which is important in the result Screen selection). It doesn't know all other information the user expecting (e.g. information's unrelated to this action). That is a controller should only create the model for one view (a SP in the result Screen). So let the controllers create all the VM for the result Screen is impossible.
> 
> My solution:
> Principle: Seperate the action controller with the view controller.
> The action controller's responsibility is to process the user action and return the result model (contains only data related to this action) and the result Screen name.
> The view controller's responsibility is creating the VM from the DM for a SP.
> 
> I agree with the book that the controller returned with a model and name of "view". But the model should only contain information related to the user action. And the name of "view" should be the name of Screen Model. But this controller is only action controller. 
> Then use a ScreenModelResolver (rather than a ViewResolver) to resolve the Screen Model name to a Screen Model which contains a set of SP Model. Every SP has a view controller to create the VM for this SP. The Screen Model calls all SPs' controller to create their VMs.
> Then use a ScreenResolver to get the concrete Screen and forward the request to this concrete Screen to create the response (by using any mechanism described in the book) and sent back to user.
> 
> As depicted in the attach files.
> 
> What about your opinion? 
>