Hibernate 3 binnen Application Server design discussie

[ronaldmathies]

Ik ben bezig om hibernate een beetje onder de knie te krijgen om een idee te hebben wat het precies inhoud en hoe ik het kan toepassen.

Ik heb als proef de volgende situatie in gedachte.
Ik wil een web applicatie, webservice en een client applicatie hebben die gebruik maken van hibernate op een database omgeving.

Nu heb ik zonder al te veel moeite hibernate als MBean geregistreerd in een JBoss applicatie server. Dit gaat allemaal goed.

Nu zit ik een beetje met een design kwestie.

Hoe kan ik er voor zorgen dat de client en de web applicatie de hibernate laag kan gebruiken voor de persistentie. Ik dacht aan de volgende situatie:

Web ---------------------------------> |
Session Bean (webservice) -> | ---> Stateless Session Bean --> Hibernate --> Ejb
Client --------------------------------> |

Uitleg:

Zowel de Web, Webservice als de client gebruiken de stateless session bean om hibernate te gebruiken.

Dit had voor mij namelijk de volgende gedachte. Je hebt maar op 1 plek hibernate draaien. De business rules kan ik vermoedelijk verwerken (moet nog even bekijken of dit inderdaad logisch is) in de Stateless Session Bean (hierna SSB). En de SSB kan fungeren als een session facade over 1 of meerdere hibernate entities (heet dat bij hibernate eigenlijk zo?).

Nu mijn vraag:

Is dit een logische opzet? Hoe hebben jullie dit probleem opgelost? (Hoeft niet heel technisch uitgelegd te worden maar meer theoretisch)

[Alarmnummer]

Ik zou achter de SSB een pojo plakken die als echte facade functioneert en waarin je de businesslogic kan prakken. Deze pojo kan je makkelijk testen doordat je niet vastzit aan een EJB-container.

