How do you structure your JSF application code?

[Chris Stewart]

I've written my first JSF application and I'm looking back now for ways I can improve it's maintainability and design.

Two things come to mind that I'd like a second opinion on.

First, I didn't use (except perhaps once) the JSF navigation feature. Instead, I forwarded/redirected at the Servlet level in my beans. Towards the end of the project, I ended up using the "JSF way" in a few instances because of the exception handling required with the Servlet method. I've heard a lot of people upset over the way JSF handles the URL in the browser and frankly I'm not sure if these two are related or not. I'd love to hear some opinions and experiences with this.

Second, I get the feeling that "everything is a bean" in JSF. Every tutorial I follow, every blog I read, they all make heavy use of beans in the sense that they are defined in the faces-config. I feel a lack of separation between a controller and a model. In JSF, I feel like a bean is essentially use for both, often in the same bean. It's obviously very subjective to say whether that's a good thing or not, but I do like to separate the two.

I think the second point really follows the question posed in the thread title. How do you generally structure your JSF application with respect to beans, controllers, models, and so forth?

[Tim Holloway]

Yup. JSF is about as pure an implementation of the MVC framework as anything can be that relies on the HTTP protocol can be. The model is the backing bean(s), the view is the JSF page and the controller is the JSF framework itself and its supporting taglibs - both standard and third-party. If you're doing it any other way, you're making extra work for yourself and whoever someday inherit the app won't thank you.

Yes, it really does annoy that the URLs in JSF don't bear a straightforward relationship to the work being done - and, more to the point, aren't very bookmark-able. Someday a happy solution may be found, but the major problem is that JSF is based on POST-type processing, where the POST carries not only the obvious form data, but a fair amount of JSF context as well - since you can't bookmark POST data, only URLs, well you can see that there's a problem. Browser bookmarks are really only good for GET-type requests.

I like to divide JavaBeans into 2 categories - data containers and logic containers. JSF, however, works best with a hybrid model. In that sense, you could say that it's both Model and Controller, but strictly speaking, an MVC controller is a View controller, and the logic part of a backing bean is normally only business logic. My own preference is to keep the stuff that's strictly JSF-specific to a minimum, but sometimes it's unavoidable, especially for datatable models.

In actual coarse structure, I normally have a layer of backing beans that connect to a layer of business beans (unless the business functions are fairly simple), the business beans attach to the DAO and other external services layer(s), and then the DAO layer attaches to the ORM objects. ORM objects may double as DTOs visible by the higher layers in cases where this doesn't make things too messy. Otherwise I use facades or decorators - I'm still working on an ideal solution.

In Struts, I broke the packages along the lines of business functions - for a given function, the form beans and action processors were all in the same package. JSF requires fewer objects, so (so far) I've simply put all the backing beans in the same package since one-bean-per-package is a bit much.