[OO] Entiteiten referenties

[Zyphrax]

In het project waar wij aan werken is er gekozen voor een bepaalde opzet, om de aanpak te illustereren gebruik ik als voorbeeld Company en Person:

Twee entiteiten Company en Person
(deze bevatten geen methoden, maar puur fields en properties).
Een Company heeft bijv. een Name
Een Person heeft bijv. een Company en een First name en Last Name

Voor iedere entiteit een Home klasse
(deze bevatten methoden, business logic)
Zowel Company als Person heeft o.a. een GetByID/GetAll/Save/Delete methode

Voor iedere entiteit een DAO klasse
(deze bevatten methoden voor communicatie met de database)
Zowel Company als Person heeft o.a. een RetrieveByID/RetrieveAll/Save/Delete methode

Tot zover weinig spannends...

Stel je voor dat je een Person op wilt vragen. Deze Person heeft omdat deze bij een bepaalde Company hoort in de database een Company ID. Vanuit je entiteiten bewerkstellig je dit door te zeggen een Person heeft een Company. Maar als je nu PUUR een Person wilt laden, moet je eigenlijk ook al de Company erbij laden vanwege de referentie. Bij dit soort kleine entiteiten kan dat, maar bij grotere of entiteiten met veel relaties naar andere zorgt dat voor veel extra bandbreedte/database instructies.

Je kan zeggen: laad dan de Person en creeer een nieuw Company object waarvan je alleen het ID vult. Nadeel hiervan is, is dat als je later met die Person aan de slag gaat, je vrij moeilijk kan bepalen of de bijbehorende Company volledig ingeladen is of niet (omdat ID hier meestal een indicator voor is).

Je kan ook zeggen: sla bij een Person zowel een Company object als een Company ID integer op en probeer dit via de properties netjes in sync te houden. Maar dat is ook niet echt een mooie oplossing.

Lazy loading zou kunnen, maar daar hangen dezelfde nadelen aan als oplossing 1. Daarnaast krijg je dan veel functionaliteit in je entiteiten, wat niet wenselijk is.

Weet iemand hier een nette oplossing voor, het lijkt me een vrij veel voorkomend probleem? Ik ben benieuwd naar jullie aanpak.

[zneek]

lazy-loading is je antwoord.

Of je zou kunnen gaan werken met Value objecten, en in die value objecten alleen de properties stoppen die geen relatie voorstellen.

Zelf zou ik blind voor lazy-loading gaan, maar alleen op Collection properties (de 1 kant van een 1 op veel). Sterker nog, ik kies er ook regelmatig voor om die Collection properties niet te gebruiken, en ipv daarvan een finder te implementeren die hetzelfde resultaat oplevert.

[Zyphrax]

Hoe zou je die lazy loading hier dan realiseren?
Ik wil de entiteiten eigenlijk puur entiteiten houden (data-vessels) en geen intelligente properties als het even kan.

[zneek]

Zyphrax schreef op vrijdag 18 februari 2005 @ 00:11:
Hoe zou je die lazy loading hier dan realiseren?
Ik wil de entiteiten eigenlijk puur entiteiten houden (data-vessels) en geen intelligente properties als het even kan.

Ken je Hibernate? Dat is je oplossing. www.hibernate.org

trouwens, daarbij neem ik aan dat je Java gebruikt Anders gaat mijn verhaal mooi niet op.

[Zyphrax]

