Twisting The Triad

ModelViewPresenter 관련 Article 읽고 정리.

C++ 시스템의 Taligent 로부터 유래. Dolphin Smalltalk 의 UI Framework. 논문에서는 'Widget' 과 'MVC' 대신 MVP 를 채택한 이유 등을 다룬다고 한다. 그리고 MVC 3 요소를 rotating (or twisting)함으로서 현재 존재하는 다른 Smalltalk 환경보다 쓰기 쉽고 더 유연한 'Observer' based framework 를 만들 것을 보여줄 것이다.

고 한다. -_a


VisualBasic, IS/2 등에 해당.

with a widget-based system it is easy to avoid having to think about the (required) separation between the user interface and the application domain objects, but it is all too easy to allow one's domain code to become inextricably linked with the general interface logic.

it was much more that the widget system was just not flexible enought. We didn't know at the time, but were just starting to realise, that Smalltalk thrives on plugability and the user interface components in out widget framework were just not fine-grained enough.

One example of this deficiency surfaced in SmalltalkWorkspace widget. This was originally designed as a multiline text-editing component with additional logic to handle user interface commands such as Do-it, Show-it, Inspect-it etc. The view itself was a standard Windows text control and we just attached code to it to handle the workspace functionality. However, we soon discovered that we also wanted to have a rich text workspace widget too. Typically the implementation of this would have required the duplication of the workspace logic from the SmalltalkWorkspace component or, at least, an unwarranted refactoring session. It seemed to us that the widget framework could well do with some refactoring itself!


In MVC, most of the application functionality must be built into a model class known as an Application Model. It is the reponsibility of the application model to be the mediator between the true domain objects and the views and their controllers. The views are responsible for displaying the domain data while the controller handle the raw usr gestures that will eventually perform action on this data. So the application model typically has method to perform menu command actions, push buttons actions and general validation on the data that it manages. Nearly all of the application logic will reside in the application model classes. However, because the application model's role is that of a go-between, it is at times necessary for it to gain access to the user interface directly but, because of the Observer relationship betweeen it and the view/controller, this sort of access is discouraged.

For example, let's say one wants to explicitly change the colour of one or more views dependent on some conditions in the application model. The correct way to do this in MVC would be to trigger some sort of event, passing the colour along with it. Behaviour would then have to be coded in the view to "hang off" this event and to apply the colour change whenever the event was triggered. This is a rather circuitous route to achieving this simple functionality and typically it would be avoided by taking a shoutcut and using #componentAt : to look up a particular named view from the application model and to apply the colour change to the view directly. However, any direct access of a view like this breaks the MVC dictum that the model should know nothing about the views to which it is connected. If nothing else, this sort of activity surely breaks the possibility of allowing multiple views onto a model, which must be the reason behind using the Observer pattern in MVC in the first place.

- 내가 파악한 MVC 모델은 너무 얕은 지식이였나. 여태껏 그냥 Layer 단으로만 그렇게 나누어진다만 생각했지 해당 이벤트 발생시나 모델의 값 변화시 어떠한 단계로 Control 이 흘러가는지에 대해서는 구체적으로 생각해본 적이 없었던 것 같다. 화살표를 보면 Application Model -> Controller 로의 화살표가 없다. 그리고 Problem Space 의 범위도 차이가 난다.

근데, WEB 에서의 MVC 와 GUI 에서의 MVC 는 그 Control Flow 가 다르긴 할것이다. 웹에서는 View 부분에서 이벤트가 발생하여 이것이 도로 Model 로 올라간다..식이 없기 때문이다. 믿을만한 출처일지는 모르겠지만, 암튼 이를 구분하는 글도 있는듯. http://www.purpletech.com/articles/mvc/mvc-and-beyond.html

TwistingTheTriad : ModelViewPresenter

This is the data upon which the user interface will operate. It is typically a domain object and the intention is that such objects should have no knowledge of the user interface. Here the M in MVP differs from the M in MVC. As mentioned above, the latter is actually an Application Model, which holds onto aspects of the domain data but also implements the user interface to manupulate it. In MVP, the model is purely a domain object and there is no expectation of (or link to) the user interface at all.

The behaviour of a view in MVP is much the same as in MVC. It is the view's responsibility to display the contents of a model. The model is expected to trigger appropriate change notification whenever its data is modified and these allow the view to "hang off" the model following the standard Observer pattern. In the same way as MVC does, this allows multiple vies to be connected to a single model.

One significant difference in MVP is the removal of the controller. Instead, the view is expected to handle the raw user interface events generated by the operating system (in Windows these come in as WM_xxxx messages) and this way of working fits more naturally into the style of most modern operating systems. In some cases, as a TextView, the user input is handled directly by the view and used to make changes to the model data. However, in most cases the user input events are actually routed via the presenter and it is this which becomes responsible for how the model gets changed.

While it is the view's responsibility to display model data it is the presenter that governs how the model can be manipulated and changed by the user interface. This is where the heart of an application's behaviour resides. In many ways, a MVP presenter is equivalent to the application model in MVC; most of the code dealing with how a user interface works is built into a presenter class. The main difference is that a presenter is directly linked to its associated view so that the two can closely collaborate in their roles of supplying the user interface for a particular model.

Benefits of MVP

Compared with our orignnal widget framework, MVP offers a much greater separation between the visual presentation of an interface and the code required to implement the interface functionality. The latter resides in one or more presenter classes that are coded as normal using a standard class browser.

Future possibilities


Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:28:19
Processing time 0.0155 sec