Spring Web MVC utilizes the ModelAndView class to encapsulate the M and V of MVC. The model part is simply a map of objects associated with a request. The key is the string name that you will use to access the object via the tag libraries. Placing an object with a key of “userPrefs” into the map will make the UserPrefs object available to the HttpServletRequest and eventually part of the implicit request object that is part of JSPs. In order to display any user data in a JSP it has to be part of the request object and it gets there by placing it in the Map used by ModelAndView.

In my experience with Spring Web MVC I’ve found that most form controller classes extend SimpleFormController. SimpleFormController derives most of its lifecycle from AbstractFormController, which provides us with a few interesting methods. There is one method in particular that is interesting. The referenceData(HttpServletRequest request) method returns a Map and this method is called during the showForm(…) method. showForm returns a ModelAndView object which will include whatever data is included in the Map returned by referenceData. The default implementation of referenceData returns null, so we have to override it in our class that extends SimpleFormController.

Here is some example code from my controller class which extends SimpleFormController. The point here is to provide a list of Bookmark objects to the form for a user to delete.


@Override
protected Map referenceData(HttpServletRequest request) throws Exception {
List userBookmarkList = bookmarkService.getUserBookmarks(
request.getUserPrincipal().toString());

Map model = new HashMap();
model.put("userBookmarks", userBookmarkList);
return model;
}

This is pretty simple example. It’s first getting the user from the request object. This is an authenticated session where a user has provided a login name and password. That name is retrieved from the request object and used to get a List of all of their bookmarks. The List is then put into a HashMap with the key “userBookmarks”.

After referenceData returns the Map those entries are then passed on to the view by the showForm method. We can use a couple JSTL tag libraries to iterate over the list and display each bookmark while building the form. The following is an excerpt from the view (NOTE – This is pre-Spring 2.5):

This view uses two tag libraries, one from JSTL, the other being the Spring form tag library. Within the form tags the JSTL forEach tag is used to iterate over the list of bookmarks. The list is obtained via the ${userBookmarks} variable. This calling convention takes advantage of the search order for finding request parameters used by JSTL. Part of the search includes looking in the request object that is part of every JSP. The items attribute is the object we want to iterate over, that being the object keyed by userBookmarks.

That object is the List of bookmarks we got from the business tier. By iterating over the bookmarks we have access to each Bookmark object and each of it’s fields. The checkbox tag is used to build up the HTML view of the each bookmark with a check box next to it for the user to click. When the user is done selecting bookmarks to delete the onSubmit method is called back in the controller.

So how does Spring know which bookmarks have been checked in the form? The form object bound to the form keeps track of the checked bookmarks. This form object is very simple, it encapsulates an array of Strings and provides a getter and setter for the array.


package net.anthonychaves.bookmarks.dataobject;

public class DeleteBookmarksForm {

private String[] bookmarkIds;

public void setBookmarkIds(String[] bookmarkIds) {
this.bookmarkIds = bookmarkIds;
}

public String[] getBookmarkIds() {
return bookmarkIds;
}
}

The “value” part of our checkbox contains the bookmark ID. When the checkbox is checked and the form is submitted the Spring dispatcher servlet collects all of the checked values of the same path into an array and puts them into the DeleteBookmarksForm object. The form object is then passed to the DeleteBookmarksController via the onSubmit method. We don’t have to implement the entire onSubmit method, though. The default implementation calls doSubmitAction which takes only our command object, in this case DeleteBookmarksForm, as an argument. Once we have a list of bookmark IDs to delete we can call the business tier to remove them from the database (after appropriate error checking, of course).

Spring 2.5 introduces the form:checkboxes tag which eliminates the need to use the JSTL forEach tag to iterate over the list of objects. The checkboxes tag takes care of that for you.

There is more to working with lists in Spring Web MVC than the material presented here. I’ve included a few references below in case you’re interested in finding out more. Thanks for reading and as usual let me know if you have any questions or comments!

Business logic always belongs in its own layer. Why? Business logic is the thing that makes your application what it is. It doesn’t matter how it’s dressed up – web app, desktop app, web service – the business logic accomplishes the task the user wants to perform. Business logic is your application. Because of its importance business logic should be placed in a sacred place where it will not be disturbed by presentation logic or infrastructure underpinnings – the business tier. Separating the business concerns from all other concerns buys a lot of benefits for the development team.

What if aggregate data must be displayed in multiple locations? For example, shopping cart data could be displayed on a checkout screen and also as a side bar while the user is still shopping. In an action-based framework this code would be duplicated in two different actions. It would be present in the action that generated checkout screen and again in the action that assembled the shopping view screen. Rather than duplicate the code why not make a method call into the business layer that did the same thing? The end result is the same except it separates the concerns of web and business logic.

Refactoring this code into a business tier method helps make our application more loosely coupled. Loose coupling is important for business logic because it allows for easier reuse, testability and maintanence. If the business logic is located in the action then creating a web service around it is going to be more difficult. The business logic will have to be decouple from the web action and pulled into a layer where both the web action and web service can use it. A good example of this would be a web page that displays new items available to a customer. A web page is ok but the customer would have to keep checking back for updates. An easier way to publish this information would be to make it available as an RSS feed the customer can subscribe to. Duplicating the logic to get the new items isn’t particularly difficult, but why make maintenance more difficult than it has to be? The application should be refactored to have a business layer that is responsible for getting the data which can be called by two different locations in the presentation layer (the web tier and the RSS feed creator). Testing the business logic (you’re testing, right?) and bug fixing only have to be done in one location thanks to this refactoring too.

Another quote from the thread is, “The other side of the story is that to have two separate classes, one dealing with the http/web layer (ex: UserAction) and one dealing with the business logic layer (ex: UserService) is bureaucratic.” This statement shows a lack of understanding of functional decomposition. Each module should be responsible for one and only one thing. If the web layer is for dealing with actions then actions should only be dealt with in the web layer. If the web layer is for dealing with actions then business logic should not be dealt with at the web layer. Business logic belongs where it can remain undisturbed by other concerns. Tight coupling of these concerns makes testing more difficult because it requires testing everything it once rather than testing in isolation. Because your application is only as good as the business logic the business layer should have a test suite that can be run without depending on action or presentation logic.

There are plenty of other reasons you should keep business and web logic separate. This is in no way an exhaustive list, but it’s certainly something to think about. If you’re building any professional application then business logic should always be in its own layer. Not only will your boss/team/successor thank you for it, it’s good software development and you’ll thank yourself for it too.