Relatie DAO/DTO en complexe view

[Verwijderd]

Laten we voor het gemak een blogengine als voorbeeld gebruiken.

We hebben drie tabellen:
- Artikel
- Categorie
- Reactie

De relaties zijn als volgt:
- Artikel --- (veel op één) --- Categorie
- Artikel --- (één op veel) --- Reactie

Nu hebben we voor iedere tabel een Data Transfer Object (DTO) gemaakt en een Data Access Object (DAO). De DAO's en DTO's beperken zich, zoals de goede manier van doen, uitsluitend tot hun eigen tabel.

Stel we hebben nu de view van een overzicht van de meest recente blog artikelen. Per artikel worden zaken getoond zoals titel, body en datum, maar ook de categorie en het aantal reacties. De view moet dus gebruik maken van een samenvoeging van verschillende entiteiten (Artikel, Categorie (de naam van de categorie) en Reactie (aantal reacties)).

Wat is nu de goede manier om een relatie te leggen tussen de DAO's/DTO's (die beperkt zijn tot één entiteit) en de 'complexe' view? Is het een goede manier van doen om een soort view DTO object in te zetten die de benodigde data samenvoegt en aanbiedt aan de view?

Alvast bedankt!

[mOrPhie]

Waarom zou je DTO beperkt zijn tot 1 entiteit? Als jij een DTO maakt voor exact datgene wat je nodig hebt, dan is daar niets mis mee. Soms worden die ook nog wel 'ns "Combined Objects" genoemd. Of je er een apart DAO object voor maakt, is aan jou. Kun je ermee leven, dat er (eventueel read-only) attributen in je DTO zitten die je niet altijd gebruikt?

Doe je trouwens alles zelf, of gebruik je een OR/M? Veel OR/M's hebben namelijk gewoon de optie om gerelateerde objecten aan te spreken. Bijvoorbeeld de naam van de categorie van een artikel, of een lijst van comments van een artikel. Deze werken meestal op basis van lazy loading. Je moet dus even aangeven dat het geladen moet worden, zodra je het wilt hebben.

[ Voor 34% gewijzigd door mOrPhie op 28-07-2008 10:53 ]

[Verwijderd]

mOrPhie schreef op maandag 28 juli 2008 @ 10:47:
Waarom zou je DTO beperkt zijn tot 1 entiteit? Als jij een DTO maakt voor exact datgene wat je nodig hebt, dan is daar niets mis mee. Soms worden die ook nog wel 'ns "Combined Objects" genoemd. Of je er een apart DAO object voor maakt, is aan jou. Kun je ermee leven, dat er (eventueel read-only) attributen in je DTO zitten die je niet altijd gebruikt?

Ik kan er mee leven, wanneer het een goede manier van doen is . Dat klinkt misschien wat vreemd, maar waar het mij om gaat is dat ik geen oplossingen gebruik die onlogisch zijn en waarvoor betere, standaard, alternatieven (design patterns) bestaan.

Ik zelf vind het wel goed om in de datalaag alleen één op één relaties te hebben tussen objecten en tabellen, dus één DAO en één DTO voor één tabel. Wanneer je een DAO en/of DTO in de datalaag hebt zitten die eigenlijk alleen bedoeld is voor de view, dan lijkt het mij dat je model niet meer zuiver is. Ik zou dan denken aan de business laag die de juiste gegevens samenvoegt uit de datalaag en dat in een speciale DTO aan de view aanlevert. Op die manier houd je de datalaag en de view volledig gescheiden. Of zie ik dit verkeerd en benader ik dit te krampachtig?

mOrPhie schreef op maandag 28 juli 2008 @ 10:47:
Doe je trouwens alles zelf, of gebruik je een OR/M? Veel OR/M's hebben namelijk gewoon de optie om gerelateerde objecten aan te spreken. Bijvoorbeeld de naam van de categorie van een artikel, of een lijst van comments van een artikel. Deze werken meestal op basis van lazy loading. Je moet dus even aangeven dat het geladen moet worden, zodra je het wilt hebben.

Dit is meer een denkbeeldige situatie, maar waarbij inderdaad alles zelf gedaan wordt. Dus geen OR/M.

[ Voor 18% gewijzigd door Verwijderd op 28-07-2008 10:58 ]

[mOrPhie]

Verwijderd schreef op maandag 28 juli 2008 @ 10:55:
[...]

