Repository Pattern: Aggiungi elemento

Question

Solo bisogno di chiarire questo, se ho l'interfaccia di seguito

public interface IRepository<T> 
{ 
    T Add(T entity); 
} 

nell'attuazione della stessa, non il controllo per la duplicazione se entità è già esistenti prima persistono è ancora un posto di lavoro della Deposito, o dovrebbe gestirne qualcos'altro?

Answer 1

Sì, si consiglia di eseguire questi controlli nel repository.

Risposta lunga: il termine "repository" è un po 'vago, ma è sempre più utilizzato come nome del livello di astrazione di persistenza. Il nome è bello, ma non dice troppo: se prendi ASP.Net MVC come esempio, le app di esempio, come la cena di Neirds e simili, o i progetti di codeplex incapsulano l'accesso ai dati dalla classe del repository. Se tale livello è implementato con un database relazionale per instancce, le chiavi primarie delle tabelle non consentiranno le voci duplicate, il che significa che in questo caso l'implementazione del repository genererà un'eccezione se vengono inserite 2 voci con la stessa chiave. Quindi, in altre parole, un'implementazione di un repository RDBMS sarà sempre dovuta a questo controllo, non sarete in grado di evitarlo. Quindi, per rendere il comportamento dei repostories là fuori nel mondo più simile e per evitare sorprese, consente a tutti loro di fare questo controllo.

È una seconda domanda se è necessario mantenere nella logica aziendale già che il metodo Add() non è associato a una voce già esistente. A volte ha senso risolvere questo solo in un singolo punto, ad esempio il database, a causa di problemi di concorrenza o risparmi sui viaggi di andata e ritorno. D'altra parte è bello, ad esempio, dire all'utente il prima possibile che un nome utente sia già stato preso. Quindi questo dipende.

hanno una bella giornata

Answer 2

Se l'entità esiste già, è possibile generare un'eccezione o aggiornare i campi dell'entità esistente.

Se si sceglie quest'ultima, il metodo dovrebbe probabilmente essere chiamato qualcosa come AddOrUpdate()

LINQ to SQL esempio

Se sto recupero di un singolo record, userò

public Entity GetEntity(int entityID) 
{ 
    return dataContext.Entities.SingleOrDefault(e => e.EntityID = entityID); 
} 

... E nel metodo di chiamata, controllerò per vedere se ciò che viene restituito è nullo prima di tentare di utilizzare l'entità restituita.

Se sto aggiornando un record, farò recuperare l'entità come mostrato, modificare l'entità, e quindi chiamare un metodo repository UpdateEntity(entityID) per aggiornare i campi del database.

Se aggiungo un record, è ancora più semplice. Poiché si tratta di una banca dati, e le mie tabelle contengono sempre un campo di identità di tipo int (un numero di auto-assegnabile, essenzialmente), l'aggiunta di un record è l'operazione più semplice di tutti (è sempre un nuovo record):

Public void InsertEntity(Entity entity) 
{ 
    dataContext.Entities.InsertOnSubmit(entity); 
    dataContext.SubmitChanges(); 
} 

Le regole aziendali (gli indirizzi di posta elettronica sono univoci, ad esempio) possono essere gestiti nel repository o in un livello aziendale separato. Se stai cercando il modo più "corretto", penso che la maggior parte delle persone sarebbe d'accordo sul fatto che le regole di business appartengono al proprio livello di business logic.

Answer 3

In sostanza, la decisione su dove gestire quel caso dipende dalle vostre esigenze.

Se si dispone di regole aziendali che definiscono azioni di taglio preciso per quando ciò accade, ad esempio se esiste un duplicato, il nuovo elemento deve essere rinominato, quindi può essere incorporato nella classe del repository.

D'altra parte, se sono in vigore regole più complesse per cui, ad esempio, sono necessarie ulteriori informazioni per modificare l'elemento prima di aggiungere, quindi dovrebbe essere gestito ulteriormente nella catena alimentare.

Il concetto di repository afferma che esiste per eseguire le attività di persistenza. Quindi se puoi fare tutto nel repository, va bene. Se scopri di iniziare a fare riferimento al di fuori del repository, o il tuo repository ha delle dipendenze, ad esempio chiamando un altro repository, un servizio o un gestore (o qualunque altra nomenclatura di processore tu preferisca), allora è un buon segno tornare indietro di un passo.