När EJB3 specifikationen kom och den första implementationen av hibernate var ute. Så var ett av sälj argumenten det att vi nu kan göra oss av med DTO’erna en gång för alltid.

Experterna glömde ett scenario där detta inte gäller …
I ett projekt skulle vi införa EJB3 med hibernate som den nya arkitekturen. Istället för den DTO lösning som fanns på plats samt den lite nyare hibernate lösningen med open-session-in-view. Vi läste på oss, tog in experter, gick kurser och vi kom fram till följande:
1) Open-Session-in-view, skall vi inte ha kvar. På grund av många skäl. Hum en till artikel månne ?
2) Vi kan strunta i DTO’erna för istället har vi vår domän och dess entiter som vi för upp till vyn
Vänta nu! Pausa och spola tillbaka! Våra domän objekt aka entiteter upp direkt till vy lagret! är inte det ett komplett lagbrott mot SoC (Separation of concerns)? Enligt min uppfattning är ett av huvudsyfterna med DTO’er att just upprätthålla detta.
Jaja.. det ska nog gå bra ”alla” säger ju att EJB3 tar bort behovet av DTO’erna…



As time goes by ..
När vi började implementera den nya arkitekturen gick allt som en dans i och med de hyfsat enkla användarfallen så ser man inte faran med entiteter uppe i vyn.
Men efter en tid så började produkt ägaren komma med bizz-regler som kräver mer av våran domänmodell. Vi behöver nu applicera dessa på våra aggregat objekt för att upprätthålla regeln/”statet”.
Och hur gör vi detta då? nu när vi har öppnat upp våra pojo entiteter som rena rama seven-eleven butiker?
Inte nog med det mer och mer data måste upp till vyn och inte bara från en viss entitet utan från flera.
Tänker man efter så är detta oftast fallet. Användaren vill inte bara se data från ett eller flera Person objekt utan mer som en tårtbit ur vår domän ”kaka” modell.
Tex ett Person objekt med sin varukorg med statistik över sina produkter samt sina kontrakt med sina nuvarande kunder.

Ni märker väll att det blir problematiskt?…


Storm at the horizon ..


Just detta ledde till en hel drös med LazyInitException’s som skedde på grund av att vyn försökte plocka fram data genom våra pojo entiteter som i sin tur var en hibernate proxy.

-Ni kommer väll ihåg transaktions gränsen har vi passerat..
Vår lösning på detta var tyvärr inte att stoppa denna domän massflykt till vyn utan istället implementera en assembly-phase lösning med så kallade fetchhints på server sidan. Med dessa fetchhints skulle vyn kunna styra vad den ville ha från våran domän.
Dock ledde detta till mer problem genom att vi drog upp hela eller delar av databasen fast vi ville bara ha viss data. Samt hur skulle vi göra när vi vill ha data långt ned i objekt-trädet?


Bigger problems ..


Men enligt min uppfattning är inte detta det stora problemet. Problemet blir verkligen farligt när vi inte kan applicera våra bizz regler pga våra pojo liknande entiteter. Publika “setters” samt entiteter som endast ska

kommas åt genom aggregat objekt strövar fritt ute i vyn.


Hope spells DTO?..


Så summa kardemumma:

1) Använd DTO’erna när du behöver visa data från fler än en entitet.
2) Ha inte ORM annoteringar på set/get utan på fält nivå! Jag ska bli ännu tydligare! Använd INTE PUBLIKA SETTERS PÅ DINA ENTITETER.
3) Om du skickar upp entiteter till vyn gör det endast för att visa data.
Vid CRUD använd DTO’erna eller möjligtvis värde objekt.
Kolla gärna in qi4j som har en annorlunda approch.



Så visst behövs DTO’erna i någon form jag säger inte att DTO’erna är en “silver bullet”

men lär dig av mina misstag och tänk till före



EJB3 DTO killer …
http://www.theserverside.com/tt/articles/article.tss?l=MigratingJDBC