En verder zou ik erg oppassen met het distributen van domain objecten naar een client. Denk dat het handiger is om een DTO daarvoor te gebruiken. Iedereen mag je DTO`s zo ver verneuken als ze willen, maar uiteindelijk wordt het je de businesslaag weer ingepompt en kan je daar allerlei checks eropt uitvoeren.

Verder moet je wel oppassen met het opentrekken van sessies. Ik heb per businesscall 1 gedeelde sessie en die sessie kan na afloop van de call geflushed (of gerollbacked) worden.

[edit]
Verder snap ik dit stuk niet helemaal:
Stateless Session Bean --> Hibernate --> Ejb

Waarom zou Hibernate weer naar EJB gaan?

[ Voor 11% gewijzigd door Alarmnummer op 26-01-2006 10:31 ]

[ronaldmathies]

Ik gebruik altijd met dit soort dingen de TransferObject pattern.

Voorheen met EJB's had ik dit model:

Client -> TransferObject -> SSB -> EntityBean

Waarbij de SSB een facade was over de Entity Beans en de TransferObject een Pojo tussen de clients en de SSB. De business rules had ik grotendeels in Validator objecten zitten die gebruikt worden door de Entity Beans.

Ow en dit:

Stateless Session Bean --> Hibernate --> Ejb

Dit is een foutje de laatste Ejb moet database zijn.

[ Voor 50% gewijzigd door ronaldmathies op 26-01-2006 10:43 ]

[Alarmnummer]

ronaldmathies schreef op donderdag 26 januari 2006 @ 10:41:
Ik gebruik altijd met dit soort dingen de TransferObject pattern.

DTO = Data Transfer Object.

[ronaldmathies]

M.a.w. De opzet die ik in gedachte had is opzich een goede manier van werken.
Zijn er nog bepaalde tips die mensen hebben waar ik rekening mee moet houden in de opzet?

Bijvoorbeeld bij de validatie, of de foutafhandeling.
Zijn er goede bronnen op internet (must haves) om te lezen in verband met de structuur (geen tutorials over hoe je hibernate gebruikt)?

Zijn er eigenlijk al mensen die de annotations van hibernate gebruikt hebben in een productie omgeving? Ik lees namelijk op internet dat dit al gebeurt.

[Alarmnummer]

ronaldmathies schreef op donderdag 26 januari 2006 @ 13:05:
M.a.w. De opzet die ik in gedachte had is opzich een goede manier van werken.
Zijn er nog bepaalde tips die mensen hebben waar ik rekening mee moet houden in de opzet?

Bijvoorbeeld bij de validatie, of de foutafhandeling.

Tricky

In Spring is validatie op dit moment niet zo geweldig. Validatie wordt in de weblayer gehouden omdat je daar een betere aansluting hebt op de melding mechanismes van het specifieke webframework. Binnenkort gaat dit verhuizen naar de domain layer waar het ook hoort. Validatie is dus volgens mij per framework (en zelfs versie) wel weer verschillend.

Foutafhandeling.. tja.. welke fouten? Businesslogic fouten? Programmeerfouten? Fouten van externe systemen zoals een db?

Zijn er goede bronnen op internet (must haves) om te lezen in verband met de structuur (geen tutorials over hoe je hibernate gebruikt)?

Hmm tja.. Volgens mij is het meer afhankelijk van welke technieken je gebruikt. Als je bv Spring bekijkt dan gaat die er op een hele andere manier mee om dan EJB.

Zijn er eigenlijk al mensen die de annotations van hibernate gebruikt hebben in een productie omgeving? Ik lees namelijk op internet dat dit al gebeurt.

Ik heb er zelf nog geen gebruik van gemaakt. Ik vind het wel prettig dat mijn mapping informatie gewoon in een xml bestand staat en niet mijn javacode verziekt. Misschien dat ik overtuigd raak als ik er een keer mee moet werken, maar zie er tot op de dag van vandaag niet echt de meerwaarde van.

[edit]
Verder kun je Hibernate redelijk achter de schermen stoppen. Dus het hoeft niet al te ver door te dringen in de rest van je systeem. Ik hoef alleen de DAO`s en een Hibernate specifieke TransactionManager te vervangen (onderdeel van Spring) als ik Hibernate zou willen vervangen door iets anders. Ook de Hibernate specifieke foutmeldingen zijn niet meer terug te vinden binnen de dao interfaces omdat die weggeabstraheerd zijn achter een generieke set met db foutmeldingen.

[ Voor 19% gewijzigd door Alarmnummer op 26-01-2006 13:25 ]

[Verwijderd]

ronaldmathies schreef op donderdag 26 januari 2006 @ 10:11:
Ik ben bezig om hibernate een beetje onder de knie te krijgen om een idee te hebben wat het precies inhoud en hoe ik het kan toepassen.

Als je nu pas gaat beginnen met Hibernate kun je wellicht net zo goed meteen naar de EJB3 versie ervan kijken.(Hibernate 3.1 + de nieuwe entity manager + hibernate annotations). Het voordeel is dat je niet meer met vervelende XML mapping files werkt. Een paar kleine annotations in je POJO's, en voila, alles kan zo van en naar de DB.

Omdat je met annotations werkt heb je geen dependency's. In veel gevallen zijn DTO's dan ook niet meer nodig. (Annotations zijn slechts een labeltje wat je aan een 'ding' hangt, je typing veranderd er niet door zoals met interfaces).

Ik gebruik nu zelf al Hibernate 3.1 / Entitymanager / Annotations en het werk geweldig. Bijkomend voordeel is dat de syntax en API in een spec vastgelegd is. Mocht ik om wat voor reden dan ook Hibernate opeens beu zijn kwa implementatie, dan kan ik het zo omwisselen voor een andere persistance provider (oracle toplink mischien?) ter zijnder tijd en hoef ik mijn code niet aan te passen.

[ronaldmathies]

Alarmnummer schreef op donderdag 26 januari 2006 @ 13:14:
[...]

Tricky

In Spring is validatie op dit moment niet zo geweldig. Validatie wordt in de weblayer gehouden omdat je daar een betere aansluting hebt op de melding mechanismes van het specifieke webframework. Binnenkort gaat dit verhuizen naar de domain layer waar het ook hoort. Validatie is dus volgens mij per framework (en zelfs versie) wel weer verschillend.

