Java - 1 DAO gebruiken voor opvullen meerdere tableModels

[Rebbelx]

Mijn vraag
Zelf beschik ik over basiskennis java... ik kamp met volgend probleem / stelling. Ik wil 2 tablemodels opvullen met databank data via hibernate. In de eerste tablemodel moeten klantgegevens weergegeven worden, in het 2de tablemodel komen er artikelgegevens.

Oorspronkelijk had ik 2 DAO classes aangemaakt:
ClientDao
ArticleDao

Echter hebben beide classes de methods create, read, update en delete. De create & delete method was zelfs 2keer dezelfde code in beide classes. Het verschil zat hem in de update en read. Read is vrij logisch, je moet 2 verschillende queries uitvoeren in beide classes, bij update iis de code ook verschillend aangezien er bepaalde tekstvelden moeten gecontroleerd worden welke data precies moet geupdate worden.

Aangezien ik steeds geleerd heb om geen duplicate code te schrijven, dacht ik om van 2 Dao classes naar 1 te gaan, welke kan gebruikt worden voor beide models op te vullen. De method read ziet er zo uit
<code>
@Override
public List<Object> read() {
Query query = null;
List<Object> objList = null;
try {
String CLIENT_QUERY = " from Client";
query = superDao.getSession().createQuery(CLIENT_QUERY);

objList = query.list();
} catch (Exception e) {

return null;
} finally {
superDao.close();
}

return objList;
}

</code>

Zoals jullie waarschijnlijk wel zien werkt dit voor het opvullen van de het clientModel maar hoe maak ik het dat ook de articles kunnen opgehaald worden ? Of....is het gewoon niet aangewezen om op deze manier te werk te gaan en toch 2 DAOs te gebruiken ?

Relevante software en hardware die ik gebruik: Eclipse, MySQL, Hibernate, MacOS
...

Wat ik al gevonden of geprobeerd heb : Staat hierboven beschreven.
...

[ Voor 3% gewijzigd door Rebbelx op 24-05-2018 08:18 ]

[PatrickH]

Ik zou sowieso wel 2 DAO's aanhouden. Wat je zou kunnen doen om duplicate code te vermijden is gebruiken van een abstracte DAO (met daarin code voor beide DAO's) en die dan extenden. Dan tevens gebruik maken van Generics. Dat lijkt mij de beste oplossing.

[Hopscotch]

Een nobel streven om duplicatie te willen voorkomen, tegelijkertijd wil je ook nadenken over de complexiteit van je oplossing. Wat je nu krijgt is dat je return type bijvoorbeeld een lijst van Objecten is geworden in plaats van een lijst van de entities die je wilt waardoor je typesafety verliest.

Je kunt je ook afvragen of elke DAO al deze functies nodig heeft (al kan het geen kwaad ze erin te stoppen).
Ik zou het lekker bij een DAO per entity houden, dat past ook beter het single responsibility principle.

Verder niet de exceptie catchen en null returnen. Als je niks vindt return je een lege lijst en als je daadwerkelijk een exception krijgt wil je dat of op een echt nette manier oplossen of je app gewoon laten klappen en zeker niet overal null checks in moeten bouwen om dit te ondervangen.