JSF Front End Architecture

[isbajxw]

Hi,

We are using JSF at the front end. Our consultant is trying to get us to break the backing bean into three different types of beans:
1. Model Bean, typically session scope.
2. Backing Bean, UI data plus action listener logic, typically request scope.
3. Controller Bean, action methods only, typically request scope.
This idea comes from the following blog post: My Link.

I understand that Seam does not do it this way. What is the recommended approach? Do you have a separate controller bean? Are model bean managed?

I appreciate any input.

Thanks,
Jin

[cosmo]

One of the many benefits to work with SEAM is that it relieves many of the JSF constraints, while keeping and/or improving its benefits, so you can mainly focus on domain problems and choose the architecture you are more comfortable with without configuration overheads. For instance, in most cases, JSF beans are not necessary, because you can reach SEAM components directly from a xhtml page without any effort, so pure JSF applications can be simplified.

In my case, as I come from Struts, I normally feel comfortable with a SEAM POJO(formerly action) acting both as a controller and backing bean per xhtml page, with model beans being just entity beans(formerly form). Also another component is in charge of persistence services or interact with other systems. Notice that action and service components could be also simplified in an unique tier, so it's up to you to find the balance.

For more details, I recommend you to take a look both at the documentation and the examples that come with SEAM package and you will notice the power and simplicity that this framework brings.

[lvdberg]

Hi,

It all depends on your objectives. If it is your intention to use Seam, start with hiring another consultant  ;-) because Seam helps you to clean up this additional partitioning (sub-layering in the View) substantially. Basically you should think in maintenance and splitting up the backing beans leads to an impressive, theoretically correct, but not easily maintainable application. 

This doesn't mean you shouldn't layer your application, but do it where it is really needed and not only because the consultant says so In our case the motivation is always re-use and maintainibility.

I always use a domain-model layer (where all my business classes and utilities reside), this is directly based on the Domain Driven design by Eric Evans. I have implemented all utilities (factory, repository , service and validators) as Seam beans in different scopes (for instance I have generic repositories which are application scoped and accessed as List-Of-ValueObjects with the unwrap -annotation). I do NOT annotate my domain model Entities  with Seam-annotations (Name etc.) . Although not intrusive, we reuse the domain model in other project and we don't want to have Seam dependencies there. We have factories and validators to do the job of creating fresh and save entity instances.

I only use Action Beans which interact with the views and at the other side. I use different flavours for which we defined Abstract beans  Most standard Seam components are declared (with the In annotation) in the AbstractBeans , which cleans up your final code.  These Action beans can also interact with my Business Layer which is the interaction with workflow and rules, In most cases I use the Observer pattern (with the RaiseEvent and Observers) to create loose coupling between the business layer and the rest, because we also try to re-use components there..

Seam allows for a much cleaner design and code and allows you to re-use the different components. If you look at Seam 3, you will see that the component-approach even goes a step further.

Hopefully this helps,

Leo

P.S: I am just kidding about the consultant, don't want to end up in a lawsuit....

[isbajxw]

Thank you for the reply, Aldo. Besides the mentioned blog, I have not found any example that separates the logic that handles navigation and logic that handles page action in JSP world. Two most prominent JSP frameworks, Struts and Spring MVC, do not have the separation.

I worked with SEAM before, so I have a basic understanding about how it works. I may have to catch up a bit with SEAM 3. When you say SEAM components, what do you mean? Aren't they essentially managed beans in JSF world? Obviously SEAM is more powerful than the JSF managed bean container.

[isbajxw]

Thank you for the insights, Leo. I agree with you on clean and simple design. The approach advocated by the mentioned blog seems over-engineering to me.

You do not annotate your domain object. I assume you still use them directly in JSF. Do your Action Beans manage (create/cleanup) the domain object?

I will surely look at SEAM 3.

[lvdberg]

Hi,

The website was down, so I couldn't reply until now. The mentioned Actions Beans use the services (Repository, Factory, Validator etc.) to do basic CRUD on the domain. This simplifies the code substantially and makes it more maintainable

Leo