Ik zelf vind het wel goed om in de datalaag alleen één op één relaties te hebben tussen objecten en tabellen, dus één DAO en één DTO voor één tabel. Wanneer je een DAO en/of DTO in de datalaag hebt zitten die eigenlijk alleen bedoeld is voor de view, dan lijkt het mij dat je model niet meer zuiver is. Ik zou dan denken aan de business laag die de juiste gegevens samenvoegt uit de datalaag en dat in een speciale DTO aan de view aanlevert. Op die manier houd je de datalaag en de view volledig gescheiden. Of zie ik dit verkeerd en benader ik dit te krampachtig?

Dan is je code "zuiver", maar wel trager. Op BL niveau praat je in processen. Het koppelen van twee objecten is niet zozeer onderdeel van een proces. Je zou je daar niet meer druk mogen maken over de data. Daar heb je de DTO voor en daar doe je alles in. Het is verstandiger om op dataniveau al joins te doen, dan zelf deze joins te gaan simuleren in je DTO of zelfs je BL.

Als het goed is, is er een verschil tussen het Business Model en je Data Model. Deze is meestal niet 1 op 1. En je hoeft niets onzuiver te maken. Als je een mapje maakt met "Combined Objects", dan is het heel erg duidelijk, dat dat objecten zijn, die niet 1 op 1 mappen op het data model. Toegegeven, het is een kwestie van smaak, maar het is verkeerd om te denken dat gecombineerde objecten "onzuiver" zijn. Zolang je hier in de architectuur rekening mee houdt, is er niets mis mee. Het is dus niet zo, dat elke developer zomaar een gecombineerd object kan maken. Dit kun je afstemmen en afleiden van je specificaties en use cases. In dit geval een "recente artikelen" view.

Er bestaan in architectuur geen "standaarden" trouwens. Hooguit richtlijnen en patronen. Als je je aan zogehete standaarden zou houden en vervolgens trage foutgevoelige code maakt, dan heb je nog niets aan eventuele standaarden.

[whoami]

Verwijderd schreef op maandag 28 juli 2008 @ 10:55:
[...]

Ik kan er mee leven, wanneer het een goede manier van doen is .

Waarom is dat een goede manier van doen ? Ik begrijp mensen hier soms niet hoor ... Tuurlijk moet je ervoor zorgen dat je code onderhoudbaar is etc..., maar waarom toch zo moeilijk doen soms ? Waarom wringen mensen zich in allerlei bochten om dan met een oplossing voor de dag te komen die onnatuurlijk aanvoelt, waar je heel wat hebt moeten opofferen, omdat het 'goed aanvoelt' volgens bepaalde theorieën ?
Nu ben ik ook voorstander van cleane software, onderhoudbare code, ben ik een OO-zealot, maar boven alles moet je software werken en moet je code goed aanvoelen voor jou als programmeur.

Ik zelf vind het wel goed om in de datalaag alleen één op één relaties te hebben tussen objecten en tabellen, dus één DAO en één DTO voor één tabel. Wanneer je een DAO en/of DTO in de datalaag hebt zitten die eigenlijk alleen bedoeld is voor de view, dan lijkt het mij dat je model niet meer zuiver is. Ik zou dan denken aan de business laag die de juiste gegevens samenvoegt uit de datalaag en dat in een speciale DTO aan de view aanlevert. Op die manier houd je de datalaag en de view volledig gescheiden. Of zie ik dit verkeerd en benader ik dit te krampachtig?

krampachtig. En introductie van bijkomende complexiteit, die de boel alleen maar ingewikkelder maakt.
Als je met DTO's / DAO's gaat werken, doe ik het als volgt: ik heb een DTO die een entiteit voorstelt. Die kan dus gegevens bevatten die uit meerdere tabellen afkomstig is. Zeg maar dat die DTO geen 'rauwe data' bevat, maar informatie. Hij stelt een entiteit voor, en ik kan daarmee wat doen.
Om die entiteit te persisten of op te halen, heb ik een aantal DAO's als je 't zo wil noemen. Eén voor elke tabel (dat dan weer wel). Om die entiteit op te slaan of op te halen, zal ik dus meerdere DAO's nodig hebben.

/verder volledig eens met mOrphie.

[Verwijderd]

mOrPhie schreef op maandag 28 juli 2008 @ 11:06:
[...]


Dan is je code "zuiver", maar wel trager. Op BL niveau praat je in processen. Het koppelen van twee objecten is niet zozeer onderdeel van een proces. Je zou je daar niet meer druk mogen maken over de data. Daar heb je de DTO voor en daar doe je alles in. Het is verstandiger om op dataniveau al joins te doen, dan zelf deze joins te gaan simuleren in je DTO of zelfs je BL.

