[Alg] Dao/dto package conventies

[Verwijderd]

Bij het opzetten van een nieuw systeem zit ik vaak te kijken naar de indeling van de verantwoordelijkheden over packages. Naarmate ik meer ervaring heb gekregen met development wordt ik daar steeds beter in, maar 1 aspect in het bijzonder heb ik nog vaak twijfels over.

In welke package zet ik al mijn DAO en DTO (models/entities) classes?

Een mogelijkheid is om alles op business concepten te groupen. Stel voor ik heb de concepten "Customer" en "Order". De ene variant is om dit dan als volgt in packages te zetten:

code:

com.mycompany.myapp
   customers
      CustomerDAO.java
      CustomerJpaDAO.java
      CustomerJdbcDAO.java
      Customer.java
   orders
      OrderDAO.java
      OrderJpaDAO.java
      OrderJdbcDAO.java
      Order.java

Een andere indeling is om juist de opsplitsing te maken op basis van abstracte concepten, b.v. "model" en "dao":

code:

com.mycompany.myapp
   models
      Customer.java
      Order.java
   persistence
      CustomerDAO.java
      CustomerJpaDAO.java
      CustomerJdbcDAO.java
      OrderDAO.java
      OrderJpaDAO.java
      OrderJdbcDAO.java

Ik vraag me af wat de meest gebruikte methode is. Er valt voor allebei de aanpakken wel wat te zeggen eigenlijk, maar welke is nou de meeste geaccepteerde?

[JKVA]

De eerste is wel mooi, maar zou ik alleen toepassen als je de onderverdeling coarse grained genoeg kunt maken, bijvoorbeeld: Klanten, contracten, hypotheken, etc. met daarin een flinke hoeveelheid klassen. Daarbinnen zou ik dan altijd nog de onderverdeling dao, service, dto, domain, etc. maken. Maar nogmaals, alleen als je genoeg klassen in een package kunt krijgen. Dit zul je waarschijnlijk alleen tegenkomen bij het opzetten van bijv. een SOA bij een wat grotere instelling, omdat daar je focus op het domein ligt.

Voor een eenvoudigere (web)applicatie zou ik het bij technische concepten houden. Waarschijnlijk kun je al je DAO's in 1 package kwijt. Hetzelfde geldt voor DTO's, domeinobjecten, etc.

De eerste aanpak leidt namelijk tot "silo's" en kan nuttig zijn bij componenten met een zeer lange levensduur waarvan bovendien geldt dat ze intern een grote cohesie/releasecycle hebben. Vandaar mij opmerking over grotere organisaties/SOA. Bij een kleinere of standalone applicatie zul je niet snel tegen de situatie aanlopen dat de eerste aanpak voordelen heeft. Eerder nadelen verwacht ik.

[Verwijderd]

Het een hoeft het ander niet uit te sluiten en ik zou dat dus ook zeker niet doen. Bijvoorbeeld: com.mycompany.myapp.models.customers.

Ook denk ik niet dat de omvang van een project bepalend zou moeten zijn voor de package naamgeving. Specifiekere package structruren geven bijvoorbeeld wel weer beter rare import constructies weer, dus in zekere zin is overdrijven een voordeel

[Verwijderd]

In het verleden heb ik beiden aanpakken wel gebruikt of gezien. Soms omdat het zo groeide, soms omdat er al een bestaande structuur was waarin de een of de andere methode gebruikt werd.

Ik neig nu zelf ook meer naar de 2de methode. Behalve nieuwe applicaties zit ik met 1 grotere applicatie (+-200.000 regels) waar het momenteel allemaal een beetje door elkaar staat. Hoewel ik nog meer in kaart moet brengen, tel ik nu al minstens zo'n 20 domain entiteiten (models/entitities) die dus in een models package zouden komen, met een andere package persistence waar dan de DAO classes in komen.

Dit lijkt zo een voor de hand liggend probleem, maar ik kan eigenlijk weinig literatuur vinden waarin dit een beetje voorgeschreven staat.

[Verwijderd]

Er is niks mis met wat refactor werk als blijkt dat een andere structuur later beter werkt. Ik zou er dan ook niet al te lang bij stil staan want alles wat je nu bedenkt blijkt later toch vaak niet 100% te passen.

[Verwijderd]

