There isn't really a recommended layering practice, what you see in the examples makes sense in the context of those examples. If it makes sense within the context of your application to separate business logic into its own layer, then by all means architect it that way. In the seamBay example, AuctionAction is a conversation-scoped component containing the business logic for creating a new auction listing. It is used by both the web-based user interface, and also by the AuctionService web service. This is just one example of how business logic can be reused.
Thank you for the reply.
I'll go and have a close look at that example.
The word 'recommended' is probably one I should not have used.
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.
Thank you for such a detailed and well thought out response.
Would you mind if I cross-posted your response in
My Blog ?
Yesterday I purchased and downloaded Seam in Action and section 1.4 made things click in my mind, how Seam removes the need to layer as aggressivly as I had in the past because it mediates between the layers so unobtrusively.
My desire to layer was not a Spring thing, but a general architecture approach to achieve simple, clean and targetted objects. I think I can achieve this in Seam with less code and less work, which is fantastic.
Go Seam !!
Thank you again.
Thank you for such a detailed and well thought out response. Would you mind if I cross-posted your response in My Blog ?
Sure no problem.
Yes, seam removes a lot of the problems with layering because Seam itself is really just the 'stuff' that interweaves the different technologies (JPA, EJB, Jbpm, state management), and pulls it all together without being monolithic.
Andy I was thinking about the samething... Your response has just cleared up a lot of things for me.. thanks