Question about MVC

[Zach Young]

I have been working for the past couple of days on a project. I have been researching and studying different methods for developing my project. This project is a very simple order entry system. From my research I have discovered many new terms and concepts that have really got me confused. First of all my system will be running on an ISP that is providing a tomcat server. Jakarta-tomcat-4.1.30 java version "1.4.2_04". This is a public tomcat server opposed to a private server. Also this will have a MYSQL database. Although this may not be the correct form for some of the following questions I will post it to others.

The first concept that I have learned about is MVC which is a design pattern. My understanding is that I would create my order entry form in view. This view/form would call the controller which determines what must be done from the information entered into the form. The controller would then hand this information to the model. The model is used to insert the data into the database. The model also contains business logic.

Should I use this design pattern for a simple order entry system? This will always be a web application. Which design pattern should I use? Why wouldn�t I just create a jsp form and then a servlet to insert the data into my table? Would this be a MVC 1?

Is an insert in the model servlet really business logic? What are other types of business logic?

If I should use MVC should I consider struts or another framework? Or is this making the project more complicated?

[Pradeep bhatt]

From maintenance and extensibilty point of view Model 2 is better.

[Stan James]

The first concept that I have learned about is MVC which is a design pattern. My understanding is that I would create my order entry form in view. This view/form would call the controller which determines what must be done from the information entered into the form. The controller would then hand this information to the model. The model is used to insert the data into the database. The model also contains business logic.

I liked that paragraph just fine. On relatively simple CRUD (Create Retrieve Update Delete) applications the business logic gets pretty thin. But I'd still keep the MVC components and data accessor layering just to keep each class small and simple, focused on one thing.

There is still a lot of flexibility in design. Struts has a single front controller servlet that delegates work to commands - action classes. It's also valid to build a servlet per page with dedicated work classes per servlet.

I made my own single front controller servlet at work; at about 100 lines of code it does command delegation and declaritive security all from configuration so I never touch it to add new pages and such. Consider writing your own as an exercise. It's not too hard and then you'll really understand the considerations that go into it.

[Ilja Preuss]

Originally posted by Zach Young:
This will always be a web application.

How do you know? In my experience, you just don't. Software that gets used gets extended, often for much longer than expected, and in directions never anticipated. Prototypes for a single customer that were supposed to be thrown away after a couple of months develop into systems that grow over the years and get installed in thousands of places, on platforms that you would never have dreamed of.

My advice is: Don't trust anyone saying that you don't need a flexible design. If the system proves to be worth its money, you will need it.

[Ben Souther]

Would this be a MVC 1?

There is no MVC1 or MVC2.
There is Model1 and Model2.
Model2 is MVC, Model1 is not.

There are several reasons to use MVC in a web app (even a simple one).
The first two were already mentioned (expansion and maintenance).
The most important reasons for me are testing and development speed.

Building your core methods in plain old java objects (POJOs) allows you run them from the command line before you start fussing with web-specific code. I've found that small amount of extra time it takes to write the extra code involved with MVC is more than made up for when I can start the web coding knowing that the core methods already work.

Additionally, these same methods can be called from unit or integration scripts when regression testing later. It's also helpful to be able to run the main method tests when debugging an app that's already been released and is having problems. You'll know right away whether the problem is on the web side or the DB side.

[Stan James]

I love this guy:

Building your core methods in plain old java objects (POJOs) allows you run them from the command line before you start fussing with web-specific code. I've found that small amount of extra time it takes to write the extra code involved with MVC is more than made up for when I can start the web coding knowing that the core methods already work

I can't tell you how profound and good that idea is.

Wander up to the JSP and Servlet forums. Ben moderates up there I think. And check out his wonderful examples linked from his signature.
[ November 21, 2005: Message edited by: Stan James ]

[Zach Young]

If you have a database change for example adding a column. With the Model2 design you would have to change it in three or more places?

Does a .net programmer use these same design patterns?

[Ilja Preuss]

Originally posted by Zach Young:
If you have a database change for example adding a column. With the Model2 design you would have to change it in three or more places?

If that columns also needs to be shown and edited through the web interface, yes.

But if only the data model changes (say, a table gets split into two, or you need to support XML files in addition to a database), you only need to change the persistence layer (if you have one - it isn't part of the MVC architecture).

If only the business rules change (for example the way a value gets calculated), only the Model needs to be touched.

If only the presentation changes, you only need to change the View.

Etc. pp.

Does a .net programmer use these same design patterns?

Yes, as well as Smalltalk, Ruby, Phyton and all other OO programmers.