Salvataggio di un oggetto tramite un metodo proprio o tramite un'altra classe?

Se voglio salvare e recuperare un oggetto, dovrei creare un'altra classe per gestirlo, o sarebbe meglio farlo nella classe stessa? O forse mescolando entrambi?

Quale è raccomandato secondo il paradigma OOD?

Per esempio

Class Student
{
    public string Name {set; get;}
    ....
    public bool Save()
    {
        SqlConnection con = ...
        // Save the class in the db
    }
    public bool Retrieve()
    {
         // search the db for the student and fill the attributes
    }
    public List<Student> RetrieveAllStudents()
    {
         // this is such a method I have most problem with it 
         // that an object returns an array of objects of its own class!
    }
}

Contro. (So ​​che si consiglia quanto segue, tuttavia mi sembra un po 'contrario alla coesione di Studentclasse)

Class Student { /* */ }
Class DB {
  public bool AddStudent(Student s)
  {

  }
  public Student RetrieveStudent(Criteria)
  {
  } 
  public List<Student> RetrieveAllStudents()
  {
  }
}

Che ne dici di mescolarli?

   Class Student
    {
        public string Name {set; get;}
        ....
        public bool Save()
        {
            /// do some business logic!
            db.AddStudent(this);
        }
        public bool Retrieve()
        {
             // build the criteria 
             db.RetrieveStudent(criteria);
             // fill the attributes
        }
    }

Principio di responsabilità unica , separazione delle preoccupazioni e coesione funzionale . Se leggi questi concetti, la risposta che ottieni è: separali .

Un semplice motivo per separare la Studentclasse "DB" (o StudentRepository, per seguire convenzioni più popolari) è quello di consentire di modificare le "regole aziendali", presenti nella Studentclasse, senza influire sul codice responsabile della persistenza e viceversa. versa.

Questo tipo di separazione è molto importante, non solo tra le regole aziendali e la persistenza, ma tra le molte preoccupazioni del tuo sistema, per permetterti di apportare modifiche con un impatto minimo in moduli non correlati (minimo perché a volte è inevitabile). Aiuta a costruire sistemi più robusti, più facili da mantenere e più affidabili in caso di cambiamenti costanti.

Avendo le regole di business e la persistenza mescolate insieme, o una singola classe come nel tuo primo esempio, o con DBuna dipendenza di Student, stai accoppiando due preoccupazioni molto diverse. Può sembrare che appartengano insieme; sembrano essere coerenti perché usano gli stessi dati. Ma ecco la cosa: la coesione non può essere misurata solo dai dati condivisi tra le procedure, è necessario considerare anche il livello di astrazione in cui esistono. In effetti, il tipo ideale di coesione è descritto come:

La coesione funzionale si verifica quando le parti di un modulo sono raggruppate perché tutte contribuiscono a un singolo compito ben definito del modulo.

E chiaramente, l'esecuzione di convalide per un Studentpo 'anche persistendo non costituisce "un singolo compito ben definito". Di nuovo, le regole aziendali e i meccanismi di persistenza sono due aspetti molto diversi del sistema, che secondo molti principi di una buona progettazione orientata agli oggetti, dovrebbero essere separati.

Consiglio di leggere di Clean Architecture , di guardare questo discorso sul principio di responsabilità singola (dove viene usato un esempio molto simile) e di guardare anche questo discorso su Clean Architecture . Questi concetti delineano le ragioni alla base di tali separazioni.

Entrambi gli approcci violano il principio di responsabilità singola. La tua prima versione assegna alla Studentclasse molte responsabilità e la lega a una specifica tecnologia di accesso al DB. Il secondo conduce a una grande DBclasse che sarà responsabile non solo degli studenti, ma di qualsiasi altro tipo di oggetto dati nel programma. EDIT: il tuo terzo approccio è il peggiore, poiché crea una dipendenza ciclica tra la classe DB e la Studentclasse.

Quindi se non hai intenzione di scrivere un programma giocattolo, non usarne nessuno. Invece, usa una classe diversa come una StudentRepositoryper fornire un'API per il caricamento e il salvataggio, supponendo che tu stia implementando il codice CRUD da solo. Potresti anche considerare di utilizzare un framework ORM , che può fare il duro lavoro per te (e il framework in genere imporrà alcune decisioni in cui devono essere posizionate le operazioni Load and Save).

Esistono alcuni modelli che possono essere utilizzati per la persistenza dei dati. C'è il modello Unità di lavoro , c'è il modello Repository , ci sono alcuni modelli aggiuntivi che possono essere usati come la facciata remota, e così via.

Molti di questi hanno i loro fan e i loro critici. Spesso si tratta di scegliere ciò che sembra più adatto all'applicazione e di attenersi ad esso (con tutti i suoi lati positivi e negativi, cioè non usare entrambi i modelli contemporaneamente ... a meno che tu non ne sia veramente sicuro).

Come nota a margine: nel tuo esempio RetrieveStudent, AddStudent dovrebbe essere metodi statici (perché non dipendono dall'istanza).

Un altro modo di avere metodi di salvataggio / caricamento in classe è:

class Animal{
    public string Name {get; set;}
    public void Save(){...}
    public static Animal Load(string name){....}
    public static string[] GetAllNames(){...} // if you just want to list them
    public static Animal[] GetAllAnimals(){...} // if you actually need to retrieve them all
}

Personalmente utilizzerei questo approccio solo in applicazioni abbastanza piccole, possibilmente strumenti per uso personale o in cui posso prevedere in modo affidabile che non avrò casi d'uso più complicati del semplice salvataggio o caricamento di oggetti.

Anche personalmente, vedi il modello Unità di lavoro. Quando lo conosci, è davvero buono sia in casi piccoli che grandi. Ed è supportato da molti framework / apis, ad esempio EntityFramework o RavenDB.

Se si tratta di un'app molto semplice in cui l'oggetto è più o meno legato al datastore e viceversa (cioè può essere pensato come una proprietà del datastore), allora potrebbe avere senso avere un metodo .save () per quella classe.

Ma penso che sarebbe piuttosto eccezionale.

Piuttosto, di solito è meglio lasciare che la classe gestisca i suoi dati e le sue funzionalità (come un buon cittadino OO) ed esternalizzare il meccanismo di persistenza ad un'altra classe o insieme di classi.

L'altra opzione è quella di utilizzare un framework di persistenza che definisce la persistenza in modo dichiarativo (come con le annotazioni), ma che sta ancora esternando la persistenza.

• Definire un metodo su quella classe che serializza l'oggetto e restituisce una sequenza di byte che è possibile inserire in un database o file o qualsiasi altra cosa
• Avere un costruttore per quell'oggetto che accetta una tale sequenza di byte come input

Per quanto riguarda il RetrieveAllStudents()metodo, il tuo feeling è giusto, probabilmente è fuori luogo, perché potresti avere più liste distinte di studenti. Perché non tenere semplicemente gli elenchi fuori dalla Studentclasse?