armtuk

MVC means Model, View Controller. Not Controller who makes a Model and passes it to the View. This is the normal usage of this system in many implementations, but that's not really what MVC is is it? The Model is an independent piece that isn't tied to the Controller directly any more than it's tied to the view. The Controller is responsible for updating the Model, and the view is responsible for rendering the Model.

In a normal Web based application, the Model is in the Database which is often an RDBMS. It doesn't break MVC to have the view talk to the database, because the database is the Model. The big mistake of many ORMs is trying to represent the Model in two places, in the database and in the application server. This of course creates all the same problems as multiple master replication causes for a database product. Every transaction has to be replicated across both systems incurring a huge overhead and making transactions way longer than on a single master system leading to huge performance problems. It's pretty common sense that the best form of distributing load is to have a share nothing cluster where you put different parts of the data set on different nodes. This is in opposition to multiple master replication which puts all the same data in two places. This is good for redundancy, but bad for performance, unless your interconnect is as fast as your local storage, which is rarely the case (don't just think throughput, think latency too). Of course you can do the best of both worlds and replicate and distribute like RAID 10, but this means having homogeneous copies, not heterogeneous copies like relational data and objects.

If we think of MVC as a three legged stool as in the first, we have true MVC, but if we corrupt it, then we get Bad MVC like the second which is like trying to have a two legged stool. It doesn't work too well:



Presenting the Model is the view's job. Preparing the data for presentation is not the controller's job. The controller's job is to process user input and update the model. The model is not a transient object that's instantiated and reads data from a store to a Model object, that's a proxy. The real model is the datastore. Most RDBMSes I know have pretty good methods to update the data within them. Most Models need to do internal checking to ensure that they are sane too and aren't corrupt. This behaviour does not belong in the controller. It's part of the Model. That means database constraints and triggers.

Any framework that forces you to build the Model in the Controller and pass it to the view is a corruption of MVC and is asking for serious concurrency and performance problems. This doesn't mean however that your View cannot be started by a servlet or similar that reads data from the database into a hash and then forwards the display to a JSP or something similar. Just that to do MVC right, your controller doesn't return a Model and a View like in SpringMVC, it might decide which view to send the user to, which will then in turn access the model.

This means that we need different functionality in the view than most frameworks give I think. Some of this can be done in JSTL, but it's kind of clunky.

I'm going to read the rest of the Wicket book in the hope they get this, but I'm doubtful.