Esiste uno schema per le operazioni non CRUD rispetto a un database?

Question

Esiste uno schema per le operazioni non CRUD rispetto a un database?

#1 da (9 voti)
#2 da (3 voti)

3

Nella mia piccola applicazione C #, gestisco le query SQL direttamente dal codice utilizzando ADO.NET di base. Non voglio usare un ORM, come Entity Framework.

Ora, ho un repository per le operazioni CRUD. Ma trovo che ho bisogno di flessibilità per query più complesse.

Ad esempio, ecco il processo (ingenuo e semplificato) di accesso all'applicazione:

L'utente digita una password (nessun nome utente, stile Windows).
A Count SQL-query conta gli utenti con tali credenziali.
Se c'è un utente con tali credenziali, un repository di utenti carica le informazioni dell'utente dal database e recupera un oggetto User .

Ora, dove dovrebbe essere il metodo Count ? Certamente non può essere nel repository, quindi dove dovrebbe essere? Esiste un modello per la gestione di tali operazioni non CRUD rispetto al database?

c# design-patterns

posta Sipo 27.09.2017 - 20:58

fonte

2 risposte

3

In genere ciò è stato fatto tramite:

ExecuteReader - Restituisce 1 o più record di dati = > %codice%
ExecuteScalar - Restituisce un singolo valore = > %codice%
ExecuteNonQuery - Non restituisce nulla = > %codice%

Si può anche avere un valore di ritorno da una procedura memorizzata e anche un riferimento a parametri che possono essere controllati.

Il tuo livello dati dovrebbe supportare queste operazioni. (ADO.Net sì)

risposta data 27.09.2017 - 21:12

fonte

Leggi altre domande sui tag c# design-patterns

Suggerimenti per sviluppare ulteriormente su un sistema legacy? [chiuso] C'è un vantaggio pratico nell'usare il tipo di dati più piccolo possibile?

score 9 · Accepted Answer

It certainly can't be in the repository

Certo che può. Questo potrebbe effettivamente essere il posto migliore per questo. La responsabilità del repository è di fornire un'astrazione per un sottoinsieme del database, che potrebbe essere sostituito da un deposito fittizio a scopo di test. Mettere qualcosa come un metodo Count in un pronti contro termine si adatterà ancora a quel "modello". Nota che se il codice client del repository non ha bisogno di usare direttamente SQL, questo rende il codice client molto più semplice da testare (senza un database).

Naturalmente, se ottieni una dozzina di questi metodi di query, potrebbe diventare necessario suddividere ulteriormente la classe di pronti contro termine in classi separate, ma come e quando lo fai dipende da te, non c'è un carico cerebrale -programma di progettazione per questo.