Rendiamo indipendenti DAO l'una dall'altra

1

Ho queste due classi (Getter / Setter / Constructor omessi):

public class Company {
    private String name;
    private String adress;
    private List<Employee> employees;
    private Uuid id;
}

public class Employee {
    private String name;
    private int age;
    private Uuid id;
}

Le due entità e la loro relazione sono modellate in un database relazionale utilizzando le tabelle COMPANY , EMPLOYEE e EMPLOYMENT .

Ora voglio scrivere le classi DAO per gestire la persistenza delle due entità e la loro relazione. Il modo semplice sarebbe creare un DAO per ognuno e avere CompanyDao di utilizzare internamente EmployeeDao . Ma secondo alcune risposte Stackoverflow che ho letto, si tratta di un odore del design e dovrebbe essere rifattorizzato in metodi di servizio che utilizzano i DAO senza che questi debbano dipendere l'uno dall'altro.

Questo è il modo in cui implementerei questo metodo di servizio:

public class DBService {
    public DBService(CompanyDao companyDao, EmployeeDao employeeDao,
                     EmploymentDao employmentDao) { ... }

    public Company findCompany(Uuid companyId) {
        Company company = companyDao.find(companyId);
        List<Uuid> employeeIds = employmentDao.findEmployeeIds(company.getId());
        for(Uuid employeeId : employeeIds) {
            company.addEmployee(employeeDao.find(employeeId));
        }
    }
}

Questo è un buon modo per farlo? O il EmployeeDao dovrebbe avere un metodo findByCompany(Uuid companyId) ?

Informazioni: ho già chiesto una domanda di smiliar su Stackoverflow, ma le uniche risposte che ho ricevuto sono state "Utilizzare uno strumento ORM" . So che qualcosa come Hibernate gestirà tutta la perseveranza per me, ma mi piacerebbe sapere come farlo a mano.

    
posta Luca Fülbier 18.06.2016 - 11:51
fonte

2 risposte

1

The easy way would be making a DAO for each one and have the CompanyDao use the EmployeeDao internally.

Poiché non è stato condiviso alcun collegamento a StackOverflow, voglio solo menzionare il motivo dell'odore del codice.

In breve:

Riguardo al codice (l'exmaple di DBService )

Is this a good way to do this?

Finora, il codice è alle porte del noto schema del repository (nonostante il nome effettivo) che è ampiamente adottato dalla comunità. Troverai molti riferimenti al modello alla ricerca di DDD .

Il modello di repository introdotto nel DDD di Eric Evans non ha nulla a che vedere con i dettagli di implementazione, quindi l'implementazione varierà in base ai requisiti e alle esigenze specifiche.

Ciò che non varia è il concetto. Lo scopo.

Quindi, basandomi solo sulle informazioni che fornisci, direi che stai facendo abbastanza bene.

    
risposta data 24.05.2017 - 22:52
fonte
0

Suggerisco un'alta simmetria. Quindi se hai un'entità dovresti avere un DAO. Il DAO dovrebbe servire solo una entità. (principio di minore sorpresa)

Devi anche mantenere le dipendenze brevi in modo che un DAO sia responsabile solo della sua entità e della risoluzione dei vicini diretti. (Legge di demeter)

In una mia architettura uso altri DAO all'interno di DAOS. Ma il comportamento che uso da altri DAO non è "caricamento" o "persistente". Io uso solo i metodi di mappa per creare una nuova rappresentazione per ogni entità per il livello superiore.

A proposito: questo non ha nulla a che fare con l'ibernazione di strumenti ORM. Riducono solo lo sforzo di mappatura e supportano le strategie di caricamento, persistenza e memorizzazione nella cache. Ma tutto questo dovrebbe essere incapsulato nel livello DAO, in modo che i livelli più alti possano astrarre da questi dettagli tecnici.

    
risposta data 23.11.2016 - 21:14
fonte

Leggi altre domande sui tag