Verwijderd schreef op vrijdag 02 mei 2008 @ 15:21:
Er is niks mis met wat refactor werk als blijkt dat een andere structuur later beter werkt. Ik zou er dan ook niet al te lang bij stil staan want alles wat je nu bedenkt blijkt later toch vaak niet 100% te passen.

Je hebt gelijk. Punt is dat ik nu wel met refactoren bezig ben, dus op dit moment voor de beslissing sta

[Apache]

Het tweede sluit wat mij betreft beter aan bij het opsplitsen in functionele lagen, bij de eerste krijg je alle verschillende functionaliteiten bij elkaar, domain classes, dao's, services evt enz ...

Maar beperk je niet tot één subfolder in zoiets, package model kan je nog gerust daaronder package customer hebben die dan evt adres info bevat die enkel gebruikt word bij customers.

In de dao package word er vaak de CustomerDAO interface gezet en dan een submap jpa (of impl) met de CustomerDaoJpaImpl.

[Verwijderd]

Apache schreef op zondag 18 mei 2008 @ 10:35:
In de dao package word er vaak de CustomerDAO interface gezet en dan een submap jpa (of impl) met de CustomerDaoJpaImpl.

'Impl' vind ik een hele matige toevoeging aan een class naam. Dat betekent doorgaans dat het maken van een interface compleet overbodig is geweest. Immers, als de enige toevoeging die je voor de class naam kan verzinnen 'Impl' is dan is het zeer onwaarschijnlijk dat er andere implementaties zijn of gaan komen.

De toevoeging Jpa geeft al duidelijk aan dat het om een implementatie gaat, namelijk diegene die op Jpa is gebasseerd. Mijn persoonlijke voorkeur is overigens dan om voor 'JpaCustomerDao' te gaan, maar dat is aan geen enkele onderbouwing onderhevig.

[Apache]

Persoonlijk ben ik fan van een ICustomerDAO en een CustomerJpaDAO of zelfs gewoon CustomerDAO, maar dat zijn conventies die ik bitter weinig tegenkom in andere projecten.

[Janoz]

Die ICustomerDAO heb ik persoonlijk een hekel aan. Een laatste adem van de eigenlijk al lang dode hungarian notation. Dat CustomerDAO een interface is is helemaal niet relevant voor de classes die hem gebruiken. Het is alleen relevant voor de classes die hem implementeren, en daar wordt het al aangegeven middels 'implements'.

@mark: In de praktijk wordt een interface niet enkel gebruikt wanneer er meerdere implementaties mogelijk zijn, maar ook voor het er tussen hangen van een proxy. Een interface met maar één implementatie is dus niet zo nutteloos als jij nu doet voorkomen

[Verwijderd]

Janoz schreef op maandag 19 mei 2008 @ 09:17:
@mark: In de praktijk wordt een interface niet enkel gebruikt wanneer er meerdere implementaties mogelijk zijn, maar ook voor het er tussen hangen van een proxy. Een interface met maar één implementatie is dus niet zo nutteloos als jij nu doet voorkomen

Weet ik, maar de uitzondering heeft hoeft niet de regel te zijn. En dat vind ik het algemeen geldende 'probleem' in de ict. Een beetje houvast wordt te vaak teniet gedaan door de uitzondering.

Overigens in het geval dat je zelf de proxies schrijft heb je duidelijk wel weer iets te melden bij de verschillende implementaties van de interface. Uiteraard is de uitzondering wanneer je een framework/product gebruikt dat je proxies genereert. Maar goed, uitzonderingen....

[JKVA]

Janoz schreef op maandag 19 mei 2008 @ 09:17:
Die ICustomerDAO heb ik persoonlijk een hekel aan. Een laatste adem van de eigenlijk al lang dode hungarian notation. Dat CustomerDAO een interface is is helemaal niet relevant voor de classes die hem gebruiken. Het is alleen relevant voor de classes die hem implementeren, en daar wordt het al aangegeven middels 'implements'.

@mark: In de praktijk wordt een interface niet enkel gebruikt wanneer er meerdere implementaties mogelijk zijn, maar ook voor het er tussen hangen van een proxy. Een interface met maar één implementatie is dus niet zo nutteloos als jij nu doet voorkomen

Je hebt voor proxies niet per sé een interface nodig. Je kunt met CGLIB prima proxies op classes zetten. Dat is wat Hibernate doet.

Aan de andere kant ben ik het wel met je eens dat het voor een proxy wel netter is om een interface te gebruiken, al is het maar dat je je exposed methods wat explicieter maakt.