Ai, nee ik Dot Net (C#)

[zneek]

Zyphrax schreef op vrijdag 18 februari 2005 @ 00:19:
Ai, nee ik Dot Net (C#)

Dat is zonde, dan is er geen bruikbare serieuze OR mapper voor jou. Alhoewel, NHibernate is in de maak, maar nog niet stable. Terug te vinden op sourceforge.net.

En voor .Net zou ik zo geen oplossing weten. Not my cup of tea.

[Alarmnummer]

Zyphrax schreef op vrijdag 18 februari 2005 @ 00:11:
Hoe zou je die lazy loading hier dan realiseren?
Ik wil de entiteiten eigenlijk puur entiteiten houden (data-vessels) en geen intelligente properties als het even kan.

AnemicDomainModel

[zneek]

Alarmnummer schreef op vrijdag 18 februari 2005 @ 06:22:
[...]

AnemicDomainModel

Wat bedoel je daar mee Alarmnummer? Je gebruikt zelf de in dat artikel beschreven aanpak toch ook?

@TS: Een simpele oplossing die ik zo kan bedenken: maak van je relatie een normale property, laad deze property niet in bij het laden van de entity, maar zorg dat de getter bij een aanroep controleert of de property gevuld is, zo nee, dan haalt hij het gerelateerde object op en zet hem in de property.

[P_de_B]

zneek schreef op vrijdag 18 februari 2005 @ 00:21:
[...]


Dat is zonde, dan is er geen bruikbare serieuze OR mapper voor jou. Alhoewel, NHibernate is in de maak, maar nog niet stable. Terug te vinden op sourceforge.net.

En voor .Net zou ik zo geen oplossing weten. Not my cup of tea.

www.llblgen.com is best serieus hoor? Wat mist er volgens jou?

[EfBe]

zneek schreef op vrijdag 18 februari 2005 @ 00:21:
Dat is zonde, dan is er geen bruikbare serieuze OR mapper voor jou. Alhoewel, NHibernate is in de maak, maar nog niet stable. Terug te vinden op sourceforge.net.

Er zijn zat serieuze O/R mappers voor .NET, waar nHibernate overigens niet bij hoort (nog), vanwege de beta status en de belabberde sourcecode kwaliteit.

En voor .Net zou ik zo geen oplossing weten. Not my cup of tea.

Je weet er weinig van maar doet wel uitspraken? Beetje raar, niet?

Overigens vraagt TS een oplossing voor zn probleem op programmatechnisch gebied, niet een of andere toolkit. .

@TS: je hebt 2 opties: lazy loading en prefetch paths/spans.
Lazy loading moet worden getriggerd. Dus als jij myPerson.Company benadert en die is nog niet ingeladen, dan moet de persistence layer dat voor je doen, echter dat weet de persistence layer alleen als er iets van logica in de property zit. Dit kan worden gerealiseerd door zg. stubs te genereren at runtime mbv de codedom, wanneer je geen intelligente properties wilt gebruiken, OF je plaatst lazy loading trigger code in de properties als je daar niet zo mee zit.

Prefetch paths zijn graph specificaties die je opgeeft aan de persistence layer waarbij de persistence layer per graph node een fetch & merge doet. Dit houdt bv in dat wanneer jij 10 companies ophaalt en al hun personeel, je 2 queries krijgt: 1 voor company en 1 voor person en die worden dan gemerged door de persistence layer en zo opgeleverd aan je.

Dit is in veel gevallen efficienter dan lazy loading. Lazy loading is alleen efficienter indien je een grote set objects hebt en weinig tot geen access van related objects.

[ Voor 44% gewijzigd door EfBe op 18-02-2005 08:39 ]

[Alarmnummer]

zneek schreef op vrijdag 18 februari 2005 @ 08:25:
[...]
Wat bedoel je daar mee Alarmnummer? Je gebruikt zelf de in dat artikel beschreven aanpak toch ook?

Ik heb het idd gebruikt maar het wil niet zeggen dat het correct is (ik erger me er ook groen en geel aan). Voor een gedeelte zijn domein objecten normale objecten en als iemand op normale objecten totaal geen domein logica zou plaatsen, dan zal ik daar hoogstwaarschijnlijk wel een enorme portie kritiek op leveren. (Je krijgt sowieso problemen met overerving). Aan de andere kant worden domein objecten vaak in omgevingen gebruikt met ondoordachte eisen. Bv een entiteit in de weblayer wordt vaak gebruikt om direct data aan te koppelen. Hierdoor kan je niet meer de garantie geven dat je objecten in een consistente toestand staan. Op bepaalde tijdstippen is het object niet goed...

Hetzelfde probleem zie ik bv bij hibernate. Daar moet je ook een argumentloze constructor hebben. Ik ben al een aantal weken aan het zoeken naar antwoorden op mijn vragen mbt domein objecten, maar ik heb ze tot zover niet echt kunnen vinden. Ik ben trouwens niet de enigste met deze problemen, want op het Spring forum (waar ik vaak kom) zie ik exact dezelfde vragen langskomen. Persoonlijk vind ik deze aanpak met domein objecten maar een gapende wond in mijn systeem.

@TS: Een simpele oplossing die ik zo kan bedenken: maak van je relatie een normale property, laad deze property niet in bij het laden van de entity, maar zorg dat de getter bij een aanroep controleert of de property gevuld is, zo nee, dan haalt hij het gerelateerde object op en zet hem in de property.

Een simpele maar vervelende oplossing. Jij gaat nu de logica van persitence mixen met domein logica .
[edit]
\me is vrij nieuw in domein objecten die gepersist moeten worden. Dus misschien vandaar mijn eisen. Ik ben 100% controle gewend en ik ga niet voor minder.

[ Voor 7% gewijzigd door Alarmnummer op 18-02-2005 08:47 ]

[EfBe]

Alarmnummer schreef op vrijdag 18 februari 2005 @ 08:38:
Ik heb het idd gebruikt maar het wil niet zeggen dat het correct is (ik erger me er ook groen en geel aan). Voor een gedeelte zijn domein objecten normale objecten en als iemand op normale objecten totaal geen domein logica zou plaatsen, dan zal ik daar hoogstwaarschijnlijk wel een enorme portie kritiek op leveren. (Je krijgt sowieso problemen met overerving). Aan de andere kant worden domein objecten vaak in omgevingen gebruikt met ondoordachte eisen. Bv een entiteit in de weblayer wordt vaak gebruikt om direct data aan te koppelen. Hierdoor kan je niet meer de garantie geven dat je objecten in een consistente toestand staan. Op bepaalde tijdstippen is het object niet goed...

Sinds wanneer is iets een onomstotelijk feit wanneer meneer Fowler iets roept? Het door jouw aangehaalde anti-pattern staat een beetje haaks op wat bv Yourdon vertelt en wat gangbaar is in grote systemen waarbij je cross-entity behavior niet in entities zelf plaatst maar erbuiten, omdat dat overzichtelijker is.

Er wordt wat te zwart/wit gedacht. Je hebt ruwweg 3 soorten behavior/rules voor entities:
1) per field rules (id > 0)
2) per entity rules (shipping date >= orderdate)
3) cross entity rules (order.Valid = (product.Inventory.Stock > 0))

