C# oggetti business e raccolte

Question

Ho difficoltà a comprendere gli oggetti di business o, in particolare, le raccolte di oggetti business.

Ecco un rapido esempio di ciò che sto cercando di fare.

Se si dispone di un oggetto incidente, questo oggetto può avere un numero di persone coinvolto e ciascuno di questi oggetti Persona può avere più note. Le note non possono esistere senza un oggetto Person e gli oggetti Person non possono esistere senza un oggetto Incident.

Se si dispone di Elenco pubblico < Nota> note = nuova lista < Nota>(), quindi metodi come ADD e REMOVE diventano disponibili per Persona all'interno di Incidente. Suppongo che se dovessi chiamare quei metodi nella raccolta di Notes, lo rimuoverò semplicemente dall'Elenco ma non eseguirà alcun codice per aggiungere/aggiornare/eliminare effettivamente il dipendente dall'origine dati. Questo mi porta a credere che non dovrei usare List ma qualcos'altro?

Questo mi porta anche a un'altra domanda. Dove dovrebbero risiedere le effettive operazioni di database CRUD. Un oggetto Note dovrebbe avere il proprio CRUD o l'oggetto Person dovrebbe esserne responsabile perché non può esistere senza di esso?

Sono un po 'perso su quale strada andare e mi piacerebbe ottenere questa parte giusta perché sarà il modello per il resto del programma.

Answer 1

alcune informazioni di grande è stata data, ma una cosa che lei ha detto che potrebbe si essere fonte di confusione è questo:

"Se ho Elenco pubblico osserva = new Lista() quindi metodi come ADD, RIMUOVERE diventa disponibile a Persona all'interno di Incidente. "

Tutto dipende da come si progettano le classi. Una cosa che dovresti pensare è il modo in cui questi dati si correlano tra loro. Questo ti aiuterà a immaginare il tuo design di classe.

suona come il seguente:

• Un incidente può coinvolgere molte persone
• Una persona in grado di creare molte note
• Una nota è il livello più basso ed esiste a causa di un incidente in fase di creazione e di una responsabile (i) che lavora su quell'incidente.

Incidente 1 - molte persone

Persona 1 - molte note

Si può fare questo tipo di rapporto in un certo numero di modi. Un modo potrebbe essere quello di separare effettivamente gli oggetti coinvolti e quindi creare oggetti uniti.

Per esempio

public class Incident { 
//insert incident fields here 
//do not add person logic/notes logic 
//probably contains only properties 
} 

public class Person { 
//insert person fields 
//private members with public properties 
//do not embed any other logic 
} 

public class Comment { 
//insert comment private fields 
//add public properties 
//follow the law of demeter 
} 

Queste classi non danno informazioni tra loro, sono solo repository per memorizzare queste informazioni. È quindi in relazione queste classi gli uni agli altri, per esempio

public class IncidentPersonnel { 
List<Person> p; 
//add methods to add a person to an incident 
//add methods to remove a person from an incident 
.... 
} 

allora si può avere un'altra classe gestire la commentando da personale

public class PersonnelNotes { 
List<Note> n; 
//other methods... 
} 

Si può andare avanti con questo, ma potrebbe complicare le cose, ma io sono solo dandoti un'altra idea su come gestirlo.

cercare di seguire the law of demeter for functions

Includete tutte le oggetti, in aggiunta, il vostro vicino può parlare con te, ma non molto altro ... Questo vi aiuterà a tenere le classi loosely coupled e rende il processo di pensiero un po 'più semplice per te.

Infine, hai menzionato come le operazioni CRUD dovrebbero funzionare. Tutto torna al tuo DAL (Livello di accesso ai dati). Piuttosto, quindi, restituisci le righe di dati da una tabella, quindi puoi restituire un oggetto di riferimento con tutti i suoi attributi. Le funzioni di aggiunta e rimozione funzionano allo stesso modo (passando dentro o fuori un oggetto). È possibile utilizzare un ORM o scrivere il proprio DAL. Tutto dipende da quanto vuoi coinvolgere te stesso :).

Answer 2

Hai diverse domande in uno qui, proverò a rispondere di più.

Per quanto riguarda i problemi con l'uso di List<T> - il framework ha un ReadOnlyCollection<T> che è utile esattamente nella vostra situazione. Questa è una raccolta che non consente l'aggiunta o la rimozione una volta creata.

Per quanto riguarda la responsabilità di funzionamento CRUD, questo dovrebbe appartenere al livello dati, non a nessuno dei propri oggetti (vedere SRP - Principio di responsabilità singola).

Answer 3

Il modo in cui lo faccio è: ogni oggetto che ha oggetti figli contiene un elenco di essi e ogni oggetto con un genitore contiene una proprietà con il suo tipo. L'aggiunta viene eseguita popolando un oggetto (o una gerarchia di oggetti) e inviandolo al DAL per la persistenza, se desiderato. Le operazioni CRUD sono tutte nel DAL, che è agnostico dei tipi di oggetto ma utilizza tali tipi per determinare a quali tabelle, colonne, ecc. Accedervi. L'eliminazione è l'unica cosa gestita in modo diverso impostando la proprietà Deleted di un oggetto che attiva il DAL per rimuoverlo.

Ora per quanto riguarda la logica di business - lo fa non risiedono con gli oggetti stessi (i DAO), ma piuttosto si è fatto da classi che ricevono o si riuniscono tali DAO quando necessario, svolgono il loro lavoro e inviare il DAO indietro al DAL per gli aggiornamenti.