DAO objects in je Domain objecten gebruiken

[Standeman]

Ik zit een beetje te piekeren over het gebruik van DAO objecten in een Domain Object. Dit kan heel handing en pragmatisch zijn, maar ik krijg er een beetje vreemd gevoel bij.

even een voorbeeldje:

Java:

public class company {
  private int id;
  private String name;

  public Set getEmployees() {
    EmployeeDAO dao = DAOFactory.getEmployeeDAOImpl();
    return dao.getEmployees(this.id);
  }
}

Op deze manier bewerkstellig je het "lazy fetching" idee, de data wordt pas opgehaald wanneer je dat wilt. Echter, om nog onduidelijke redenen vind ik niet dat DAO's aangesproken moeten worden in je Domain Objecten..

Ik zat dus na te denken over argumenten waarom je dit niet moet doen.. echter kan ik er zo 1..2..3 geen bedenken. Zit mijn "gevoel" er nu naast of toch niet?

[JKVA]

Ik vind het persoonlijk altijd erg fijn om domeinobjecten ook als VO en als DTO te gebruiken, tenminste die rol te laten vervullen. Bovendien is het niet gemakkelijk te unit testen als je je DB code in je domeinlaag laat komen. Dat is ook een van de redenen dat Hibernate transparant is.

Over jouw voorbeeld. Ik begrijp dat je je code versimpeld hebt voor het voorbeeld, maar om in een getter een DAO aan te spreken... Lijkt me niet de goede plaats. Als ik deze methode zou aanroepen, zou ik verwachten een member te zien te krijgen, niet iets dat ter plekke uit de database geslobberd wordt. In mijn getters staat meestal alleen een return en hooguit een lazy instantiatie, om nullwaarden te voorkomen.

Je hebt gelijk dat je een soort lazy fetching krijgt, maar wat is het waard? Want je krijgt tegelijk ook een "heel vaak" fetching, omdat het bij elke aanroep gebeurt.

---

"Expliciete code" was de term die ik zocht. Als je je domeinlaag dergelijke dingen laat doen, doe dit dan via een static getById o.i.d. Op die manier heb je een duidelijkere interface, zonder gekke bijeffecten als je deze aanroept.

[ Voor 13% gewijzigd door JKVA op 06-07-2006 18:14 ]

[Alarmnummer]

Ik heb op dit moment niet veel tijd, maar check de repository eens in ddd. Een repository geeft je een soortement van collection achtige access tot je data en dat is ook precies hetgeen een dao ook doet. Mijn mening op dit moment is dat het gewoon mogelijk moet zijn om je dao's direct aan te spreken in je domain model.

[whoami]

De repository in DDD maakt idd deel uit van je domain layer, en, spreek je dus gewoon vrij aan in je model.
Zelf ben ik ook niet zo'n fan om je DAO's in je domain objecten te steken, om dezelfde redenen die al aangehaald zijn, en ook omwille van de duidelijkheid. Ik denk dat het dan nl. niet altijd even duidelijk is voor de 'gebruiker' van je domein objecten wat er nu precies gebeurd (DB access of niet ?).

[Standeman]

JKVA schreef op donderdag 06 juli 2006 @ 18:13:
Ik vind het persoonlijk altijd erg fijn om domeinobjecten ook als VO en als DTO te gebruiken, tenminste die rol te laten vervullen. Bovendien is het niet gemakkelijk te unit testen als je je DB code in je domeinlaag laat komen. Dat is ook een van de redenen dat Hibernate transparant is.

Ben ik het wel mee eens. Ik kan niet aan de indruk ontkomen dat je een hoop dubbelwerk doet wanneer je aparte DTO's gaat bouwen.
Maar wat is een VO eigenlijk

Over jouw voorbeeld. Ik begrijp dat je je code versimpeld hebt voor het voorbeeld, maar om in een getter een DAO aan te spreken... Lijkt me niet de goede plaats. Als ik deze methode zou aanroepen, zou ik verwachten een member te zien te krijgen, niet iets dat ter plekke uit de database geslobberd wordt. In mijn getters staat meestal alleen een return en hooguit een lazy instantiatie, om nullwaarden te voorkomen.

