Java开发网 - Design Patterns of Enterprise Rich Client part 2

Topic: Design Patterns of Enterprise Rich Client part 2

1.Design Patterns of Enterprise Rich Client part 2

Posted by: polygoncell
Posted on: 2005-12-23 21:32

本文为作者原创，如转载，请注明出处及作者的blog: http://spaces.msn.com/members/polygoncell/
Anyone who want to copy&paste or reference this article, please adds my name "Jing Ge" and my blog: http://spaces.msn.com/members/polygoncell/.

我继续对上一篇文章中的模式进行了深入讨论，由于有些新的想法，就直接用英文写了。希望大家能够支持。

In the last part I have simply described the four Patterns：Autonomous View, MVC, MCP, and Presentation model and the principle of choosing them. Since the article is written in Chinese, readers who can not read Chinese please refer to the homepage of Martin Fowler for the detail information of these patterns. I just repeat here the most important principle of choice that I made in the last article. The principle is for the choice of the two patterns: MVP and Presentation Model. Martin Fowler says “it really comes down to how easy it is to do the pattern in your GUI environment and on your own personal tastes.” I think, it is not 100% correct. We should choose the Presentation Model if we have a data binding solution, for example Jgoodies binding. Otherwise MVP is the first choice.

As I use the Presentation Model, I find there is one problem with this pattern – where should the view be initialized and How to initialize the View? When we use the MVC and MVP, we can get the Controller or the Presenter and let them initialize the view. But how can we do this with the Presentation Model, since the presentation model has no reference of the view? As I think about it, I find there are two possible solutions:

The first one is using the Dependency Injection and Business Delegate Patterns. Using Dependence Injection an object, for example a presentation chooser, can be injected into the presentation model. When we want to create/get view through presentation model, the invocation will be delegated to the injected object.


public class PresentationModel {
 private PresentationChooser chooser;
 
public PresentationModel(PresentationChooser chooser) {
  this.chooser = chooser;
 }

 public View getView() {
  chooser.getView(this);
 }
}

From this sample code we can see that the PresentationModel does not need any reference of any View.

The Second one is combining the two patterns, i.e. Presentation Mode and MVP. In the normal MVP, the Presenter has references of the View and the Model, most of the functionalities are implemented in the Presenter include some function like Synchronization. As extension, we can add a reference of the model into the View, just like the Presentation Model pattern does. Now we can use some data binding framework, for example Jgoodies binding, to synchronize the view and the model, and let the Presenter do the rest work.

The UML looks like:

Since I have not found that such a pattern has been described by someone else, I call it Presentation Model Presenter(PMP). This solution can also solve the one known problem of using Presentation Model pattern: When the presentation logic goes very complex, the presentation model class goes very big, the maintenance of the code such class is very difficult. Some logics, i.e. the logics for managing the model, should be move to a new class, which is normally called XXXModelManager. Using the This new pattern, we can move these logics into the Presenter. And the result is – we got the benefit of both patterns and avert some drawbacks of them. Thanks for the power of the combination!