Model 1.5

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.