Pattern di repository vs entità di gestione DAO

Ci sono due problemi da affrontare - che sono ortogonali tra loro:

1) La parte inferiore della persistenza

Questo è il punto in cui devi gestire Connections , Query , Resultsets e simili. Tipicamente usi l'uno o l'altro framework che ti dà una facciata -pattern a portata di mano, che astrae via le cose sporche in modo da dire solo ciò che vuoi sapere (Resultset from Query) e dove il framework potrebbe trovarlo (query e connessione). Quello che fai con il set di risultati dipende da te.

Quando il tuo paradigma è OOP, c'è un ulteriore passaggio: assemblare il set di risultati agli oggetti. O lo fai manualmente o hai un object-relational-mapper che fa il lavoro per te.

2) L'astrazione all'interno della tua applicazione Al di sopra di questo livello di basso livello si trova l'astrazione con cui si occupa la tua applicazione. C'è DataAccessObject (DAO) -Layer o Repository -Layer. Entrambi generano oggetti con cui la tua applicazione può lavorare.

Quello che stai usando non ha alcun effetto sulla risposta della tua domanda.

La tua domanda è da un lato sulla modellazione ( »Come gestire le relazioni tra gli oggetti« Risposta: via Composizione / Aggregazione ) e su come riempire l'oggetto (e le sue dipendenze) con i dati.

Is it done using Dependency Injection and if so, where is the dependency created?

Questa è la strada da percorrere. Ci sono due modi:

1) Rendi esplicito il DI e definisci un costruttore. Quando crei l'oggetto, puoi creare prima tutte le dipendenze e iniettarle tramite constructor o setter injection

2) Usi un quadro, che fa la magia per te. Spesso la riflessione è coinvolta, cioè ci sono possibilità in alcune lingue di esaminare e manipolare gli oggetti al volo. L'iniezione viene eseguita in modo trasparente per l'utente dal framework.

Questo è indipendente dal modello DAO / Repository.

I am not using an ORM tool and don't want to as I like to explore these basic patterns directly

È un approccio nobile, ma in ogni caso non produttivo. La maggior parte delle volte, vuoi fare delle cose. Per scopi didattici, potresti percorrere questa strada. Ma non lo consiglierei.

Cerca un ORM-Framework flessibile, che ti dà una mano quando è necessario senza forzarti in un modo o nell'altro. Non è in ogni caso efficace la query generata da ootB. Un buon framework consente di utilizzare SQL quando necessario e si occupa solo della parte di assemblaggio .

Questo è il luogo in cui l'ORM (mappatura relazionale dell'oggetto) è utile. Esistono librerie per molti linguaggi di programmazione che forniscono questo tipo di tecniche di programmazione. Per esempio. per Java c'è Hibernate . Hibernate funziona con annotazioni Java. Ecco un semplice esempio per una relazione molti a uno dalla documentazione ufficiale :

@Entity
public class Flight implements Serializable {
    @ManyToOne(cascade={CascadeType.PERSIST, CascadeType.MERGE})
    @JoinColumn(name="COMP_ID")
    public Company getCompany() {
        return company;
    }
    ...
}