1) en 2) kun je prima onderbrengen IN de entity classes. 3) wordt lastiger. Je kunt dat doen, maar er zijn ook goede argumenten om het niet te doen. Het stuit me meer en meer tegen de borst dat men maar begint te roepen dat 3) altijd in een entity geplaatst dient te worden. Men gaat dan aan het feit voorbij dat dat helemaal niet zo vanzelfsprekend is. Namelijk: waar plaats je een cross-entity rule wanneer er 3 entities bij betrokken zijn? in 1 van de 3 en zo ja welke?

Het zou mooi zijn als de Fowler-supporters zich wat meer bedachten dat wat zij denken dat waar is, niet meer is dan een mening. Er is nl. itt bv Yourdon geen wetenschappelijk onderzoek gedaan naar wat zij denken wat juist is of niet.

Hetzelfde probleem zie ik bv bij hibernate. Daar moet je ook een argumentloze constructor hebben. Ik ben al een aantal weken aan het zoeken naar antwoorden op mijn vragen mbt domein objecten, maar ik heb ze tot zover niet echt kunnen vinden. Ik ben trouwens niet de enigste met deze problemen, want op het Spring forum (waar ik vaak kom) zie ik exact dezelfde vragen langskomen. Persoonlijk vind ik deze aanpak met domein objecten maar een gapende wond in mijn systeem.

Wellicht is die argumentloze constructor voor de proxies die ze genereren voor lazy loading triggering? (gok, maar kijkend naar deserializer eisen in .NET kan ik het me voorstellen)

Een simpele maar vervelende oplossing. Jij gaat nu de logica van persitance mixen met domein logica.

Je kunt discussieren of dat goed is of niet. JIJ roept bij voorbaat dat het fout is, ik denk dat dat een verkeerde benadering is. Je kunt nl. beargumenteren dat persistence logica een deel van de behavior is van een entity object, het is nl. behavior. Je kunt ook beargumenteren dat het geen behavior is van een entity object, want het is onderdeel van overhead code en niet van de plain entity rule code zoals 1) en 2). Wat juist is is een spelletje welles/nietes: de een vindt dit, de ander dat. Er is nl. geen enige juiste weg die altijd werkt.

Je ageert ook tegen gui support code in entity classes. Helemaal mee eens. Je gaat echter alweer voorbij aan een aantal zaken. De voornaamste is dat de platforms Java en .NET single inheritance zijn. Wil je dus iets met je entity data doen in bv databinding scenario's, dan heb je 2 opties:
a) databinding support code in de entity classes bouwen
b) data overpompen in een gui-support object met dezelfde stuctuur als je entity

b) is onzinnig, a) is niet zo fraai, maar pragmatisch gezien de 'beste weg'. Je hebt natuurlijk ook nog een optie 'c)' : niets doen en dan maar wat kloterige gui's. Tja...

