anonymous wrote : 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
"[EMAIL PROTECTED]" 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?",
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 reusa
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.
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
t
