Model-View-Controller

Model-View-Controller

By using this pattern, you separate your concerns into various layers of the application,

just as you did with Data Transfer Objects (DTOs) and Data Access Objects

(DAOs) in your service layer. If you’ve been developing Java-based web applications for

a while, you’re probably familiar with some of the MVC frameworks that are available.

The same concepts apply here, but as you’ll see, they’re implemented in a way that is a

bit easier to use. Let’s look at the various components of the MVC design pattern and

see how they’re implemented.

■ Model—The model layer of the application holds the data of the application

and contains any business rules for manipulating that data. Your PRProduct

object with its fields containing values for the name and serial number is part of

your model and was generated by Service Builder. Any logic that would change

those values based on certain rules would also be part of the model layer.

■ View—The view layer of the application contains all the logic for displaying the

data to the user. Handling fields, check boxes, and other form elements, as well

as hiding or showing data, are functions provided by the view layer. You’ll create

JSPs that will handle the view layer, and you’ll see some tools that Liferay provides

that makes this easy.

■ Controller—The controller layer acts as a traffic director. It passes data back and

forth to and from the model and view layers, providing a separation of concerns.

The controller, for example, might be responsible for determining which

action a user has clicked and directing processing to the proper function to

update the model. Generally, the model and view speak only to the controller,

with the exception that the view may use objects from the model for display purposes

(such as iterating over a List to populate a table).

These three layers are pictured in figure 4.1.

How would you implement this design pattern in a portlet? The model layer is generated

for you by Service Builder from your table design. I stated earlier that your JSPs

will be your view layer. That leaves the portlet class as your controller. As you’ll see,

this design will provide a good implementation of the MVC design pattern, allowing

you to separate your concerns in a way that is maintainable and straightforward.

Liferay has subclassed GenericPortlet to provide functionality that makes it easy

to create MVC applications using portlets. This subclass is called MVCPortlet, and it

enhances the way portlets handle actions and page management. All of Liferay’s portlet

plugins are based on MVCPortlet instead of GenericPortlet, because it’s a much

better option.

What’s different? Well, MVCPortlet is a lot easier to use. You won’t have to worry

about page management anymore; you get it for free. Liferay’s MVCPortlet provides a

simple means for page management. If you want to determine what JSP to display, all

you need to do is point a render parameter called jspPage to the location of the JSP,

and that’s the page that will be displayed to the user. This functionality does several

things for you:

■ You don’t have to worry about doView(), doEdit(), or any other do method.

■ Your portlet class doesn’t need to implement any portlet-specific APIs.

■ Your portlet class is simple: all it contains is action methods.

■ If you wish, you can use any piece of the standard portlet API that you want:

MVCPortlet is subclassed from GenericPortlet, so feel free to override any

functionality for your own purposes.

One of the other things this project will have is a portlet in Liferay’s Control Panel as

an alternative to Edit mode for administrative functions.