[Alarmnummer]

EfBe schreef op vrijdag 18 februari 2005 @ 08:54:
[...]
Sinds wanneer is iets een onomstotelijk feit wanneer meneer Fowler iets roept?

Niet omdat fowler het roept. Ik gebruik/gebruikte ook functieloze objecten in het domein. En ik vond het een erg halfgebakken oplossing omdat bv functionaliteit mbt validatie overal al versnipperd ligt. Verder zijn het gewoon objecten (en dat ze ook in de db zitten vind ik minder belangrijk). Waarom zou ik geen logica erin plaatsen als de behoefte bestaat? Als ik bij een normaal object logica nodig ben dan aarzel ik geen moment om het daarin te plaatsen (als het daarin hoort), waarom moeten domein objecten nu ineens zo anders behandeld worden?

Ik heb nog geen goeie argumenten voor de functieloze aanpak gevonden.

Het door jouw aangehaalde anti-pattern staat een beetje haaks op wat bv Yourdon vertelt en wat gangbaar is in grote systemen waarbij je cross-entity behavior niet in entities zelf plaatst maar erbuiten, omdat dat overzichtelijker is.

hoho.. Ik ben gek op een goed ontwerp en deins er ook absoluut niet voor terug om functionaleit onder te brengen in een apart onderdeel als daar de behoefte voor is. Het is soms handiger om 1 stuk functionaliteit binnen 1 'manager' achtig object te hebben ipv dat het versnipperd ligt over je domein objecten. Maar dat is iets anders dan totaal geen logica meer onder te brengen in je domein objecten.

Er wordt wat te zwart/wit gedacht. Je hebt ruwweg 3 soorten behavior/rules voor entities:
1) per field rules (id > 0)
2) per entity rules (shipping date >= orderdate)
3) cross entity rules (order.Valid = (product.Inventory.Stock > 0))

1) en 2) kun je prima onderbrengen IN de entity classes.

Hier zijn we het over eens.

3) wordt lastiger. Je kunt dat doen, maar er zijn ook goede argumenten om het niet te doen. Het stuit me meer en meer tegen de borst dat men maar begint te roepen dat 3) altijd in een entity geplaatst dient te worden. Men gaat dan aan het feit voorbij dat dat helemaal niet zo vanzelfsprekend is. Namelijk: waar plaats je een cross-entity rule wanneer er 3 entities bij betrokken zijn? in 1 van de 3 en zo ja welke?

Hier ook.. en ik zou het ook niet erg vinden om dit in een geheel ander object onder te brengen. Maar dit is iets anders dan je objecten eigelijk te reduceren tot datadragers.

Het zou mooi zijn als de Fowler-supporters zich wat meer bedachten dat wat zij denken dat waar is, niet meer is dan een mening. Er is nl. itt bv Yourdon geen wetenschappelijk onderzoek gedaan naar wat zij denken wat juist is of niet.

Wat jij en fowler hier beschrijven komt imho redelijk overeen.

Wellicht is die argumentloze constructor voor de proxies die ze genereren voor lazy loading triggering? (gok, maar kijkend naar deserializer eisen in .NET kan ik het me voorstellen)

Nope... bij hibernate is het altijd verplicht.

Je kunt discussieren of dat goed is of niet. JIJ roept bij voorbaat dat het fout is, ik denk dat dat een verkeerde benadering is. Je kunt nl. beargumenteren dat persistence logica een deel van de behavior is van een entity object, het is nl. behavior. Je kunt ook beargumenteren dat het geen behavior is van een entity object, want het is onderdeel van overhead code en niet van de plain entity rule code zoals 1) en 2). Wat juist is is een spelletje welles/nietes: de een vindt dit, de ander dat. Er is nl. geen enige juiste weg die altijd werkt.

Persistence is een bepaald aspect van je domein model. Net zoals security, logging, validatie. Verschillende aspecten van je systeem wil je vaak scheiden omdat het dan beter inzichtelijk is. En het is geen kwestie van beter of niet.. Maar aan de alles-bij-elkaar-in-aanpak kleeft het nadeel dat de code erg onoverzichtelijk gaat worden en vaak ook niet meer aanpasbaar. Op het moment dat je via verschillende aspecten je core gaat enhancen dit dit probleem zich minder voor. Je hebt uiteraard wel een extra stuk complexiteit, maar goeie bytecodeenhancers, codegeneratoren, aop/proxy-tools zoals Spring kunnen dit een stuk minder vervelend maken om zo te gaan werken.