Foutafhandeling.. tja.. welke fouten? Businesslogic fouten? Programmeerfouten? Fouten van externe systemen zoals een db?

Ik heb de validatie het liefst zoveel mogelijk gecentraliceerd, dus ook als ik bijvoorbeeld Spring zou gebruiken dan zou ik nog willen dat de validatie centraal is. Dus ik wil eigenlijk zo min mogelijk rekening houden met frameworks.

Hmm tja.. Volgens mij is het meer afhankelijk van welke technieken je gebruikt. Als je bv Spring bekijkt dan gaat die er op een hele andere manier mee om dan EJB.

Klopt, maar in Spring kan ook omgaan met Session Beans, en dan houd mijn model nogsteeds stand.

Ik heb er zelf nog geen gebruik van gemaakt. Ik vind het wel prettig dat mijn mapping informatie gewoon in een xml bestand staat en niet mijn javacode verziekt. Misschien dat ik overtuigd raak als ik er een keer mee moet werken, maar zie er tot op de dag van vandaag niet echt de meerwaarde van.

Ik heb het resultaat gezien bij EJB3 en ik vondt het zelf geweldig, zo heb je de metadata van je POJO's en de POJO zelf bij elkaar. Hoef je niet meerdere bestanden te onderhouden met het risico dat het uit sync zou gaan lopen.Daarnaast kennen Annotations meer compile time controlle dan XML bestanden.

