responses inline below...
On Sat, Oct 19, 2013 at 10:49 AM, Mark Struberg <struberg@yahoo.de> wrote:
> It depends on the application I'd say.
>
> Of course if you use @Stateless then you are really bound to
> entitymanager-per-transaction pattern, and then DTO is almost the only
> thing which really works.
>
this is definitely what i'm doing. only @Stateless @EJBs, no @Stateful
@EJBs at all.
>
> If you use @Stateful + a CDI normal scope and UserTransaction, or you use
> CDI + @Transactional with either UserTransaction or a producer for an
> EntityManager then you can also use the entitymanager-per-request pattern.
> This plays really nice together with mostly CRUD JSF2 apps where the xhtml
> stuff will then be able to lazy-load the data it needs.
>
+1 on the entitymanager-per-request-pattern recommendation. Definitely
something that I am not doing, but I think it may work with approach that
I've seen recommended by some of the experts in PrimeFaces forum
(@RequestScoped beans > @EJBs). please correct me if my
assumption/association is incorrect.
i definitely need to gain some experience using producers and user
transaction, and @Transactional.
> This has a few pros:
>
> * no DTO needed as you can use the entities directly in your backing
> beans. Usually DTOs are mostly 1:1 the data from the entities anyway for
> those cases.
> * the entity will get automatically detached after the first request, any
> cancel on the postback will not store the state to the DB that way.
>
<snip>
> * this means that all the JSR-303 BeanValidation annotations from your
> entities also work out of the box in your JSF2 app, without having the need
> to do all those validations manually and maintaining them twice!
>
</snip>
interesting. i am using @Stateless @EJB (+DTO) and my app/pages are using
BeanValidation nicely (when I want the app to do that...usually on
save/update requests/posts). i definitely use immediate=true, when I don't
want bean validation to do it's thing on commandbutton/link posts in/from
xhtml pages.
> * Save will be done by simply em.merge the entities. There is no further
> need to manually apply any values nor check for any locking as the
> information is already available in your JPA entity.
>
hmmm, my save/update are definitely using em.merge in @Stateless @EJBs.
i have the following in my AbstractFacade class:
public void edit(T entity) {
// 2011-09-17 flush immediately after merge
getEntityManager().merge(entity);
getEntityManager().flush();
}
and JSF controller class has the following:
getFacade().edit(current);
on a page that allows enduser to edit data, I always get a managed entity.
>
> But you also need to be aware of a few cons of this approach:
> * if you have an application which takes a few requests to the server to
> render all state, then this will not work. The entity is only in managed
> mode in the first request - all later requests will fail to load not yet
> touched lazy fields. This e.g. makes it impossible to use
> entitymanager-per-request in Vaadin apps (Vaadin is nice from an UI
> perspective, but wtf, this does SOOOO many round trips to the server an
> almost any click in the UI!)
>
interesting, i definitely only want one trip to server on button-click in
the UI.
> * if you have a remoting technology which does transfer 'exact'
> representations. Then you need some mapping layer anyway.
>
<snip>
> * if you are bound to use pure @Stateless EJBs for your services ;)
>
</snip>
i think that would be me. :)
>
> In this cases a DTO approach is really better usually.
>
agreed.
|