Il repository dovrebbe avere un metodo per ogni specifica operazione di database?

Question

Il repository dovrebbe avere un metodo per ogni specifica operazione di database?

#1 da (2 voti)
#2 da (0 voti)

5

Se si seguono i modelli di servizio e di repository standard, il repository dovrebbe contenere un metodo specifico per ogni operazione di database o utilizzare solo i metodi generali, ad es. aggiornare? Prendi ad esempio il seguente metodo di servizio:

DisableUser(User user) {
    user.enabled = false;
    userRepo.update(user); // General user update method
}

Questo esegue le sue modifiche sul record utente, quindi richiede al repository di aggiornare il database chiamando il metodo di aggiornamento generale dell'utente.

O dovrebbe essere più specifico, come:

DisableUser(User user) {
    userRepo.disable(user); // Specific operation, matching the service
}

Ovviamente questo è un esempio molto semplice, ma ritengo che la conclusione influenzi il modo in cui vado avanti con il repository in generale e questa stessa logica si applica a molti scenari.

Ciò che mi confonde ulteriormente è che nel primo caso l'uso del metodo di aggiornamento standard può essere considerato inefficiente, perché può aggiornare ogni colonna del record, ma mi capita di usare Entity Framework in modo che si occupi di controllare cosa i campi sono cambiati e solo l'aggiornamento del campo modificato per me. Ma dovrei fare questa ipotesi dal mio servizio?

Se dovessi scrivere un'implementazione plain sql alternativa dell'ID del repository, devi aggiornare tutti i campi lì, o implementare il rilevamento dei cambiamenti di campo da solo. Quindi quella parte mi spinge verso l'implementazione specifica, ma con ciò sto aggiungendo molti più metodi e forse mi sembra un po 'inutile.

Quindi, in poche parole, se il repository ha solo i metodi standard, aggiorna, inserisci, trovaById, trova Tutto, elimina. O dovrebbe avere un metodo per ogni specifica operazione di database, come le stored procedure.

Ci sono probabilmente molte altre considerazioni che non sto afferrando. Qualsiasi consiglio sarebbe apprezzato.

design-patterns repository patterns-and-practices

posta matthewrk 09.06.2016 - 18:18

fonte

2 risposte

Leggi altre domande sui tag design-patterns repository patterns-and-practices

Perché dovrei usare es6 Set prototype - 'entries' È auspicabile un sistema di event-aware promettente?

score 2 · Answer 1

Per fornire una prospettiva diversa dalla risposta già esistente, direi che dipende .

Quello generico è più riutilizzabile, ma quello specifico del dominio segnala l'intento e separa meglio il tuo modello di dominio dalla scelta della persistenza. Se lo fai

var user = repo.GetUser(id); user.Enabled = false; repo.Update(user);

Quindi il repository non ha una vera idea di cosa stia facendo (che può essere una buona cosa dal punto di vista della riusabilità). Ma hai anche perso la possibilità di ricordare l'intento dell'operazione.

Se ne fai uno specifico per il dominio:

repo.DisableUser(id);

Prima di tutto, forse puoi implementare il tuo repository in modo più efficiente. Potresti non aver bisogno di ottenere che l'utente lo disabiliti, forse puoi semplicemente fare un UPDATE e averne fatto. Inoltre, conosci cosa stai facendo, così puoi scegliere di aggiungere anche un buon messaggio di log in un log di controllo o qualcosa di simile a livello di repository. Mentre è ancora possibile eseguire la registrazione di controllo con la versione più generica, si otterrà una voce generica "customer updated" anziché una specifica "customer disabled" del dominio. Questo in molti casi può essere molto bello e prezioso.

Questo è più lavoro, per cui in generale le persone andranno con la soluzione generica perché è più generica e più facile da implementare. Ma non trascurare il repository specifico del dominio come inutilizzabile o cattivo, la risposta è sempre dipende .

score 0 · Answer 2

Se segui i metodi più generali, aggiorna, inserisci, findById, findAll, delete, il tuo codice sarà probabilmente più riutilizzabile. Con questo intendo che invece di scrivere un metodo specifico per ogni scenario, scoprirai che puoi semplicemente esporre i metodi più generali e usarli per i casi specifici che sono necessari. Ad esempio, potrei aver bisogno di disabilitare un utente, per questo chiamerei il metodo di aggiornamento. In seguito potresti avere altre interfacce che devono disabilitare un utente e puoi chiamare di nuovo lo stesso metodo di aggiornamento invece di scrivere un metodo completamente nuovo per affrontare quel caso specifico. Ho lavorato molto su SOA (Services Oriented Architecture) e posso dire che più è generico mantenere le cose, più facilmente lo troverai per mantenere un buon codice. Alla fine potresti scoprire che la tua organizzazione vuole spostarsi su un bus di servizio per mantenere tutti i vari servizi. Con metodi più generici questa transizione sarà molto più semplice.