Question

Being pretty unfamiliar with design patterns and architecture, I’m having trouble explaining to others exactly how my latest application is designed. I’ve switched between thinking it’s a pure n-tier, pure MVC and n-tier with MVC in the presentation layer. Currently I think the latter is correct, but I want thoughts from more experienced developers.

How it works:

1. Browser sends HTTP request to Tomcat. Maps the request via web.xml to a servlet (which I call controller)
2. The controller instantiates one or more business object and calls methods on these, i.e. customerBO.getById(12) which again will perform business logic/validation before calling one or more DAO methods, i.e. customerDAO.getById(12). The BO returns a list of CustomerVO’s to the controller
3. The controller prepares attributes for the view (JSP) (request.setAttribute("customers", customers);) and chooses a .jsp file to use which in turn will iterate the list and render XHTML back to the browser.

Structure (my proposal/understanding)

Presentation tier: currently using what I think is a MVC web-implementation: servlets (controllers), jsp (views) and my own implementation of OO XHTML forms (ie. CustomerForm) lies here. It should be possible to use a Swing/JavaFX/Flex GUI by switching out this presentation layer and without the need to change anything on the layers below.

Logic tier: Divided into two layers, with Business Objects (BO) on top. Responsible for business logic, but I haven’t found much to put in here besides input validation since the application mostly consists of simple CRUD actions… In many cases the methods just call a method with the same name on the DAO layer.

DAO classes with CRUD methods, which again contacts the data tier below. Also has a convertToVO(ResultSet res) methods which perform ORM from the database and to (lists of) value objects. All methods take value objects as input, i.e. customerDAO->save(voter) and return the updated voter on success and null on failure.

Data tier: At the bottom data is stored in a database or as XML files. I have not “coded” anything here, except some MySQL stored procedures and triggers.

Questions (besides the one in the title):

1. The M in MVC. I’m not sure if I can call this n-tier MVC when the models are lists/VO’s returned from business objects in the logic tier? Are the models required to reside within the presentation layer when the controller/view is here? And can the form templates in the presentation layer be called models? If so; are both the forms and lists from BO to be considered as the M in MVC?
2. From my understanding, in MVC the view is supposed to observe the model and update on change, but this isn’t possible in a web-application where the view is a rendered XHTML page? This in turn leads me to the question: is MVC implemented differently for web-applications vs. regular desktop applications?
3. I’m not using a Front Controller pattern when all HTTP requests are explicitly mapped in web.xml right? To use Front Controller I need to forward all requests to a standard servlet/controller that in turn evalutes the request and calls another controller?
4. The Business Layer felt a little “useless” in my application. What do you normally put in this layer/objects? Should one always have a business layer? I know it should contain “business logic”, but what is this exactly? I just perform input validation and instantiate one or more DAOs and calls the appropriate methods on them…

I realize there is MVC frameworks such as Struts for Java, but since this my first Java web-application I tried to get a deeper understanding of how things work. Looking in retrospect I hope you can answer some of the questions I stumbled upon.

Answer 1

I’m not sure if I can call this n-tier MVC when the models are lists/VO’s returned from business objects in the logic tier

Those are perfectly good models. I also consider the ActionForms in Struts to be models. ActionForms are what Struts uses to represent/model HTML forms.

in MVC the view is supposed to observe the model and update on change, but this isn’t possible in a web-application

Yep, and that is a matter of debate as to whether you can have true MVC with web-applications.

Should one always have a business layer?

It depends on the type of application. Some applications are database-driven, and are essentially a UI for the database. In that case, there’s very little business logic required.

Data Tier:

The stored procedures aren’t really part of the data tier code. You should be creating data access objects (DAOs) which are called by the business objects. The DAOs call the stored procedures. Further, the DAO interfaces should give no hint to the business objects as to where the data is stored, whether that be a database or file system or from some web service.