Maar om even terug te komen:
als jij een gui voor bv een persoon hebt. Werk jij dan ook met een lege huls waarin je alles gaat binden? Of maak jij een map aan waarin alle properties staan, eventueel gevalideerd zijn en dan via een of andere service call het volledig-goed-opgebouwde object terug sturen? En een andere vraag.. als je een savetodb actie hebt voor persoon, hoe vang jij hier de validatie hiervan af? En daarbij doel ik voornamelijk op rechten-validatie. Een algemene saveactie bypast als je normale 'service' methodes en alle validatie daar daar plaatsvind. Stel je hebt een Werknemer met een salaris veld. Alleen een directeur mag het salaris veld aanpassen. Gewoonlijk zou ik dan een serivce methode maken: verhoogsalaris en daarop de rollcheck doen. Maar op het moment dat je een save hebt dan kan je makkelijk hier langs komen. Hoe los jij dit op?

Je ageert ook tegen gui support code in entity classes. Helemaal mee eens. Je gaat echter alweer voorbij aan een aantal zaken. De voornaamste is dat de platforms Java en .NET single inheritance zijn. Wil je dus iets met je entity data doen in bv databinding scenario's, dan heb je 2 opties:
a) databinding support code in de entity classes bouwen
b) data overpompen in een gui-support object met dezelfde stuctuur als je entity

Jij hebt het nu weer over een bepaald aspect. Als het kan kies ik ervoor om de aspecten niet met elkaar te verweven. Als ik op dit moment dat gui probleem voor de kiezen zou krijgen zou ik een AOP proxy om die entiteit heen wikkelen waarbij alle setters worden geregistreerd. Uiteraard doe ik dit pas op het moment dat het nodig is... (kan eenvoudig met Spring).

b) is onzinnig, a) is niet zo fraai, maar pragmatisch gezien de 'beste weg'. Je hebt natuurlijk ook nog een optie 'c)' : niets doen en dan maar wat kloterige gui's. Tja...

