-
1. Re: Recommendation for layered architecture???
gavin.king Jun 5, 2007 7:14 AM (in response to maku01)This question has been asked several times and my answer is always that nothing about Seam prevents you from structuring your code in the "traditional" layered manner.
For example, one possible architecture would be:
A "DAO" is a Seam EntityHome object, or even just a @Stateless session bean that injects a Seam-managed persistence context and performs persistence operations and returns entities.
A "Service" is a @Stateful or @Stateless session bean that injects the "DAOs" and does business logic.
A "Delegate" is a JavaBean component that injects "Services".
There are many possible variations upon this. I picked this schema because it is closest to something that is familiar in traditional J2EE development, but not because it is any way the "best" thing to use with Seam. -
2. Re: Recommendation for layered architecture???
maku01 Jun 5, 2007 7:33 AM (in response to maku01)Thanks for answering.
I realized that it is possible to layer the app in such a way.
But it seems that this is not the recommended way to layer the app according to the "Seam" spirit.
I'm not really bound to such a stateless session layer. I would want to use as much power Seam can give me.
Though it should be possible to use the business logic separately from the UI. -
3. Re: Recommendation for layered architecture???
gavin.king Jun 5, 2007 7:42 AM (in response to maku01)Well, basically, I think these problem becomes much easier once you stop thinking in terms of "what layers should I have", and start thinking in terms of "what code do I have that is reusable when the client is not JSF, and what code do I have that is not reusable?", and then implement the reusable code into reusable Seam components.
This doesn't stop you from thinking about component dependencies, and about separation of concerns - in fact it makes it easier.
It's my strong belief that conceptualizing reusability in terms of "layers" has been the source of much evil in the Java world. I try to write reusable objects, not reusable layers. But this is not an approach that Seam forces upon you, it is just my approach. -
4. Re: Recommendation for layered architecture???
cwash Jun 26, 2007 5:09 PM (in response to maku01)"gavin.king@jboss.com" wrote:
Well, basically, I think these problem becomes much easier once you stop thinking in terms of "what layers should I have", and start thinking in terms of "what code do I have that is reusable when the client is not JSF, and what code do I have that is not reusable?", and then implement the reusable code into reusable Seam components.
This doesn't stop you from thinking about component dependencies, and about separation of concerns - in fact it makes it easier.
It's my strong belief that conceptualizing reusability in terms of "layers" has been the source of much evil in the Java world. I try to write reusable objects, not reusable layers. But this is not an approach that Seam forces upon you, it is just my approach.
That's an interesting way to look at it. Do you feel you could say the same for loose-coupling, maintainability, scalability, and all of the arguments people give for layering? Perhaps it's hard for people to see that a lot of the old-school layering techniques are done for you under the covers with Seam, and feel like they're taking the "red pill" by not self-imposing their own layers. -
5. Re: Recommendation for layered architecture???
gavin.king Jun 28, 2007 2:58 PM (in response to maku01)That's an interesting way to look at it. Do you feel you could say the same for loose-coupling, maintainability, scalability, and all of the arguments people give for layering? Perhaps it's hard for people to see that a lot of the old-school layering techniques are done for you under the covers with Seam, and feel like they're taking the "red pill" by not self-imposing their own layers.
Maintainability is affected by three things:
* How much code there is (less is better)
* How clean and understandable the code is
* How well concerns are separated
If you look at a typical Seam application, I think you'll find that it wins on all three counts compared to a traditional Java EE architecture. Some people might say that our example apps show less separation of concerns between application orchestration and pure business logic, but I think this point is somewhat debatable. Anyway, if you feel this way it is very easy factor out the "pure business logic" into "pure business components".
I'm not sure exactly what you mean by "loose coupling", my view is that business components in Seam applications are much, much, much more loosly coupled than in traditional architectures because they don't need to manage each others lifecycles. IMO this is one of the great strengths of our component model.
Scalability is a red-herring here. The most scalable known architecture is a single physical tier with a horizontal axis of scale. Layering does not contribute to scalability.