Als het goed is, is er een verschil tussen het Business Model en je Data Model. Deze is meestal niet 1 op 1. En je hoeft niets onzuiver te maken. Als je een mapje maakt met "Combined Objects", dan is het heel erg duidelijk, dat dat objecten zijn, die niet 1 op 1 mappen op het data model. Toegegeven, het is een kwestie van smaak, maar het is verkeerd om te denken dat gecombineerde objecten "onzuiver" zijn. Zolang je hier in de architectuur rekening mee houdt, is er niets mis mee. Het is dus niet zo, dat elke developer zomaar een gecombineerd object kan maken. Dit kun je afstemmen en afleiden van je specificaties en use cases. In dit geval een "recente artikelen" view.

Oke, dus als ik het goed begrijp zou je in de datalaag een onderscheid kunnen aanbrengen tussen data model en business model? Waarbij het business model waar nodig een samenvoeging is van verschillende entiteiten uit het data model? En het business model vormt dan vervolgens de data input voor de business logic? En wat genereert dan dan een object uit het business model? Wat voorziet deze van waarden?

Maar hoe verhoudt het business model zich dan tot de view? Want in principe vraagt de view om een bepaalde dataset die in deze opzet dus wordt geconstrueerd door het business model. Met andere woorden: het business model is afhankelijk van de view zoals die op dat moment is opgezet.

mOrPhie schreef op maandag 28 juli 2008 @ 11:06:
Er bestaan in architectuur geen "standaarden" trouwens. Hooguit richtlijnen en patronen. Als je je aan zogehete standaarden zou houden en vervolgens trage foutgevoelige code maakt, dan heb je nog niets aan eventuele standaarden.

Dat ben ik met je eens. Het gaat natuurlijk veel te ver om standaarden te ontwikkelen voor iets dat erg dynamisch is en afhankelijk van allerlei omstandigheden. Maar ik probeer wel altijd een logisch consistente architectuur te ontwerpen waarbinnen ik waar geschikt design patterns toepas. Ik ben er dan altijd wat onzeker over of ik het dan wel op de juiste manier doe.

[Verwijderd]

whoami schreef op maandag 28 juli 2008 @ 11:13:
[...]

Waarom is dat een goede manier van doen ? Ik begrijp mensen hier soms niet hoor ... Tuurlijk moet je ervoor zorgen dat je code onderhoudbaar is etc..., maar waarom toch zo moeilijk doen soms ? Waarom wringen mensen zich in allerlei bochten om dan met een oplossing voor de dag te komen die onnatuurlijk aanvoelt, waar je heel wat hebt moeten opofferen, omdat het 'goed aanvoelt' volgens bepaalde theorieën ?
Nu ben ik ook voorstander van cleane software, onderhoudbare code, ben ik een OO-zealot, maar boven alles moet je software werken en moet je code goed aanvoelen voor jou als programmeur.

Uiteindelijk maak je hiermee het punt waar het om gaat. Je kunt een stuk software slecht in elkaar zetten (door gebrek aan kennis, gemakzucht, tijdsdruk of whatever), je kunt een stuk software goed in elkaar zetten (het is logisch opgezet, is onderhoudbaar, is te begrijpen enzovoort) en je kunt een stuk software zien alsof het zich moet kunnen meten aan de heilige graal en er nachten van wakker liggen hoe je het zo elegant mogelijk kunt opzetten. Ik ben zelf vrij perfectionistisch en ben altijd op zoek naar de meest perfecte oplossingen. En als ik er dan één gevonden denk te hebben en toepas, dan ga ik twijfelen en voel me er niet zo goed meer bij. Dat is misschien iets om toch eens aan te werken.

whoami schreef op maandag 28 juli 2008 @ 11:13:
krampachtig. En introductie van bijkomende complexiteit, die de boel alleen maar ingewikkelder maakt.
Als je met DTO's / DAO's gaat werken, doe ik het als volgt: ik heb een DTO die een entiteit voorstelt. Die kan dus gegevens bevatten die uit meerdere tabellen afkomstig is. Zeg maar dat die DTO geen 'rauwe data' bevat, maar informatie. Hij stelt een entiteit voor, en ik kan daarmee wat doen.
Om die entiteit te persisten of op te halen, heb ik een aantal DAO's als je 't zo wil noemen. Eén voor elke tabel (dat dan weer wel). Om die entiteit op te slaan of op te halen, zal ik dus meerdere DAO's nodig hebben.

