Discussion:
[seam-dev] Stafeful services directly from the JSF VS "ViewBean" + stateless service
José Rodolfo Freitas
2011-12-22 10:49:40 UTC
Permalink
CDI created the possibility to reach any bean in the container from a JSF
view, encouraging a closer approach between ejb and jsf (or any cdi bean
and jsf), which can potentially lead to a simpler application design. I
think that is great!

However, I'm observing that this new programming model has been
experimenting user resistance. The "traditional" way of doing things, using
a "ViewBean" accessing a Stateless Service seems to be the
more legit.

What do you think about this? I'd like to discuss best practices around it
as I see it's on the core of almost every web application design.
John D. Ament
2011-12-22 11:36:11 UTC
Permalink
I tried this a few times recently. the main issue that pops up is that the
EJB timeouts and WEB timeouts in the platform do not sync up. so if you're
idle on a page for 5 minutes, your stateful EJB disappears, unless you have
someone change container config.

On Thu, Dec 22, 2011 at 5:49 AM, José Rodolfo Freitas <
Post by José Rodolfo Freitas
CDI created the possibility to reach any bean in the container from a JSF
view, encouraging a closer approach between ejb and jsf (or any cdi bean
and jsf), which can potentially lead to a simpler application design. I
think that is great!
However, I'm observing that this new programming model has been
experimenting user resistance. The "traditional" way of doing things, using
a "ViewBean" accessing a Stateless Service seems to be the
more legit.
What do you think about this? I'd like to discuss best practices around it
as I see it's on the core of almost every web application design.
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
Peter Muir
2011-12-22 13:06:57 UTC
Permalink
IMO both approaches are valid in different situations, and it entirely depends on the app. If I have multiple view layers (eg jsf and jax rs I will likely want some sort of controller bean betweeny business layer and jsf, so as to not let jsf concerns leak. Otoh if it was just a web app with a jsf front end only, maybe I would dispose of this layer.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
I tried this a few times recently. the main issue that pops up is that the EJB timeouts and WEB timeouts in the platform do not sync up. so if you're idle on a page for 5 minutes, your stateful EJB disappears, unless you have someone change container config.
CDI created the possibility to reach any bean in the container from a JSF view, encouraging a closer approach between ejb and jsf (or any cdi bean and jsf), which can potentially lead to a simpler application design. I think that is great!
However, I'm observing that this new programming model has been experimenting user resistance. The "traditional" way of doing things, using a "ViewBean" accessing a Stateless Service seems to be the
more legit.
What do you think about this? I'd like to discuss best practices around it as I see it's on the core of almost every web application design.
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
cdi-dev mailing list
https://lists.jboss.org/mailman/listinfo/cdi-dev
Fabien Marsaud
2011-12-22 14:41:17 UTC
Permalink
I agree with the fact the "traditional" way of doing things is hard ot get
rid of, I agree with Pete too, but if I may, I'd say it's often hard or
impossible to avoid some "view bean".

You can, when you only want to display stuff that doesn't need any 'UI'
reformatting.

Otoh, take a canonical CRUD: the submit button requires an action method
you don't have in your business layer. So it must go on a bean standing
behind the view.

Another example: feed a table on the screen. If the objects fetched from
the business layer can be displayed as-is, you can directly call the EJB.
But many developers will be reluctant to annotate it @Named. So you have to
wire your business methods through a view bean which is known to EL. Now,
if the elements on the table require any manipulation/action, you have to
encapsulate them and there's no other way but to get the cooking done on
some view bean.

And as development teams are required to work in a "normalized" way no
matter what's going to be on the screen, you end up having complete web
applications wiring all the biz methods through view beans.

After all I see no probmem with that, with CDI everyone can work the way he
wants. In my application I get all the db/xml configs via producer methods,
and I did a custom scope/context to refresh them without restarting
anything. So no matter whether you want to do simple of sophisticated
things, CDI has a solution in store.

fm.
Post by Peter Muir
IMO both approaches are valid in different situations, and it entirely
depends on the app. If I have multiple view layers (eg jsf and jax rs I
will likely want some sort of controller bean betweeny business layer and
jsf, so as to not let jsf concerns leak. Otoh if it was just a web app with
a jsf front end only, maybe I would dispose of this layer.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
I tried this a few times recently. the main issue that pops up is that
the EJB timeouts and WEB timeouts in the platform do not sync up. so if
you're idle on a page for 5 minutes, your stateful EJB disappears, unless
you have someone change container config.
On Thu, Dec 22, 2011 at 5:49 AM, José Rodolfo Freitas <
Post by José Rodolfo Freitas
CDI created the possibility to reach any bean in the container from a JSF
view, encouraging a closer approach between ejb and jsf (or any cdi bean
and jsf), which can potentially lead to a simpler application design. I
think that is great!
However, I'm observing that this new programming model has been
experimenting user resistance. The "traditional" way of doing things, using
a "ViewBean" accessing a Stateless Service seems to be the
more legit.
What do you think about this? I'd like to discuss best practices around
it as I see it's on the core of almost every web application design.
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
cdi-dev mailing list
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
Dan Allen
2011-12-24 00:29:32 UTC
Permalink
On Thu, Dec 22, 2011 at 05:49, José Rodolfo Freitas <
Post by José Rodolfo Freitas
CDI created the possibility to reach any bean in the container from a JSF
view, encouraging a closer approach between ejb and jsf (or any cdi bean
and jsf), which can potentially lead to a simpler application design. I
think that is great!
However, I'm observing that this new programming model has been
experimenting user resistance. The "traditional" way of doing things, using
a "ViewBean" accessing a Stateless Service seems to be the
more legit.
What do you think about this? I'd like to discuss best practices around it
as I see it's on the core of almost every web application design.
The way I've always looked at this is that the initiative to flatten the
tiers in the Java EE platform was always focused on making the platform
more approachable. When you read tutorials that require many technical
steps that doesn't seem to add any value, the perception is that the
platform is overkill. Why create two beans when one will do?

I think that once an application matures, many of your UI interactions will
go through a controller layer that mediates between the view and the
services. If you're an experienced developer, this maturation may occur as
early as the design stage, in which case you never even write any code that
uses the flattened architecture. But it's critical for tutorials &
prototypes.

Another way to say this is that there is no reason to enforce a middleman.
Why can't the UI just invoke any service you expose directly? There will be
plenty of cases when that's reasonable. If there is a reason it shouldn't,
that should be a restriction you impose, not one that the platform imposes.

So I advise you to not feel shy about creating a view controller if it
feels right. You should only observe yourself creating a bean that does
nothing but delegate to another bean and ask why you are doing that.

-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
Loading...