[alg] Hoe diep verbind je je classes

[pjvandesande]

Duidelijk zo'n titel, maar ik kon er niets beters van maken.

Vanmorgen begonnen met een nieuw project, niet groot maar alles heeft betrekking op elkaar. Een werknemer heeft o.a.: verzoeken, beschikbaarheid, salaris, authorisatie.

De Customer class is dus voorzien van een hoop deep linking, hij heeft een RequestCollection, AvailabilityCollection. Een Availability is weer voorzien van een ShiftCollection etc, dit gaat vrij ver door.

Ik wil dit niet elke keer ophalen, om het niet voor me GUI elke keer op te halen heb ik daar speciale GUI classes voor:

code:

class CustomerGuiHelper
{
    private int _id;
    private string _name;
    
    ...
}

Maar in sommige schermen heb ik de Employee nodig en bijvoorbeeld de vijf laatste shifts of een Employee en ze availability.

Nu kan ik hiervoor ook weer GuiHelper classes voor aanmaken, maar dan krijg ik er zo 40 bij en dat maakt het niet echt overzichtelijk. Wat er ook nog bij komt is dat je Repository een 40 tal methods erbij krijgt, wilt je ook niet.

Hoe gaan jullie hiermee om? Haal je je hele Customer object op, met alles er op en er aan en filter je hier alles uit of gebruik je wel GuiHelpers?

[Eelke Spaak]

Ik programmeer in Java, en als ik iets nodig heb waar jij een GuiHelper voor voorstelt dan haal ik gewoon 'legere' objecten op. Dus bij een Customer bijvoorbeeld, die normaal gesproken allerlei collections heeft, selecteer ik alleen de ID en de name.

Dit realiseer ik overigens met Hibernate; ik weet niet of je iets soortgelijks gebruikt. Tevens is het uiteraard nodig dat de collections niet per se gevuld hoeven te zijn in het object.

[whoami]

Gaat het nu over klanten, of over werknemers ?

Wat je kan doen, is gebruik maken van lazy loading. Dus , enkel de collectie laden als je ze daadwerkelijk nodig hebt.

[pjvandesande]

Opzich is er natuurlijk niets mis mee om het niet allemaal aan elkaar te verbinden en alles dingen op te vragen wanneer je ze nodig hebt. Maar dan zit je er weer mee dat als je van 5 employees de shifts nodig hebt dat je die los hebt van je employee instanties. Dit werkt weer niet handig.

Eelke Spaak schreef op woensdag 30 november 2005 @ 10:46:
Ik programmeer in Java, en als ik iets nodig heb waar jij een GuiHelper voor voorstelt dan haal ik gewoon 'legere' objecten op. Dus bij een Customer bijvoorbeeld, die normaal gesproken allerlei collections heeft, selecteer ik alleen de ID en de name.

Alleen dan krijg ik een hele hoop GuiHelper's, bijvoorbeeld 1 maar alleen wat shift's en 1 met alleen availability en de anderen weer requests die goedgekeurd zijn etc..

whoami schreef op woensdag 30 november 2005 @ 10:48:
Gaat het nu over klanten, of over werknemers ?

Wat je kan doen, is gebruik maken van lazy loading. Dus , enkel de collectie laden als je ze daadwerkelijk nodig hebt.

Sorry, ben gewend een voorbeeld te tikken met Klanten

Maar lazy-loading schoot mij ook als eerste binnen, je werkt dan namelijk met je normalen objecten, alleen als er 500 shifts zijn voor een employee (wel heel erg extreem) gaat hij die alles 500 ophalen als ik er eigen maar 1 nodig heb of ga je dit ook weer filteren?

[ Voor 15% gewijzigd door pjvandesande op 30-11-2005 10:59 ]

[Eelke Spaak]

questa schreef op woensdag 30 november 2005 @ 10:53:
[...]


Alleen dan krijg ik een hele hoop GuiHelper's, bijvoorbeeld 1 maar alleen wat shift's en 1 met alleen availability en de anderen weer requests die goedgekeurd zijn etc..

Dat bedoelde ik niet; ik bedoelde eigenlijk ook lazy loading

Maar lazy-loading schoot mij ook als eerste binnen, je werkt dan namelijk met je normalen objecten, alleen als er 500 shifts zijn voor een employee (wel heel erg extreem) gaat hij die alles 500 ophalen als ik er eigen maar 1 nodig heb of ga je dit ook weer filteren?

Als je er maar één nodig hebt kan je die ook nog apart ophalen, maar hoe weet je welke ene je moet hebben? Je kan ook een complete collection ophalen, maar van elk object in die collection weer alleen de naam en de ID.

