This articles is presenting something quite familiar, but however not well classified and described. It is actually closer to Model2, but lacks its decoupling of the business-layer. So I label it "Model 1.5". It is meant for single developers or small teams.
A brief introduction. You will excuse me for once again telling what "MVC" is:
Mode1 - a design strategy, where everyting - the presentation and the logic are situated in one jsp/servlet, which often "posts" back to itself when data-manipulation is required.
Model2 - using the MVC design pattern:
- A presentation (view) consists of jsp's that do not modify the data - just displays it.
- A controller which handles all incoming requests, takes care of obtaining all the data from those requests, and directs them to the prespecified model components.
- A model which, provided with all the parameters, handles the business-logic (e.g. data manipulation).
Even with simplified look over the Model2, it still requires some deeper knowledge, and time, in order to create a proper controller . Let alone the use of a MVC framework.
On the other hand, Model1 cannot provide extensibility, flexibility, and even hardly provides reuse of code.
The use of Model2 for middle-sized application (say: 10-12 pages) might turn out to be unjustified. Then, what about merging the model and controller into one, pure Servlet? Here are the key points:
- JSP's are used only for presentation - no data manipulation. Thus a separation of presentation from logic is achieved. However database-queries can be run from the view provided they just select, and not manipulate data. A little less work for the model.
- All forms are posted to a particular Servlet, which handles the request parameters, generates database queries, and then returns the application to a component of the view.
- The redirect-after-post principle is thus easily implemented
- The business-layer is NOT decoupled from the web-application context, and hence creating other interfaces to it is harder.
The advantages are clear: simplicity and flexibility. The disadvantages, of course: unsuitable for large applications, and ones developed by large teams.
I'd say there is nothing wrong with that, as long as you understand the constraints you are imposing upon your app.
You are essentially rightfully saying that model 2 allows you to build applications that can grow in a controlled and scalable manner as new features get bolted on. You decided you don't need this characteristics (i.e. your app will never grow), therefore it's okay to go with model 1.x
Although you might consider this:
1. Unless you are building the app for yourself, there's little hope that the app will remain without growing one way or another
2. Setting up a model 2 framework like Struts for example really isn't a big deal. There are plenty of downloadable empty shells out there.
Once you have a base application built, back it up and reuse at will. Personally, I use model2 frameworks even for the silliest little application. I'm just not ever willing to live with the above constraint.
For a beginner, like my student (to whom I proposed using the pattern described above), setting a Struts application might be a nightmare.
The Model 1.5 applications can grow, despite in a not quite controlled manner, and not so easily.
Don't blame the architecture for the complexity, blame struts.
There are *many* simpler MVC frameworks out there.
Struts 2, stripes, Spring MVC... and also component-oriented frameworks like wicket, tapestry...
A web app made by almost any of these frameworks is much simpler to understand and to work with than a JSP "Model 1" app.
I would say it's a far better exercise having the student create the MVC framework rather than learning an existing one.
Using some patterns and a few standard mechanisms a simple MVC framework can be easily developed. Unnecessary options and the complexity of the existing frameworks will only confuse the student.