/verder volledig eens met mOrphie.

Dus in feite zijn bij jou de DTO's niet representatief voor een tabel in de database maar puur een entiteit die binnen de software een betekenis heeft en die je uiteindelijk gebruikt om de view van data te voorzien? En hoe combineer je dan de data uit de verschillende DAO's in één DTO? Op welke plaats gebeurt dat?

[mOrPhie]

Verwijderd schreef op maandag 28 juli 2008 @ 11:17:
[...]

Maar hoe verhoudt het business model zich dan tot de view? Want in principe vraagt de view om een bepaalde dataset die in deze opzet dus wordt geconstrueerd door het business model. Met andere woorden: het business model is afhankelijk van de view zoals die op dat moment is opgezet.

Mjah, het business model of (de meer gebruikte term) "domain model" hoeft niet altijd tot code te leiden. In UML zijn daar wat tools voor om te bepalen welke business entiteit een DTO wordt. Het is moeilijk te zeggen dat daar altijd 1 techniek wordt gebruikt.

In het geval dat je met Web Services werkt bijvoorbeeld, dan is het verstandig om altijd "zo weinig mogelijk" over de lijn te sturen en zijn de view en het (soap) object vaak 1 op 1 aan elkaar. In een statefull omgeving is dat wellicht niet nodig en is het maken van objecten die 1 op 1 verhouden tot de view wellicht wat overhead en laat je dat zitten. De afweging is per scenario weer anders.

[...]

Dat ben ik met je eens. Het gaat natuurlijk veel te ver om standaarden te ontwikkelen voor iets dat erg dynamisch is en afhankelijk van allerlei omstandigheden. Maar ik probeer wel altijd een logisch consistente architectuur te ontwerpen waarbinnen ik waar geschikt design patterns toepas. Ik ben er dan altijd wat onzeker over of ik het dan wel op de juiste manier doe.

Ijkpunt voor dit soort dingen is nog altijd: Is de gedachte erachter goed. Kun je uitleggen waarom je ervoor gekozen hebt? Als het antwoord is "omdat het zuiverder is", moet je jezelf gaan afvragen waarom het zuiverder is en wat de daadwerkelijk winst is. Daarom vind ik het zelf altijd verstandig om een design met collega's te bespreken. Zo kun jij een uitleg hebben aan iets, welke misschien wel voorbij gaat aan een ander belangrijk punt, waar je geen rekening mee had gehouden, maar waar die collega je op wees. Zegt een collega echter: "dit vind ik niet zuiver", dan zou ik vragen: "waarom?". Als hij dan zegt dat het niet de standaard is, dan denk ik dat ik niet snel overtuigd zal zijn.

Verwijderd schreef op maandag 28 juli 2008 @ 11:29:
[...]
En hoe combineer je dan de data uit de verschillende DAO's in één DTO? Op welke plaats gebeurt dat?

Je kunt 2 dingen doen:

• De DTO extra read-only attributen geven en de DAO erop aanpassen dat bij het loaden die attributen ook geladen worden. Dit doe je niet in code, maar in SQL met een join waarschijnlijk.
• Je maakt een nieuwe DTO/DAO combinatie, speciaal alleen voor het laden (en dus niet update of delete) voor deze specifieke situatie. Deze optie is wellicht wat over the top en minder vriendelijk voor onderhoud. Het is wel zuiverder, als je dat zo zou willen noemen.

Maar er zijn nog meer opties. Zie ook de optie die whoami aandraagt hierin.

[Verwijderd]

Hmmm, dat je begint over een JOIN in je SQL statement, brengt mij op het volgende punt. Wanneer je de toegang tot je database afhandelt via DAO's en DTO's die een één op één relatie hebben met een tabel uit de database, dan krijg je inderdaad de situatie dat je koppelingen met code moet realiseren. Neem bijvoorbeeld de relatie tussen Artikel en Categorie:

Tabel Artikel
id (primaire sleutel)
titel
bericht
datum
categorie_id

