when I executed the orderLineDao.remove(…)

That does mean that the Java object model will be inconsistent with the contents of the database when the deletion fails. Then again, in that case an exception will probably be thrown ending the user request/transaction anyway.

I’m not going to translate your questions, but as this blog is usually in English, I will reply to your questions in English. If you don’t mind.

1. When starting out with JPA, I started using more of the modern ideas, doing away with DAO’s and DTO’s, etc. Only to discover that these abstractions do have a place in the architecture. But I would love to hear other peoples’ innovations on JPA.

2. Acually, I don’t think injecting your DAO into your domain objects is a good idea. They are in fact two different things: a domain object represents one, euh, thing in your domain, while a DAO represents a collection of those things. So I think having a non-static findOrder method in OrderDao is nicer than having a static findOrder in the Order class. The single responsibility principle applies here, I think.
But if a domain object needs access to other services, injecting them with those other services is very needed to prevent your domain model from being anemic. In fact that is what we do in our application. Most of our logic is in our domain objects; the services only load the right objects by invoking the DAO and then invoke the right methods on those objects. This is something I will revisit in a later blog.

3 I have looked at Dozer and it looks very nice. The only reason we haven’t used it yet, is because the code we had to write to copy properties from DO to DTO and back was not that much. Introducing another framework for this did not seem like something that would pay off. The whole team would have to know about the framework, we could run into bugs in that framework, etc.

4. I didn’t mention any JPA 2.0 features because I have no real-life experience with them. Once I do, I will probably be writing a few more blogs. I’m really interested to see how the Criteria thing works out.

5. Using delegation instead of implementation inheritance is the thing to do these days. Then again, these DAO’s are so small that I feel that implementation inheritance is simpler to understand. See also my comment dated April 19th, 2009 at 3:50 pm on my DAO blog.

6. AFAIK, JPA doesn’t have something similar to Session.load so that is opportunity for performance you don’t get with JPA.

7. Yup, we also use ValueType objects, a.k.a. embedded objects, where ever we can. They make life a lot easier: no DAO to write, no lifecycle to worry about.

8. Actually, I think having a very flexibly DAO search interface makes the code harder to read. I’d rather have a number of specific finder methods for all the different ways my app needs to find entities. Then again, if your app needs to provide ad-hoc search capabilities to the end user, such an interface might be very beneficial.

9. (from your second comment) I’m not really sure what you mean here. Could you give an example? Having all entities extend from a base class seem a bit EJB2-ish to me. It would also “waste an inheritace”, something you object to when it comes to DAOs.

10. Hmm, the package scope methods (I did not mentiond protected methods) in our code does work. I’ve also heard about problems with using field access (my preference) versus property access when it comes to Hibernate proxies. I have a feeling that the proxies created for JPA work slightly differently than those created for Hibernate. The fact that JPA by default eagerly loads to-one associations probably helps here too. This is something I am going to investigate for my next blog on lazy loading.

Thanks again for attending. And for your long reply! Regards, Vincent.

@ManyToOne(optional=false)
private Order order;

If you do that, Hibernate will throw this exception when you try and commit the transaction in which you created that orphan:
org.hibernate.PropertyValueException: not-null property references a null or transient value: com.xebia.jpaip.order.OrderLine.order

Nog wat: Pas op met protected methods in Domain objecten. Je zei op ten duur in je presentatie dat je die setInternal* method protected kon maken. DIT KAN NIET als je wilt dat je proxies (met lazy loading) goed werken. Dan moet dit nl public zijn om je proxies correct te triggeren. Dus pas hier mee op.
Maar goed: proxies in domain objecten is ook een heel apart onderwerp waardoor vaak vele bugs in projecten zitten omdat het niet correct wordt begrepen.
Bijvoorbeeld: het gebruik van instanceof en getClass() method in equals() van domain object is uit ten boze en kan tot raare fouten leiden. Zie de bijbel voor meer uitleg.
Ik zelf heb altijd standaard testen die ik op domain objecten los laat om te testen of ze proxy-safe zijn.

