jamesladdcode.com

For a short while I have been looking into JBoss Seam and working through the examples and coding my own project.

My last few projects were Spring/Spring MVC based and architected with distinct layers to keep the code clean and focused, and I wondered how Seam supported this approach. Initially I thought I could just get Seam to inject the items I needed to form different layers and it does, but this isnt idiomatic Seam.

I think it is important to understand the idioms of a framework so you understand how it is intended to be used and therefore get the most out of it. So I posted a question about layering to the Seam Forums.

There were a couple of responses but one in particular from Andy Gibson spelt it all out so clearly that I had to post it here, since it applies to a wider audience than just Seam users.

Hey James,

Shane is right, it really depends on the application context. Another important factor (I think) is whether code is going to be re-used later on, either from another point in the same application, or from another client elsewhere.

These things can always be refactored out later but if you know about it ahead of time, it can impact design decisions earlier.

The first major layering decision though is whether to mix business logic and view logic in the same session bean. A lot of times we’ll see code to handle button clicks in the same bean as the code to perform actions on entities. If we want to perform the same actions from other places in the code or even other applications, we may want to separate that out which is fine.

You can further demarcate the layers based on state and function. The ‘backing bean’ session beans can hold the view state and logic, but any general functional code can be placed into stateless beans which have state passed in to them.

The obvious benefits are that we put the method in one place and always use it to perform that action so if we decide to change it, or always send an email to someone when that action is performed, we can just put it in that one method.

This is probably obvious to many as it is just good OO principles, but Spring always seemed to to put as many layers in as possible because of the (overstated IMO) need to change any layer at any given point in time. We started with MVC, and then Spring threw in service layers, repositories, Daos and so on.

Seam is a little different, especially since it is based around a stack that probably 80% of people are going to use anyway, hence no need to swap out layers. With Seam you can just put layers where they are logical, or it is prudent to do so.

Cheers,

Andy Gibson

Seam handles the weaving (I had to get in a sowing term) of web and services so well that the need for heavying layering is removed, at least for the immediate development. However, I am still a little weary of putting EntityManager interaction logic across more than one class and still choose to put this into a Repository object that is in turn injected into the Action/Service.

Happy seaming !