Tabel Categorie
id (primaire sleutel
naam

Stel nu dat ik een overzicht wil weergeven van alle artikelen met daarbij de naam van de categorie, dan kan ik dat met een eenvoudige JOIN met SQL uitvoeren:

code:

SELECT Artikel.id, Artikel.titel, Artikel.bericht, Artikel.datum, Categorie.naam
FROM Artikel
INNER JOIN Categorie
ON Artikel.categorie_id = Categorie.id

Met één query kan ik dus de data uit de database halen voor de weergave van het overzicht. Maar dan moet ik wel een DAO schrijven die deze query uitvoert en dat betekent een DAO die niet beperkt is tot één databasetabel.

In dat geval gaat mijn voorkeur uit naar een opstelling waarmee je data kunt verkrijgen doormiddel van JOINs in plaats van dat je met behulp van de code diverse informatie apart uit de database moet trekken om het vervolgens samen te voegen tot één pakketje.

[mOrPhie]

Ik weet zeker dat er voor beide opties voors en tegens zijn, maar als jij geen andere problemen of afhankelijkheden ziet met die aanpak, dan is er niets mis mee om een DAO een join te laten doen.

[Confusion]

Verwijderd schreef op maandag 28 juli 2008 @ 14:19:
Maar dan moet ik wel een DAO schrijven die deze query uitvoert en dat betekent een DAO die niet beperkt is tot één databasetabel.

Zolang dat maar duidelijk is, is dat geen probleem. Je moet complexe queries niet in een Dao wringen waar ze niet horen en daar een aparte klasse met een fatsoenlijke naam voor maken. In dit voorbeeld zou je echter nog prima voor de ArtikelDao kunnen kiezen en de call getArticlesByCategory() ofzo noemen.

[whoami]

Verwijderd schreef op maandag 28 juli 2008 @ 11:29:
[...]

Uiteindelijk maak je hiermee het punt waar het om gaat. Je kunt een stuk software slecht in elkaar zetten (door gebrek aan kennis, gemakzucht, tijdsdruk of whatever), je kunt een stuk software goed in elkaar zetten (het is logisch opgezet, is onderhoudbaar, is te begrijpen enzovoort) en je kunt een stuk software zien alsof het zich moet kunnen meten aan de heilige graal en er nachten van wakker liggen hoe je het zo elegant mogelijk kunt opzetten. Ik ben zelf vrij perfectionistisch en ben altijd op zoek naar de meest perfecte oplossingen. En als ik er dan één gevonden denk te hebben en toepas, dan ga ik twijfelen en voel me er niet zo goed meer bij. Dat is misschien iets om toch eens aan te werken.

Ik ben ook vrij perfectionistisch & puristisch als het op die dingen aankomt, maar soms moet je gewoon eens kunnen 'tegemoetkomingen' doen (ik kan nu niet op het goede woord komen - 't is warm hier) en het wat pragmatischer aanpakken. Het zal dan iets minder 'puur' zijn, maar beter onderhoudbaar, en ook beter werkbaar. (Trust me, ik worstel er ook soms mee ).

JOIN's binnen een DAO moeten kunnen; zolang je die DAO voornamelijk gebruikt om gegevens te benaderen uit die ene tabel, en als je hier en daar dan eens een andere tabel moet joinen met die ene tabel ... so what.
Voor complexere queries , of queries die niet meteen die 'ene tabel' als 'main datasource' hebben (pfff, ben niet goed bezig), kan je altijd nog een aparte service class oid maken

[ Voor 14% gewijzigd door whoami op 28-07-2008 15:42 ]

[Verwijderd]

whoami schreef op maandag 28 juli 2008 @ 15:40:
[...]
Ik ben ook vrij perfectionistisch & puristisch als het op die dingen aankomt, maar soms moet je gewoon eens kunnen 'tegemoetkomingen' doen (ik kan nu niet op het goede woord komen - 't is warm hier) en het wat pragmatischer aanpakken. Het zal dan iets minder 'puur' zijn, maar beter onderhoudbaar, en ook beter werkbaar. (Trust me, ik worstel er ook soms mee ).

JOIN's binnen een DAO moeten kunnen; zolang je die DAO voornamelijk gebruikt om gegevens te benaderen uit die ene tabel, en als je hier en daar dan eens een andere tabel moet joinen met die ene tabel ... so what.
Voor complexere queries , of queries die niet meteen die 'ene tabel' als 'main datasource' hebben (pfff, ben niet goed bezig), kan je altijd nog een aparte service class oid maken

Ik wil mij hier bij aansluiten.

Als ik puur zou kijken naar artikel en categorie, maak ik twee dao's en twee objecten:
- ArtikelDAO, CategorieDAO
- Artikel, Categorie

Bij het maken van artikel zorg ik altijd dat deze beschikt over een categoryId en een property Categorie heeft, die standaard null is. Met behulp van deze twee properties pas ik een soort van lazy loading toe:

C#:

public Categorie Categorie
        {
            get
            {
                if (this._categorie== null)
                {
                    this._categorie = CatagorieManager.GetItem(this._categorieId);
                }
                return _categorie;
            }
        }

[Face_-_LeSS]

Wat ook een mogelijkheid is om voor elke "complexe" view een DTO te maken. Of één algemene DTO welke dynamische properties bevat (Dictionary<string, object> of een DataTable).

Voor alle complexe views kan je dan één apart DAO maken. Of omdat deze complexe views vaak betrekking hebben tot hoofd entiteit kan je deze DAO methoden ook in de desbetreffende entiteit DAO klasse zetten. dus:

DTO

C#:

// View specifiek
public class ArticleAndCategoryAndReactionsViewDTO
{
  public string Article;
  public string Category;
  public int Reactions;
}

// Dynamisch
public class DynamicDTO
{
  private Dictionary<string, object> _values = new Dictionary<string, object>();
  
  public object GetValue(string name)
  {
    return _values[name];
  }
}

DAO

C#:

public class ComplexViewsDAO
{
  public DynamicDTO[] GetArticlesWithCategoryAndReactions();

  //of

  public ArticleAndCategoryAndReactionsViewDTO[] GetArticlesWithCategoryAndReactions();
}

// Of

public class ArticleDAO
{
  public DynamicDTO[] GetArticlesWithCategoryAndReactions();

  //of

  public ArticleAndCategoryAndReactionsViewDTO[] GetArticlesWithCategoryAndReactions();
}

Zo kan het joinen dus op database niveau en kost het je maar een query.

[Verwijderd]

Face_-_LeSS schreef op donderdag 09 oktober 2008 @ 15:20:
Wat ook een mogelijkheid is om voor elke "complexe" view een DTO te maken. Of één algemene DTO welke dynamische properties bevat (Dictionary<string, object> of een DataTable).

Voor alle complexe views kan je dan één apart DAO maken. Of omdat deze complexe views vaak betrekking hebben tot hoofd entiteit kan je deze DAO methoden ook in de desbetreffende entiteit DAO klasse zetten. dus:

DTO

C#:

// View specifiek
public class ArticleAndCategoryAndReactionsViewDTO
{
  public string Article;
  public string Category;
  public int Reactions;
}

// Dynamisch
public class DynamicDTO
{
  private Dictionary<string, object> _values = new Dictionary<string, object>();
  
  public object GetValue(string name)
  {
    return _values[name];
  }
}

DAO

C#:

public class ComplexViewsDAO
{
  public DynamicDTO[] GetArticlesWithCategoryAndReactions();

  //of

  public ArticleAndCategoryAndReactionsViewDTO[] GetArticlesWithCategoryAndReactions();
}

// Of

public class ArticleDAO
{
  public DynamicDTO[] GetArticlesWithCategoryAndReactions();

  //of

  public ArticleAndCategoryAndReactionsViewDTO[] GetArticlesWithCategoryAndReactions();
}

Zo kan het joinen dus op database niveau en kost het je maar een query.

Ideaal! Ik loop zojuist tegen een zelfde soort probleem op. Ga gelijk kijken of ik het op deze manier inderdaad op kan lossen.

[Face_-_LeSS]

Dit soort constructies wijken wel af van de "recht toe, recht aan" entity CRUD methoden dus wel goed beschrijven hè

[Verwijderd]

Face_-_LeSS schreef op maandag 20 oktober 2008 @ 13:33:
Dit soort constructies wijken wel af van de "recht toe, recht aan" entity CRUD methoden dus wel goed beschrijven hè

Toch op een iets andere manier aangepakt. Ik heb tussen mijn objecten en dataaccesobjecten ook een logica-laag.

In dit geval had ik te maken met een object 'Werknemer' die een collectie heeft van 'Extrarecht' objecten. Ik heb in WerknemerManager (logica-laag) een nieuwe functie gemaakt. Deze functie haalt via 'WerknemerDAO' werknemers en via ExtrarechtDAO extrarechten op. Vervolgens wordt in iedere werknemer de propertie 'extrarechten' gevuld op basis van de twee lijsten die zijn opgehaald.

Normaal is de propertie 'extrarechten' leeg, totdat deze wordt geraadpleegd. Alleen door middel van deze funtie wordt de propertie wel gevuld.

zo blijven de CRUD-methodes dus ook echt CRUD-methodes.

Toch nog niet helemaal happy mee, maar voorlopig werkt het prima. In plaats van voor iedere werknemer een nieuwe query te draaien, kan ik het nu met twee querys af.