Recommendation for layered architecture???

[maku01]

In my former jsf projects I used a classical layered architecture with spring (and hibernate) for implementing a completely stateless service layer.
e.g.
UI (JSF) --> Delegate --> Service Layer --> DAO Layer

With the help of Spring I was able to handle the transactions declaratively, handle exceptions and so on with the help of AOP.
I had a clear demarcation between UI and backend.

I structured this architecture in some distinct projects:
- generic backend func.
- app. specific backend func.
- generic ui func.
- app. specific ui func.
Maven2 does the magic when it comes to deployment.


Now I evaluate Seam an I see a very interesting UI framework on top of JSF which is able to help the developer in a great manner.
(and I would really like to move in this direction)

But, I'm a little bit confused about the coherence between the UI and the business logic.

What I have to achieve is to use the business logic in a non UI app e.g. for batch purposes (bill computations and so on)

I would need a recommendation for structuring my app so that the usage of the business logic is possible without pain.

Also I see little problems when developing with the seam ant approach because of the separation of the app in several projects.
(a Maven approach would be very helpful in this context)

Could anybody of you give me an advice or share the experience in context with the topics above.

TIA

[gavin.king]

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.

[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.

[gavin.king]

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.

[cwash]

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.

[gavin.king]

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.