Ik ben eens aan het nadenken over hoe ik NHibernate kan gebruiken in een applicatie waarin ik werk met remoting / wcf.
Dit is hoe ik de structuur zie:
De client communiceert mbhv remote calls met de service layer. Om een object op te halen, zal de client dus bv een remote call maken die er als volgt uit ziet:
Customer is hier een entity class die zich in het Domain Model bevindt.
De client kan hier een aantal mutaties gaan uitvoeren op Customer, en deze later dan gaan saven :
Het probleem dat ik hier zie, is 2 - ledig:
- Mijn client kan niet weten of mijn Customer object nu al of niet gewijzigd is; mijn entities hebben nl. geen state-tracking, aangezien NHibernate dit verzorgt dmv zijn ISession unit-of-work.
De kans is dus groot dat ik een onnodige remote call doe.
- Aangezien ik in een remote situatie werk, zijn mijn remote-methods stateless. Dwz dat mijn SaveCustomer method een andere ISession (een nieuwe) zal gebruiken om mijn Customer object te saven. In het geval van NHibernate betekent dit dus ook dat NHibernate niet weet of hij mijn Customer nu eigenlijk moet updaten , of niet. Dit kan dan weer problemen opleveren als je entities een version, lastupdated, lastupdatedby property bijhouden; dit kan maw tot verkeerde informatie in de DB leiden. (lastupdated, version, lastupdated by kunnen ten onrechte aangepast worden als er niets aan mijn entity veranderd is).
Nu zie ik wel een oplossing, en dat is om een soort van state-tracking in m'n entities te implementeren. (Maw, een property die aangeeft of m'n entity nieuw, gewijzigd, verwijderd, ... is). Echter, dit heeft dan weer nadelen:
- het is fragile (je moet als programmeur er iedere keer voor zorgen dat je entity als 'changed' is gemarkeerd iedere keer je iets wijzigt. Maw, in iedere property setter zal je een 'MarkDirty()' method oid moeten aanroepen. Dit is vervelend werk, en een foutje is snel gebeurd.
- je bypassed daarmee een beetje hetgeen wat NHibernate voor jou kan doen. Trouwens, Hibernate zorgt ervoor dat geassocieerde entities ook automatisch ge-updated worden, dus hier zit je ook met een probleempje.
Nu vroeg ik me af hoe anderen een dergelijk probleem opgelost hebben ? Gebruik je een volledig andere werkwijze ? Ga je gebruik maken van DTO's die je dan weer mapped met je business classes ? etc...
Dit is hoe ik de structuur zie:
De client communiceert mbhv remote calls met de service layer. Om een object op te halen, zal de client dus bv een remote call maken die er als volgt uit ziet:
code:
1
| Customer c = RemoteProxy.GetCustomer (1); |
Customer is hier een entity class die zich in het Domain Model bevindt.
De client kan hier een aantal mutaties gaan uitvoeren op Customer, en deze later dan gaan saven :
code:
1
| RemoteProxy.SaveCustomer(c); |
Het probleem dat ik hier zie, is 2 - ledig:
- Mijn client kan niet weten of mijn Customer object nu al of niet gewijzigd is; mijn entities hebben nl. geen state-tracking, aangezien NHibernate dit verzorgt dmv zijn ISession unit-of-work.
De kans is dus groot dat ik een onnodige remote call doe.
- Aangezien ik in een remote situatie werk, zijn mijn remote-methods stateless. Dwz dat mijn SaveCustomer method een andere ISession (een nieuwe) zal gebruiken om mijn Customer object te saven. In het geval van NHibernate betekent dit dus ook dat NHibernate niet weet of hij mijn Customer nu eigenlijk moet updaten , of niet. Dit kan dan weer problemen opleveren als je entities een version, lastupdated, lastupdatedby property bijhouden; dit kan maw tot verkeerde informatie in de DB leiden. (lastupdated, version, lastupdated by kunnen ten onrechte aangepast worden als er niets aan mijn entity veranderd is).
Nu zie ik wel een oplossing, en dat is om een soort van state-tracking in m'n entities te implementeren. (Maw, een property die aangeeft of m'n entity nieuw, gewijzigd, verwijderd, ... is). Echter, dit heeft dan weer nadelen:
- het is fragile (je moet als programmeur er iedere keer voor zorgen dat je entity als 'changed' is gemarkeerd iedere keer je iets wijzigt. Maw, in iedere property setter zal je een 'MarkDirty()' method oid moeten aanroepen. Dit is vervelend werk, en een foutje is snel gebeurd.
- je bypassed daarmee een beetje hetgeen wat NHibernate voor jou kan doen. Trouwens, Hibernate zorgt ervoor dat geassocieerde entities ook automatisch ge-updated worden, dus hier zit je ook met een probleempje.
Nu vroeg ik me af hoe anderen een dergelijk probleem opgelost hebben ? Gebruik je een volledig andere werkwijze ? Ga je gebruik maken van DTO's die je dan weer mapped met je business classes ? etc...
https://fgheysels.github.io/
:strip_icc():strip_exif()/u/47583/ollie.jpg?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
Ik zou zeggen, kijk eens naar o/r mappers die het wel goed oplossen 