[pjvandesande]

Eelke Spaak schreef op woensdag 30 november 2005 @ 11:10:
[...]

Dat bedoelde ik niet; ik bedoelde eigenlijk ook lazy loading


[...]

Als je er maar één nodig hebt kan je die ook nog apart ophalen, maar hoe weet je welke ene je moet hebben? Je kan ook een complete collection ophalen, maar van elk object in die collection weer alleen de naam en de ID.

En waar specificeer je dan wat je precies nodig hebt?

Stel ik wil de shift hebben met id 5, dan zou ik devolgende code tikken bij lazy-loading:

code:

Shift shift = employee.Shifts.GetById( 5 );

De GetById method loopt door de gehele collectie en zoekt de shift op met het id 5. Alleen nu is dus de _shiftCollection nog null, maar deze zal gevult worden zodra hij opgevraagt word. Maar lazy-loading zal alles ophalen, want ik vraag in eerste instantie op (_shiftCollection).

[Eelke Spaak]

questa schreef op woensdag 30 november 2005 @ 11:16:
[...]


En waar specificeer je dan wat je precies nodig hebt?

Stel ik wil de shift hebben met id 5, dan zou ik devolgende code tikken bij lazy-loading:

code:

Shift shift = employee.Shifts.GetById( 5 );

De GetById method loopt door de gehele collectie en zoekt de shift op met het id 5. Alleen nu is dus de _shiftCollection nog null, maar deze zal gevult worden zodra hij opgevraagt word. Maar lazy-loading zal alles ophalen, want ik vraag in eerste instantie op (_shiftCollection).

Dat is een probleem voor je persistence implementatie. Je kan de aanroep GetById naar een collection natuurlijk zo gaan schrijven dat 'ie het met SQL ophaalt:

code:

SELECT * FROM shifts WHERE id = 5

maar ik weet niet of dat mogelijk is met a) .NET en b) je eigen persistence implementatie.

Een oplossing die ik zou gebruiken voor dit probleem is het object gewoon ophalen met je ShiftsDao (=Repository?) en dan vragen om het object dat voldoet aan de eisen id = 5 en employee = je employee object. Eigenlijk zou dat laatste niet eens hoeven, want id = 5 identificeert je Shift natuurlijk hoogstwaarschijnlijk al uniek.

[whoami]

Waarom is het een probleem om de ganse collectie op te vragen ?
Dit doe je toch met één query ?

[pjvandesande]

whoami schreef op woensdag 30 november 2005 @ 11:25:
Waarom is het een probleem om de ganse collectie op te vragen ?
Dit doe je toch met één query ?

Precies, maar _shiftCollection is null, dus deze zal eerst gevult worden met de huidige Lazy-loading implementatie.

Ik kan het natuurlijk via de ShiftRepository.FindById( int id ); ophalen, maar het ging even om het idee.

Wanneer vul ik dan precies mijn _shiftCollection dmv lady-loading en wanneer laad ik deze niet in maar selecteer ik er alleen 1 met het id?

Ook een probleem bij lazy-loading is dat er ik als ik wel alle shifts nodig heb bij me employee instantie eerst me employee geladen word met een sessie. En daarna als ik de shifts opvraag hij weer een nieuwe sessie moet starten en de zooi ophalen, dit had veel beter in 1 keer gekunt.

Een anderen mogelijkheid is dus om de Employee class een ShiftCollection te geven. Dan haal je het dus gewoon altijd zelf op:

code:

Session session = Session.Create();
session.Open();
Employee employee = _employeeRepository.FindById( session, 5 );
ShiftCollection shifts = _shiftRepository.FindByEmployee( session, employee );
session.Close();

Nu gebeurt alles mooi binnen 1 sessie.

[Confusion]

questa schreef op woensdag 30 november 2005 @ 12:49:
Wanneer vul ik dan precies mijn _shiftCollection dmv lady-loading en wanneer laad ik deze niet in maar selecteer ik er alleen 1 met het id?

Dat kunnen wij toch niet voor je bepalen? Jij geeft in je eerst post aan dat je het niet iedere keer wilt ophalen, maar je geeft niet aan waarom. Heb je teveel dataverkeer, is het te traag? Of ben je iets aan het optimaliseren dat helemaal niet geoptimaliseerd hoeft te worden? Als je enorme collecties op onvoorspelbare momenten nodig hebt, dan zijn er twee mogelijkheden: de gegevens in het geheugen voorhanden houden, of, als dat niet kan, de wachttijd voor lief nemen. Zonder de gebruikelijke manier waarop het systeem zal worden gebruikt te kennen kan niemand je zinnig advies geven.