Does JPAContainer replace the need for DAOs


I’m new to Vaadin and am trying to wrap my mind the Vaadin way of doing DB accesses. In my previous non-Vaadin life, I was accustomed to having DAOs and Service classes to access/manipulate my data before I made it ready for display.

It would seem to me that those layers haven been eliminated with JPAContainer? Is there no longer any need for DAOs and Service layers? I know that the JPAContainer has basic container filters, etc, but how does one do any data manipulation prior to display?

For instance, in the past, I would have used a service layer to encrypt/decrypt data before persisting it via a DAO. How do i do that with JPAContainer? I would also have used my service layers to denote the start/end of a transaction. But I don’t see that anywhere in the JPAContainer demo - it all seems to happen “magically”. How/where does one deal with transactions error processing, etc?

Or is there another container that I can use and retain the use of my Service/DAO layers?



JPAContainer is just a Vaadin container implementation that uses JavaPersistenceApi.
So, JPAContainer is for binding user interface components to data, that is, JPA data.
It supports transactions as well.

JPA by itself lets you easy persist your PoJos, creates the database tables, keys, indices and constraints from the domain model, etc.
It is implemeted for example with Hibernate or Eclipselink, where the latter is the JPA reference implementation
(and has much better performance and predictability than Hibernate and much less quirks,IMO).

For extensive threadsave and transaction based data manipulation you can use JPA´s
itself, in addition to the JPA POJOs persistence patterns.
With the entitymanager you can do alike with DAO and much more with less effort. The SQL that JPA generates internally is mostly unbeatable and performs well.
But you can pass your own SQL statements to it also.

Vaadins JpaContainerAdressbookexample is a good starter to look at, see its domain class where the datamodel is defined with pure JPA.

You can also use Vaadin with JPA without using the JPAContainer at all, and populate the table with the BeanItemContainer,
but then you may have to write lot more additional code for the forms and tables yourself.

In any case, you may want to use JPA itself to manipulate your data in your business logic in a more flexible way than with the UI bound JPA subsets of JPAContainer.
For encryption, look for the JPA annotations @prepersist,@preupdate and @postload in the wiki, with them you can implement encryption/decryption Entity Listeners
(or what else that alters the data before written or after read) on domain level.

Thanks for the detailed response. I have used JPA before, but have used it in conjunction with DAOs and the Entity Manager. (ie: @Transactional, em.merge, em.persist, etc…)

But when I looked at the documentation/examples for JPAContainer, it seems as though there is no place to manually use the EntityManager anymore. I couldn’t understand how to manipulate my data in my business logic and still use the JPAContainer. I would appear that if I want to do any manipulation of the data myself, then I end up needing to use a BeanItemContainer, and no longer the JPAContainer.

Is there something I am missing?



You can simply create instances of EntityManager where you need them, and then use them.

Either I am not understanding something or I didn’t make myself clear. What I don’t understand with the JPAContainer is how to execute my own queries using the EM and send the resultset to the JPAContainer for display.

From what I can tell, if I want to do my own query manipulation (either using named queries or other) and/or do any data manipulation in my business logic, I have to put the items into a BeanItemContainer and cannot use the JPAContainer at that point. Is that accurate? If not, I’m not sure I understand how I can do my own queries and still use the JPAContainer - how do I put my resultset into the JPAContainer?



In your business logic you can use your own instances of EntityManager for manipulating the data, alongside with, but independently of, JPAContainer.
That is, you can not for example do a select with them that is then shown in the JPAC. There you would have to use the criteria api builder or filters.

If you change data outside of JPAC with an EM instance, you have to make sure to refresh() the container.

So, you can use the EM freely outside of JPAC, one instance per thread,
but not “inside”, although you may pass one EM as the second parameter to the JPACFactory, but alas, that has no further effect.

I would rather prefer if one could also simply use SQL statements with the JPAC, but it looks like one has to use the criteria builder or the filters.

Okay - thanks for the confirmation. That’s pretty much what I had understood, but I wasn’t sure.