Hoe zou jij dan de methode in je domain object noemen welke de employees uit de DB slobbert en retourneert in een Set. loadEmployees(), retreiveEmployees()? In mijn ogen is het maar een beestje dat een naampje moet hebben... (hoewel het wel duidelijk moet zijn wat het doet...)

Je hebt gelijk dat je een soort lazy fetching krijgt, maar wat is het waard? Want je krijgt tegelijk ook een "heel vaak" fetching, omdat het bij elke aanroep gebeurt.

Daar heb je wel weer gelijk in. Hoe vaak gaat (in mijn geval) getEmployees() aangeroepen worden. Moet er een vorm van caching in komen (alleen bij de 1ste call naar de DB en verder alleen de wijzigingen persisten?) .

---

"Expliciete code" was de term die ik zocht. Als je je domeinlaag dergelijke dingen laat doen, doe dit dan via een static getById o.i.d. Op die manier heb je een duidelijkere interface, zonder gekke bijeffecten als je deze aanroept.

Je bedoelt static Set getEmployee(int id) ofzo?

Alarmnummer schreef op donderdag 06 juli 2006 @ 18:43:
Ik heb op dit moment niet veel tijd, maar check de repository eens in ddd. Een repository geeft je een soortement van collection achtige access tot je data en dat is ook precies hetgeen een dao ook doet. Mijn mening op dit moment is dat het gewoon mogelijk moet zijn om je dao's direct aan te spreken in je domain model.

Ga ik zeker doen. Ik ben op deze vraag terecht gekomen omdat ik in het verleden nogal vaak trok naar het Anemic Domain Model (zoals in jouw topic wordt aangestipt). Dus ben ik begonnen om mijn leven te beteren qua ontwerp.

whoami schreef op donderdag 06 juli 2006 @ 21:02:
De repository in DDD maakt idd deel uit van je domain layer, en, spreek je dus gewoon vrij aan in je model.
Zelf ben ik ook niet zo'n fan om je DAO's in je domain objecten te steken, om dezelfde redenen die al aangehaald zijn, en ook omwille van de duidelijkheid. Ik denk dat het dan nl. niet altijd even duidelijk is voor de 'gebruiker' van je domein objecten wat er nu precies gebeurd (DB access of niet ?).

Gelukkig ben ik zelf (en een paar collega's) de gebruiker van de domain objecten. Hoewel dat natuurlijk geen excuus is om een ondoorzichtig en verwarrend domain model op te leveren

[JKVA]

Standeman schreef op vrijdag 07 juli 2006 @ 09:22:
[...]
Maar wat is een VO eigenlijk
[...]

Dat is een afkorting die ik voor ValueObject gebruik, dus een weer te geven object met alleen properties die je voor die context nodig hebt. Ik weet niet of het officieel is.

[JKVA]

Bij dezen een antwoord op de andere opmerkingen, ik keek er in eerste instantie overheen.

Standeman schreef op vrijdag 07 juli 2006 @ 09:22:
[...]
Ben ik het wel mee eens. Ik kan niet aan de indruk ontkomen dat je een hoop dubbelwerk doet wanneer je aparte DTO's gaat bouwen.
Maar wat is een VO eigenlijk

Zie vorige post.

Hoe zou jij dan de methode in je domain object noemen welke de employees uit de DB slobbert en retourneert in een Set. loadEmployees(), retreiveEmployees()? In mijn ogen is het maar een beestje dat een naampje moet hebben... (hoewel het wel duidelijk moet zijn wat het doet...)

Ehm, ik zou het iig geen get*** noemen, aangezien die in de JavaBean conventie ook worden gebruikt en meestal erop duiden dat je een property uitleest. Dat is tenminste het eerste waar ik aan denk als ik get*** zie. Ik zou het een static maken of een methode in een of andere managerklasse.

Daar heb je wel weer gelijk in. Hoe vaak gaat (in mijn geval) getEmployees() aangeroepen worden. Moet er een vorm van caching in komen (alleen bij de 1ste call naar de DB en verder alleen de wijzigingen persisten?) .

Je kunt idd lazy loading gebruiken, maar dan krijg je waarschijnlijk n+1 selects. Ik zou voor de Managerklasse gaan.

Je bedoelt static Set getEmployee(int id) ofzo?

Jup