Dovrei avere un metodo separato per Update (), Insert (), ecc., o avere una Query generica () che sarebbe in grado di gestirli tutti? [chiuso]

6

Attualmente sto provando a scrivere una libreria di classi per una connessione a un database. Guardandoci sopra, ci sono diversi tipi di query: Seleziona Da, Aggiorna, Inserisci, ecc.

La mia domanda è, qual è la migliore pratica per scrivere queste domande in un'applicazione C #?

Dovrei avere un metodo separato per ognuno di essi (cioè Update (), Insert ()), o avere una Query generica () che sarebbe in grado di gestirli tutti? Grazie per qualsiasi aiuto!

    
posta PiousVenom 04.10.2012 - 18:58
fonte

6 risposte

8

In primo luogo, un po 'del gergo. Inserisci, l'aggiornamento non è una query. Una query in RDBMS è strettamente SELECT (o una sotto-istruzione con clausola WHERE). Il set di verbi: SELECT, INSERT, UPDATE, DELETE sono istruzioni di azione in Data Manipulation Language (DML).

La maggior parte delle risposte finora si riaccendono intorno a come per raggiungere il tuo obiettivo, ma la tua domanda è:

Should I have a separate method for each of them(i.e. Update(), Insert()), or have a generic Query()

La risposta è sì. Ogni metodo dovrebbe eseguire 1 funzione e restituire 1 tipo di risultato. È possibile riutilizzare la logica di connessione o ObjectContext (se si utilizza Entity Framework) in ciascuno.

La maggior parte del codice per la gestione del database in genere visse in un livello o livello separato dalla logica di presentazione.

    
risposta data 04.10.2012 - 19:52
fonte
3

La migliore pratica non è affatto quella di scrivere una tale libertà. Utilizzare un mappatore OR come MS entity framework o uno qualsiasi dei micro-ORM leggeri disponibili (ad esempio, vedere qui link )

    
risposta data 04.10.2012 - 19:14
fonte
2

Come altri hanno suggerito, puoi andare con gli ORM (a meno che tu non ritenga che gli ORM siano un antipattern ). Se per qualsiasi ragione non puoi andare con un ORM esistente, ti consigliamo di cercare alcuni pattern DAO (Data Access Object) per vedere se ciò che si adatta. Un'altra opzione potrebbe essere l'effettivo DML / SQL in una stored procedure e chiamare la procedura per nome. Ciò sarebbe più utile se le tue operazioni sono un po 'più complicate di SELECT / UPDATE / INSERT.

    
risposta data 04.10.2012 - 19:24
fonte
1

(Risposta generica, indipendente dalla lingua)

Spesso nelle classi di astrazione DB vengono visualizzati due metodi: Query () ed Execute (). Query () restituisce i risultati, Execute () restituisce successo / fallimento.

Questo consente

results = db.Query('select....', parms)
while (row = results.whatever())
{
...
}    

e

if (db.Query( 'update...', parms))
{
  //do something else
}

Non vedo la necessità di dividere il metodo Execute () nei metodi Insert () e Update () a meno che tu non stia cercando di creare un generatore di query e stia usando il tuo livello db per costruire effettivamente lo sql.

    
risposta data 04.10.2012 - 22:04
fonte
0

Una delle pratiche è l'uso di framework di mappatura ORM (come Entity Framework, nHibernate, ecc.)

È possibile utilizzare la potenza della sintassi LINQ con qualsiasi linguaggio di framework .NET (C # e VB.NET in particolare).

Come introduzione rapida, puoi consultare Guida introduttiva a LINQ in C # e poi con esempi LINQ per C # usando questi ORM menzionati.

Per alcune considerazioni, se progetta di saltare ORM puoi utilizzare in modo sicuro stored procedure come metodo comune per mantenere SQL al di fuori di C #.

    
risposta data 04.10.2012 - 19:19
fonte
0

Dipende

Ci sono molti fattori diversi che vanno nella progettazione della tua interfaccia. L'obiettivo di questa interfaccia è quello di togliersi di mezzo il chiamante, in modo che possano svolgere le proprie attività senza preoccuparsi dei dettagli della persistenza e del recupero dei dati (che sono molti).

Detto questo, un buon punto di partenza è la ricerca del lavoro di altri che sono venuti prima di te. La tua applicazione non sembra che stia facendo qualcosa di rivoluzionario, quindi non reinventare troppo la ruota.

ORM

EntityFramework
NHibernate

RollYourOwn

Altri modi per affrontare il problema della interfunzione di codice e database .NET includono, ma non sono limitati a, LINQ to SQL , CQRS , Pattern del repository , tutti e tutti i tipi di file che potrebbero essere utilizzati per la rotazione della propria varietà di ORM
Come bonus, RavenDB può servire come esempio di una libreria di persistenza che serve un'API C # abbastanza solida.

Tutto ciò detto, strongMENTE raccomando contro il rotolamento del proprio livello di persistenza. Usa un ORM che è ampiamente utilizzato e controllato, e ti risparmierai un sacco di dolore.

    
risposta data 04.10.2012 - 21:39
fonte

Leggi altre domande sui tag