id property in object wrappen, of een andere oplossing?

[Hopscotch]

Ik heb momenteel een discussie met collega's over het volgende:

In onze codebase hebben we een Model class, deze implementeert een ModelInterface.
Het object is vooral een propertybag met getters en setters, onder andere getId() en setId($id),
deze getters en setters staan ook in de interface.

Er zijn functies die enkel de id van het model nodig hebben, echter enkel een int of string aan de functie meegeven is niet zo fraai, dus wordt altijd het gehele model object meegegeven, maar soms hoeft deze helemaal niet ingeladen te worden omdat je enkel in het id geïnteresseerd bent en het model object is vrij zwaar.

Daarom is er een ModelReference object in het leven geroepen. Deze implementeert de ModelInterface, maar bij alle functies behalve de get en set id wordt een NotImplementedException gegooid.
Een functie die enkel een id nodig heeft vraagt om een ModelInterface dus je kan er zo een volledig model ingooien als je die toch al hebt, maar ook enkel een reference.

Dit vind ik een monsterlijke oplossing omdat het een leugen is, je zegt dat je een interface implementeert, maar doet dat eigenlijk niet. En in de declaratie van de functie is niet duidelijk of je aan een reference genoeg hebt, zo kan je per ongeluk een reference meegeven aan een functie die andere functionaliteit van de model wil gebruiken en als je het niet zeker weet geef je maar het volledige model mee voor de zekerheid en ga je die alsnog inladen terwijl je die misschien niet eens nodig hebt.

Ik heb voorgesteld om de ModelReference te deprecaten en het id veld in een model te wrappen in een ModelId value object zodat we die voortaan aan een functie mee kunnen geven die enkel de ID nodig heeft.

Mijn collega's zijn echter nog niet overtuigd, ze vinden een wrapper-class overkill en onnodig veel code en vinden het idee van een gedeelde interface van een model en een modelreference een groot goed. Een idee zou bijvoorbeeld kunnen zijn om een ModelReferenceInterface in het leven te roepen. De ModelReference implementeert dan nog enkel deze interface en de ModelInterface kan deze extenden. Echter dan moet op alle plekken waar nu een ModelInterface gevraagd wordt en een ModelReference gegeven wordt de signature van de functie worden aangepast.

Een andere optie die voorbij kwam was om een proxy te gebruiken. We gebruiken al een proxy voor de Model class en we zouden de class zo kunnen inrichten dat enkel de id direct wordt ingeladen en alle andere properties via de proxy. Ik heb daar zelf geen goed gevoel bij, maar ik heb eigenlijk niet de argumenten waarom niet.

Graag hoor ik hoe jullie dit op zouden lossen en natuurlijk vooral ook waarom.

[jip_86]

Er zijn functies die enkel de id van het model nodig hebben, echter enkel een int of string aan de functie meegeven is niet zo fraai,

Dus omdat een int of string niet fraai is, is er een interface gekomen vol met NotImplementedExceptions? Dan zou er sowieso al een belletje moeten gaan rinkelen dat dit niet de manier is om dit op te lossen.

Mijn voorkeur zou ook richting jouw ModelReferenceInterface oplossing gaan. Maar zit je wel met een aanpassing in de signature. Is misschien te tweaken door evt je huidige ModelReference lazy te maken. Dat je zodra je aan een van die NotImpelmented properties komt hij alsnog het echte model gaat inladen intern zodat het niet onderuit gaat.

[NMe]

Welke taal en welk ORM gebruik je? Ik gok op PHP gezien je setId($id). Gebruik je toevallig Doctrine voor je ORM? Daar los je dit namelijk op door getReference() te gebruiken op je entitymanager in plaats van get(). Je krijgt dan gewoon een object terug van de klasse die bij je entity hoort, maar daarin is alleen het ID gevuld. Pas als je daadwerkelijk waardes gaat opvragen gaat Doctrine het object hydraten.

Zelfs als je geen Doctrine gebruikt: misschien ondersteunt de ORM die je wél gebruikt dit ook al native?

[Hopscotch]

@Jip, die class met NotImplementedExceptions was er al een tijdje toen ik er kwam werken.

@NMe php inderdaad, maar geen ORM, we gebruiken repositories waar we SQL queries in schrijven om de benodigde data op te halen.

[Byron010]

Hopscotch schreef op woensdag 30 november 2016 @ 17:17:

Er zijn functies die enkel de id van het model nodig hebben, echter enkel een int of string aan de functie meegeven is niet zo fraai, dus wordt altijd het gehele model object meegegeven, maar soms hoeft deze helemaal niet ingeladen te worden omdat je enkel in het id geïnteresseerd bent en het model object is vrij zwaar.

Waarom is enkel het benodigde doorgeven niet zo fraai? dat is toch precies wat je wilt hebben.

Nou werk ik niet met PHP dus kan zijn dat het niet 1:1 over te nemen is. Maar het eerste waar ik aan denk zijn viewmodels. Met een viewmodel kan je (in ASP.Net teminste) de specifieke properties van model(s) pakken die je nodig hebt. Hierdoor krijg je niet te veel informatie en heb je ook de mogelijkheid om data van verschillende models te combineren in 1 view.

[Ventieldopje]

Wat NMe zegt, zorgen dat je je model kan lazy-loaden. De meeste moderne ORM's ondersteunen dat wel meen ik, Doctrine is er een van

[ChaZy]

lazy-loaden is een optie maar dit kan ook performance bottlenecks veroorzaken plus daarbij ben ik het eens met de topic starter eens dat je een niet een interface moet implementeren maar vervolgens NotImplementedExceptions gaat gooien... Dit is een hele sterke indicatie dat er inderdaad een andere oplossing gekozen moet/kan worden.

Misschien helpt dit een beetje, ik kon er niet direct meer informatie over vinden, maar in Domain Driven Design van Vaugh Vernon wordt er gebruik gemaakt van het concept "Descriptor(s)". Simpel gezegd is het een class die genoeg informatie bevat om een entity te "beschrijven"

Hier is een voorbeeld:

https://github.com/Vaughn...s/DiscussionDescriptor.cs

het is wel in c# DotNet maar het principe blijft hetzelfde.

Misschien kun je ze met deze informatie overtuigen van jou standpunt.

[Hopscotch]

@Chasy, bedankt, interessant leesvoer.
@Byron, ik denk niet dat een viewmodel in dit geval heel erg nuttig is aangezien het alleen om een id veld gaat.
Helaas kunnen we hier geen ORM gebruiken vanwege legacy code.

[mulder]

Denk dat Byron zijn eerste punt wel valide is, waarom niet gewoon id doorgeven, dat is wat je nodig hebt niet meer. Klinkt anders allemaal als overdesign.

[NMe]

Eens inderdaad. Als je geen ORM kan of wil gebruiken en als je in je eigen reference-oplossing toch al geen auto-hydrate inbouwt dan kun je net zo goed gewoon ID's doorgeven.