More Group Sites
Education Books
School Rankings
Jobless Net
Better Home
Welcome Guest! To enable all features please Login or Register.



Go to last post Go to first unread
#1 Posted : Sunday, 8 November 2009 9:48:00 AM(UTC)

Rank: Administration


Groups: AcademicCoachingSchool, admin, Administration, BookSeller, CatholicSchool, CoachingAdult, CoachingProfessional, CoachingSports, ExtraCurriculumCoaching, IndependentSchool, Moderator, MusicTeacher, PrivateSchool, PublicSchool, SelectiveSchool, tutor
Joined: 23/11/2008(UTC)
Posts: 522

Model-View-Controller (MVC) Design Pattern

In a software application, model is the business logic or data store, view is the user interface. Because the key flow of information is between the data store and the user interface, naturally we incline to tie model and view together (the view and business logic are combined in a single object) to reduce coding and to improve application performance. However, we should decouple the view from the model for the following reasons:
1. The coupling between the data and user interface means more effort in implementation, testing and maintenance as the user interface tends to change much more frequently than the data storage system. Every time you change the user interface, you have to modify the object containing business logic. This is likely to introduce errors and require the retesting of all business logic after any user interface change.

2. You may need to have different view formats on the same data such as spreadsheet view, chart view or other formats using style sheets. You need to change the views without touching the business logic.

3. User interface code tends to be more device-dependent than business logic. We may need to have different types of the user interface on the same data such as a rich-client user interface on Windows or Linux, a thin-client web interface on a web browser, or a user interface on an embedded device. A clean separation of the view and the user interfaces helps the migration from one UI to another.

4. We need to separate the user interface design from the implementation of the complex business logic as they require different skill sets. Normally a person doesn't have both skill sets.

5. It is more difficult and time-consuming to create automated tests for user interfaces than for business logic. Testing user interfaces either requires tedious and error-prone manual testing or testing scripts that simulate user actions. Separating the model from the presentation logic allows the model to be tested independently of the presentation and reduces the number of user interface test cases.

6. When testing components are highly interdependent, it is hard to isolate the problem to a specific component. Also it is complicated to set up interdependent components for the testing.

The Model-View-Controller (MVC) design pattern separates the application domain, the presentation and the actions based on user input into three separate classes. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate. In a web application, the view is the web page (html code rendered in the browser) and controller is the server-side components handling the HTTP request. In a rich-client application using latest Windows Presentation Foundations (WPF), the view can be a Windows Form in XAML and the controller can be Windows Forms Controls. However, in Microsoft Foundation Class Library (MFC), the view and controller are combined as one object "View" in Document-View pattern. The document in Document-View pattern corresponds to the model role in MVC.

Unlike the view or the controller which depends on the model, the model doesn't depend on either the view or the controller. So the model can be built and tested independently.

Two variations of MVC
Passive model
The controller modifies the model and then informs the view that the model has changed and should be refreshed. for example, the HTTP protocol does not detect changes in the data on the server. A refresh is required to retrieve the asynchronous data change.

Active model
The model notifies the views to refresh the display without the controller's involvement. If the user changes data in one view, the model updates all other views of the data automatically. To keep the decoupling of the MVC, Observer (publish-subscribe) Pattern is used to inform the view the state changes of the model. Each view implements the Observerinterface and registers with the model as an observer. The model tracks the list of all views which subscribe to changes. When a model changes, the model iterates through all registered views and notifies them of the change. The model never requires specific information about any views. Similarly the controller can also be implemented as an observer if it needs to be informed of model changes (e.g. enabling/disabling a button). If there are many views, we may need to define multiple subjects, each of which describes a specific type of model change. Then each view can only subscribe to types of changes which are relevant to the view. Keep in mind that the model may need to batch multiple updates into a single notification to the view if the model undergoes frequent change and the view falls behind (is flooded with) update requests.

See also Model-View-Controller (MVC) in ASP.NET.

Edited by user Sunday, 8 November 2009 10:33:11 PM(UTC)  | Reason: Not specified

Rss Feed  Atom Feed
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.