4 Answers
4

Diagrams are useful to help visualize data flow. The data is the foundation of virtually every program. Well done UML shows you where the data is stored (The model), what is looking at it (the controller), and how it might be presented (the view).

A concrete example of an MVC system might be a blog application. The data such as the blog entries, comments and such might be stored into a database. That's the Model portion. The view portion would be a set of routines which construct the html for the pages. These would not be complete, they would just be a framework, so if they were run without inputs, they would produce a few static visual elements, and some empty boxes. They are responsible for the aesthetic presentation of the content.

The controller would tie the two together by requesting data from the database, and handing it to the html routines for display, as well as accepting input from the user via the html pages, and making further data display requests.

An important aspect about this paradigm is that the interfaces presented by both the view framework and the database can be general. If the method for getting an article is always getArticle(ArticleID), it doesn't matter how the backend is implemented, be it an SQL database, a hash db or a set of flat files. All that needs to happen is that the raw article data is handed over.

Equally, the view software need only be able to handle the raw data. This is one of the reasons why CSS is important, and idea of markup is important. If your article data only has semantic markers, like paragraph, division, and so on, and avoid naming fonts or colors or other aesthetic attributes, then you can use the same interfaces for a view which handles the aesthetics completely differently. For instance, it could render it into braille, or speak it.

I hope this helps and isn't just another recapitulation of other explanations you have read.

It's kind of strange question. One of the main characteristics of design patterns is the context in which they are applied. In my opinion, you don't start with a design pattern, you start with a context.

OK, let's say, for the sake of argument, MVC is what you need. What are you building? Web application? In this realm, the toolbox is either a framework or a set of components, be it Struts, Spring MVC, Rails or Zend (or hundreds of others). In most cases they already incorporate MVC and you need to follow a prescribed way of doing things so that you don't break MVC concepts.

I know. It is a strange question, but I am not sure yet how to make it clearer. One additional aspect might be if the application needed to be implemented under multiple systems, like Mac OS X, iOS, & the Web. MVC promises, in part, to break the implementation up such that there can be some shared elements and everything would not need to be written from scratch on each system.
–
ericgorrMar 7 '11 at 2:14

1

@ericgorr I am not sure MVC makes such a promise at all. What you need is a cross-platform programming language. You mentioned Mac OS X, iOS & Web. Take a look at Cocoa, it may point you into the right direction: en.wikipedia.org/wiki/Cocoa_(API)
–
Yuriy ZubarevMar 7 '11 at 3:58

(This isn't a direct response to your question about design tools, but is instead a response to your comments about cross-platform development with MVC.)

The MVC pattern does separate the data and its closely-associated logic (the Model) from the business logic (the Controller) from the display logic (the View).

As such, when programming for OS X and iOS, you'll be able to use the exact same Model design and code, require very minimal changes to the Controller code, leaving most of the changes at the View end.

Adding in the web, if you used the Cappuccino Web Framework or GNUstepWeb there'd be more changes on the Model end, but the MVC separation would still allow much of the Controller code to be the same or similar.