Re: Implementing Model-View-Controller

One first question you should do to yourself is: How big is this system?

This question is important because this can make you choice from two different approuches...

1) If the system is small and you just need to show the contents of a database, you can stick to the MVC used by struts, or others... wich mean that the Model object is the database encapsulation.

2) OTOH, if the system is supposed to be a little bigger, and you're not just showing the contents of the table, but you have to deal with business rules you probably want to create a more sofisticated design...

In this design, you would split your system in two parts, one as a Service Provider that would provide the needed services to retrieve and save the information, so you can implement multiple interfaces, or interface with other systems (see Web Services Architecture in w3c website)...

The not-so-obvious implication is that the Model object will not necessarly represent the plain table, but could also include some calculated information, some object's relationships.

Now to the implementation:

The main key to MVC is a magic keyword named: "event". The key is... When the model is changed, it notifies the changes, so if the model is changed by the Controller (I mean, loading the data) the UI is updated, and if the UI changes the Model, the controller can be notified and do some extra calculation (I mean, sum the values and set the total value in the model and the UI will be notified).

The big difference is that when you want to fetch the data to send to your service, you will not traverse all the components getting the values, the model will be already in the format you need to pass to the service, thus, reducing the complexity of the user interface.

daniel

Comment on Re: Implementing Model-View-Controller

Replies are listed 'Best First'.
Some remarks on the difference between traditional MVC and web-MVC (was: Re^2: Implementing Model-View-Controller) by Joost (Canon) on Jan 05, 2006 at 16:39 UTC
1) If the system is small and you just need to show the contents of a database, you can stick to the MVC used by struts, or others... wich mean that the Model object is the database encapsulation. True, most MVC-for-the-web frameworks assume most of the model is implemented using an object-relational system, but struts does not mandate that. In fact, struts (like most other MVC systems I've seen) doesn't even have a built-in oo-relational library, although it does make some assumptions about your model's API. In short, you are typically free to design your model classes in any way you want (but see below). The main key to MVC is a magic keyword named: "event". The key is... When the model is changed, it notifies the changes, so if the model is changed by the Controller (I mean, loading the data) the UI is updated, and if the UI changes the Model, the controller can be notified and do some extra calculation (I mean, sum the values and set the total value in the model and the UI will be notified). Yes, and this is exactly where most web-MVC systems do things very differently compared to traditional GUI MVC systems, which tend to use Observer pattern or callbacks to link Model and View. First off, since the web mostly works with HTML pages that can only be updated via request/response actions (I'm ignoring flash), you can't really have a model update the view's output directly. Also, there are so many possible views that updating them all would be very inefficient. What tends to happen is that for each request, after the model has been updated, the view just queries the relevant model objects and generates new HTML/XML/whatever output. The exception to this is caching; cache-invalidation can sometimes handled by observing the model (however, in this case the observer responsible for clearing the cache is usually not the view or controller). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: Some remarks on the difference between traditional MVC and web-MVC (was: Re^2: Implementing Model-View-Controller) by ruoso (Curate) on Jan 05, 2006 at 16:44 UTC
First off, since the web mostly works with HTML pages that can only be updated via request/response actions (I'm ignoring flash), you can't really have a model update the view's output directly. Also, there are so many possible views that updating them all would be very inefficient. Unless you get serious about AJAX (many people bet on this). In theory, you can implement the entire MVC in JavaScript (client-side) and have your server acting just as a Web Services provider. In fact, XForms is just that, the only problem is that it still isn't supported by the web browsers.. daniel	[reply]
Re^2: Some remarks on the difference between traditional MVC and web-MVC (was: Re^2: Implementing Model-View-Controller) by dimar (Curate) on Jan 05, 2006 at 20:15 UTC
Yup. In fact there is work underway now on complete templating, database persistence and state management using only the browser and Javascript. Here are some links relating to what ruoso said: Javascript-only Templating and MVC framework. Ajax Massive Storage System (supposedly simulate a database without RDBMS or web server). The point is that "offline AJAX" is a buzzword to be looking out for. Another buzzword "serverless AJAX" might become popular. In fact, with JSON, you can have "offline AJAX without XML" (which is ironic, since XMLHTTP is what started this whole bandwagon in the first place). =oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV	[reply]
Re^3: Some remarks on the difference between traditional MVC and web-MVC (was: Re^2: Implementing Model-View-Controller) by ruoso (Curate) on Jan 06, 2006 at 18:16 UTC
Re^2: Some remarks on the difference between traditional MVC and web-MVC (was: Re^2: Implementing Model-View-Controller) by Joost (Canon) on Jan 05, 2006 at 17:06 UTC
Unless you get serious about AJAX (many people bet on this). While you can certainly craft stuff on top of AJAX that behaves like a callback system, it's still running on top of HTTP, i.e. request/response pairs originating from the browser. That means you're still just polling for data from the client as soon as you need any information from the server side. You're not pushing data to the display as you do in traditional GUI applications, where the view also knows a lot about the state of the display. Actually, my guess is that the more AJAX technology you're using, the more you'd have to focus on plain output & http caching if you want to get any kind of performance (instead of generating one HTML page, you're generating lots of XML fragments). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^3: Some remarks on the difference between traditional MVC and web-MVC (was: Re^2: Implementing Model-View-Controller) by ruoso (Curate) on Jan 05, 2006 at 17:22 UTC


"be consistent"
	PerlMonks