Ik ga weer snel verder….
– Ed

Ik was gisteren bij je JSpring 2009 voordracht.
Hastikke goed gedaan, lekker rustig en duidelijk. Alleen het eind was een beetje rommelig, maar dat komt vast nog een keer goed .

Anyway: ik vond het prettig om herkenbare problement te zien, maar had wel het gevoel alsof ik 5 jaar terug in tijd gng. Ik had gehoopt meer innovatieve oplossingen te zien.
Een paar dingetjes (zeker niet compleet):

- Inject je Dao in je domein objecten (met Spring bijvoorbeeld). Je gebruikt het Anemic Domain pattern wat echt not-done is met de huidige technieken en tijd. Stop gewoon je remove, save, etc… operaties direct in je domain objecten (ik vroeg hier ook naar tijdens je voordracht). Zie: http://www.theserverside.com/news/thread.tss?thread_id=38047

- Waarom je eigen DTO converter schrijven als er tools als Dozer zijn die dit reeds netjes voor je doen?

- Waarom niet dingen van JPA 2.0 reeds in je voordracht gebruiken?

- Ik zou die DAO implementaties niet laten exenden van je DAO base class waarin je get/find, etc… methods zitten maar ik zou deze laatste als een Persister class injecten in je DAO implementatie class. Dit werkt prettiger (ik had het eerste exact zoals jij het schetste) en scheelt een inherance, en je weet dat die zeldzaam zijn want je heb er maar 1 (dus: gebruik delegator pattern).

- Ik weet niet precies of JPA dat nu goed ondersteund, maar maak ook meer gebruikt van de hibernate load/get i.p.v. alles via de get laten lopen.
Voorbeeld: als je een nieuw adres aanmaakt en deze persist, en stop daarin een Country object waarvan je zeker weet dat hij bestaat in de db, gebruik dan load voor het country object. Dit scheelt een query en bij grote loads, kan dat een behoorlijke performance boost zijn.

- Je refereerde naar de bekende Bijbel van Gavin King en Christian. Dan ben je op de hoogte van Entity en ValueType objecten waar ze steeds onderscheid in maken.
Samengevat: Entity object: heeft eigen levenscyclus en ValueType object niet en die hangt altijd aan een Entity object.
Voorbeeld:
Entity -> Member object.
ValueType -> Email object.
Member heeft eigen methods zoals remove/save, etc… en Email niet, die volgt het gedrag van zijn Member (als Component in HIbernate termen).
Dit werkt bijzonder prettig en ik heb hier op diverse grote enterprise projecten goede ervaringen mee. D.w.z.: Categoriseer al je domain ojbecten in deze 2 (m.u.v. een mix voor performance redenen maar dat is een technisch feesie).

- Ik mis een flexible DoaSearch interface (naast de DAO interface). Voorbeeld van 1 van zijn methods:
public List findEntities(J persistenceClass, SearchCriteria search, SortCriteria sort)

Zoals je ziet kan je hiermee felxibel queries bouwen (SQL, HQL of JPA achtig afhankelijk van je implementatie die je inschiet).
Dit werkt er prettig omdat je hiermee in het Criteria object aangeeft op welke velden je van een Member wil zoeken en vervolgens maakt de query builder automatisch via een specifieke Query appender (via het observer pattern) de query voor je en klaar is kees. Deze appenders schiet je in via Spring, en het toevoegen van een find is dus puur configuratie in de backend, het schrijven de de nieuwe appender en criteria.

Euuwwww.. dit was het wel even, de rest ben ik alweer vergeten.

Misschien heb je er wat aan (ik wilde je eigenlijk paar dingetjes mailen, maar het zijn er toch meer geworden )….
Als je wat wil weten, hoor ik het wel.
Cheers,
Ed
PS: vergeet voortaan je water niet