[edit]
Verder kun je Hibernate redelijk achter de schermen stoppen. Dus het hoeft niet al te ver door te dringen in de rest van je systeem. Ik hoef alleen de DAO`s en een Hibernate specifieke TransactionManager te vervangen (onderdeel van Spring) als ik Hibernate zou willen vervangen door iets anders. Ook de Hibernate specifieke foutmeldingen zijn niet meer terug te vinden binnen de dao interfaces omdat die weggeabstraheerd zijn achter een generieke set met db foutmeldingen.

[Alarmnummer]

ronaldmathies schreef op donderdag 26 januari 2006 @ 14:04:
[...]
Ik heb de validatie het liefst zoveel mogelijk gecentraliceerd, dus ook als ik bijvoorbeeld Spring zou gebruiken dan zou ik nog willen dat de validatie centraal is. Dus ik wil eigenlijk zo min mogelijk rekening houden met frameworks.

Dat is iedereen zijn wens, maar in de praktijk moet je vaak praktisch te werk gaan. Validatie zie je vaak nog terug komen in de ui layer, puur omdat het daar eenvoudiger is om te doen mbt foutmeldingen bv. Maar het hoort absoluut niet thuis in de ui layer, het hoort namelijk thuis in de businesslayer. Dus in de praktijk worden keuzes genomen op basis van de mogelijkheden van het de tools waar je mee werkt.

Wat ik hiermee wil zeggen is dat je vaak moet roeien met de riemen die je hebt.

Klopt, maar in Spring kan ook omgaan met Session Beans, en dan houd mijn model nogsteeds stand.

Ik snap je opmerking niet helemaal.

Ik heb het resultaat gezien bij EJB3 en ik vondt het zelf geweldig, zo heb je de metadata van je POJO's en de POJO zelf bij elkaar. Hoef je niet meerdere bestanden te onderhouden met het risico dat het uit sync zou gaan lopen.Daarnaast kennen Annotations meer compile time controlle dan XML bestanden.

Misschien dat ik het in de toekomst wel een keer ga proberen, maar ik vind niet dat het nou echt meerwaarde heeft. Als je het doet in een mapping bestand of je doet het via annotations. Ik zie hetzelfde met security en transactie settings in Spring. Ik kan het daar in XML doen, in common attributes (voor java <5) en met annotations. Maakt me eerlijk gezegd niet zo heel veel uit waar het staat, het is niet dat er een hele lading viezigheid voor me opgelost wordt oid. Het is meer een esthetische kwestie imho.

[ Voor 9% gewijzigd door Alarmnummer op 26-01-2006 14:26 ]

[Verwijderd]

Alarmnummer schreef op donderdag 26 januari 2006 @ 14:15:
Misschien dat ik het in de toekomst wel een keer ga proberen, maar ik vind niet dat het nou echt meerwaarde heeft. Als je het doet in een mapping bestand of je doet het via annotations. Ik zie hetzelfde met security en transactie settings in Spring. Ik kan het daar in XML doen, in common attributes (voor java <5) en met annotations. Maakt me eerlijk gezegd niet zo heel veel uit waar het staat, het is niet dat er een hele lading viezigheid voor me opgelost wordt oid. Het is meer een esthetische kwestie imho.

Je kunt ook stellen dat de annotatie wel degelijk bij de class hoort:
public interface User {}

public HibernateUser implements User {}

In dit geval vind ik dat de annotaties wel degelijk bij een class horen. Het is immers hetgeen de class Hibernate specifiek maakt.

[Kwistnix]

Alarmnummer schreef op donderdag 26 januari 2006 @ 14:15:

Validatie zie je vaak nog terug komen in de ui layer, puur omdat het daar eenvoudiger is om te doen mbt foutmeldingen bv. Maar het hoort absoluut niet thuis in de ui layer, het hoort namelijk thuis in de businesslayer.

Dat is ook altijd iets waar ik toch even over na moet denken.
Sowieso moet user input altijd gevalideerd worden, maar dat kan op twee verschillende niveau's: de syntax en de semantiek van de input. Syntactische controle stop ik vrijwel altijd in de UI layer, omdat het daar meestal eenvoudig te controleren is en omdat je dan directe terugkoppeling naar de gebruiker kan realiseren. Voor webapps geldt natuurlijk dat je de input niet (alleen) client-side op een geldige syntax moet valideren vanwege het security concern.
Als de syntax van de input geldig is, is het altijd nog de vraag of de input ook een geldig waarde vertegenwoordigd binnen het systeem en die validatie stop ik dan wel in business layer.

Ik kan zelf uitsluitend uit ervaringen spreken die ik heb opgedaan tijdens mijn opleiding, dus ik ben benieuwd of dit een juiste aanpak is.

[Alarmnummer]

Verwijderd schreef op donderdag 26 januari 2006 @ 14:34:
[...]
Je kunt ook stellen dat de annotatie wel degelijk bij de class hoort:

Het is een bepaald aspect van de class, maar dat wil niet zeggen dat het in hetzelfde bestand hoeft te komen. Verder vind ik het eerlijk gezegd ook niet zo veel uitmaken, als jij het in de class wilt hebben, dan plaats je het in de class. Ik ga er niet sneller of langzamer door werken.

[Verwijderd]

Alarmnummer schreef op donderdag 26 januari 2006 @ 14:56:
Het is een bepaald aspect van de class, maar dat wil niet zeggen dat het in hetzelfde bestand hoeft te komen. Verder vind ik het eerlijk gezegd ook niet zo veel uitmaken, als jij het in de class wilt hebben, dan plaats je het in de class. Ik ga er niet sneller of langzamer door werken.

Het maakt voor de werking ook niet zoveel uit, maar het maakt je applicatie structuur wel duidelijker en het zoeken makkelijker. Dus ja, je gaat er wel langzamer van werken

Het is geen gedeelde informatie, zodoende is het niet nuttig om de informatie uit de class te halen. (enkel op recompiles te voorkomen, maar dat voordeel is nauwelijks interessant).

[Alarmnummer]

Verwijderd schreef op donderdag 26 januari 2006 @ 15:08:
[...]
Het maakt voor de werking ook niet zoveel uit, maar het maakt je applicatie structuur wel duidelijker en het zoeken makkelijker.

Tja.. ik heb liever in 1 bestand mijn hibernate mappings staan, dan het versnipperd ligt over mijn class heen. Maar volgens mij dwalen we nu af.