Hmm tja.. ik heb vroeger nogal wat gui`s gemaakt in Swing en daarbij had ik ook vaak dit soort problemen. Ik zou tegenwoordig afzien om overal maar listeners aan te plakken, maar de gui gewoon maar een repaint geven.

[edit]
Mijn voornaamste probleem zit hem in het volgende:
1) ik geef mijn domein objecten uit handen (vooral als ze doorlekken naar een web/remoting layer). Hierdoor heb ik geen zicht erop wie er wat mee doet. Een algemene save methodes maakt het systeem tot een grote security-leak
2) mijn domein objecten kunnen half af zijn. De beslissingen die ik neem op basis van niet complete domein objecten kunnen verstrekkende gevolgen hebben.

Deze problemen had ik vroeger niet en die moeten opgelost worden.

[ Voor 16% gewijzigd door Alarmnummer op 18-02-2005 09:45 ]

[EfBe]

Alarmnummer schreef op vrijdag 18 februari 2005 @ 09:30:
Niet omdat fowler het roept. Ik gebruik/gebruikte ook functieloze objecten in het domein. En ik vond het een erg halfgebakken oplossing omdat bv functionaliteit mbt validatie overal al versnipperd ligt.

Maar validatie is niet altijd onder te brengen in een enkele entity. Bv of een order valide is hangt af van klantgegevens (gold customer?), repository, order grootte etc. Dit soort validatie onderbrengen in een entity is lastig.

Field validatie en entity-validatie an sig zou ik inderdaad in een entity onderbrengen, omdat de enige plek waar je dat het beste zou kunnen doen is in het entity zelf. Wel loop je dan wellicht tegen zaken aan als field rule X is geldig op voorwaarde Y maar Y verschilt per entity.

hoho.. Ik ben gek op een goed ontwerp en deins er ook absoluut niet voor terug om functionaleit onder te brengen in een apart onderdeel als daar de behoefte voor is. Het is soms handiger om 1 stuk functionaliteit binnen 1 'manager' achtig object te hebben ipv dat het versnipperd ligt over je domein objecten. Maar dat is iets anders dan totaal geen logica meer onder te brengen in je domein objecten.

Ok mee eens. Het anti-pattern van Fowler kwam anders op me over. Wellicht moet ik het nog eens lezen.

[...]
Nope... bij hibernate is het altijd verplicht.

Ik ken hibernate te slecht om hier zeker van te zijn, maar zou het niet kunnen dat hibernate altijd proxies genereert ? dit omdat lazy loading anders niet in POJO's te bewerkstelligen is (kan ook met bytecode mangling maar dat doet hibernate dacht ik niet)

Persistence is een bepaald aspect van je domein model. Net zoals security, logging, validatie.

Er is een onderscheid. Validatie gaat over de semantiek van de data in een bepaalde context. Logging, security en ook persistence gaat over het gebruik van de semantiek van de data.

Maar om even terug te komen:
als jij een gui voor bv een persoon hebt. Werk jij dan ook met een lege huls waarin je alles gaat binden? Of maak jij een map aan waarin alle properties staan, eventueel gevalideerd zijn en dan via een of andere service call het volledig-goed-opgebouwde object terug sturen?

Je bedoelt, of ik een entity aan de BL call meegeef of een method aanroep met parameters? Ik denk het eerste, tenzij vereist is dat het op methode 2 moet. Ik zie een graph van entities als een goede structuur om data in te vervoeren tussen tiers, waarom zou ik daar nieuwe objects voor maken? Dat is toch alleen maar dubbel werk, wat ook nog eens de ondoorzichtigheid vergroot, omdat je ineens met andere objects werkt dan in andere delen van de applicatie. Let wel, ik zou wel kiezen voor een persistence logic loos entity object, dus dat je een session/context/adapter achtig object nodig hebt om de graph te persisten. Dit verhoogt de verantwoordelijkheid per tier en geeft volgens mij meer inzicht in wat waar gebeurt.

En een andere vraag.. als je een savetodb actie hebt voor persoon, hoe vang jij hier de validatie hiervan af? En daarbij doel ik voornamelijk op rechten-validatie. Een algemene saveactie bypast als je normale 'service' methodes en alle validatie daar daar plaatsvind. Stel je hebt een Werknemer met een salaris veld. Alleen een directeur mag het salaris veld aanpassen. Gewoonlijk zou ik dan een serivce methode maken: verhoogsalaris en daarop de rollcheck doen. Maar op het moment dat je een save hebt dan kan je makkelijk hier langs komen. Hoe los jij dit op?

Waar je rechten-checks doet is op zich niet zo relevant. Een gebruiker kan niet handmatig iets aanpassen zonder een interface. Je zou ook kunnen kiezen voor een GUI waarin dit is geregeld mbv role based security, dus dat je niet bij de update functionaliteit kunt indien je die rechten niet hebt.

Paranoia developers roepen dan vaak dat dit niet veilig is, maar dat is IMHO onzin, want hoe moet een normale werknemer zn salaris dan ophogen als hij niet bij de update functionaliteit kan? En programma-technisch kan ik altijd cheaten als ik wil, desnoods met een commandline applicatietje dat direct op de database dingen wijzigt (zelfs met procs).

Je kunt ook kiezen voor een andere aanpak en validatie te doen in de GUI (moet sowieso) en in de lower tiers dmv een method die jij beschrijft. Ik denk dat het van de applicatie zelf afhangt wat users kunnen. Kan een user een plugin laden die via via overal bij kan in de gui, dan moet je toch zorgen dat het wat anders in elkaar zit dan wanneer je alleen via een default gui ergens iets mee kunt wijzigen.

[edit]
Mijn voornaamste probleem zit hem in het volgende:
1) ik geef mijn domein objecten uit handen (vooral als ze doorlekken naar een web/remoting layer). Hierdoor heb ik geen zicht erop wie er wat mee doet. Een algemene save methodes maakt het systeem tot een grote security-leak

Mee eens. Zodra 'distributed' erbij komt, is persistence logic eigenlijk niet te handhaven in een entity. Niet alleen omdat wellicht de database helemaal niet benaderbaar is vanaf de client, maar ook inderdaad dat je geen zicht hebt op wat er gebeurt.

Nu moet ik wel zeggen dat wanneer de client door hetzelfde team wordt gemaakt ik me wel afvraag of je die developers dan wel vertrouwd. En het andere geval, client wordt door derden gemaakt, dan weet je inderdaad niet wat er mee gebeurt dus is het enige wat je kunt doen het object volledig checken wanneer je het terugkrijgt.

2) mijn domein objecten kunnen half af zijn. De beslissingen die ik neem op basis van niet complete domein objecten kunnen verstrekkende gevolgen hebben.
Deze problemen had ik vroeger niet en die moeten opgelost worden.

Je bedoelt, de data in een entity is nog niet volledig dus je kunt nog niet saven, ik noem maar iets. ?