C#:Cos'altro usi oltre a DataSet

Question

Mi sono trovato sempre più insoddisfatto del paradigma DataSet/DataTable/DataRow in .Net, soprattutto perché spesso è un paio di passaggi più complicati di quello che voglio veramente fare.Nei casi in cui sono vincolato ai controlli, i DataSet vanno bene.Ma in altri casi, sembra esserci una discreta quantità di sovraccarico mentale.

Ho giocato un po' con SqlDataReader e sembra essere utile per semplici escursioni attraverso una selezione, ma sento che potrebbero esserci altri modelli in agguato in .Net che sono utili per saperne di più.Sento che tutto l'aiuto che trovo su questo utilizza solo DataSet per impostazione predefinita.Forse quello e DataReader sono davvero le migliori opzioni.

Non sto cercando una ripartizione migliore/peggiore, sono solo curioso di sapere quali sono le mie opzioni e quali esperienze hai avuto con esse.Grazie!

-Eric Sipple

Answer 1

Da quando è uscito .NET 3.5, ho utilizzato esclusivamente LINQ.È davvero così bello;Non vedo più il motivo di usare quelle vecchie stampelle.

Per quanto eccezionale sia LINQ, penso che qualsiasi sistema ORM ti consentirebbe di eliminare quella schifezza.

Answer 2

Ci siamo allontanati dai set di dati e abbiamo creato i nostri oggetti ORM liberamente basati su CSLA.Puoi portare a termine lo stesso lavoro con un DataSet o LINQ o ORM ma riutilizzarlo è (abbiamo scoperto) molto più semplice."Meno codice rende più felici".

Answer 3

Ero stufo dei DataSet in .Net 1.1, almeno lo hanno ottimizzato in modo che non rallenti più in modo esponenziale per i set di grandi dimensioni.

È sempre stato un modello piuttosto esagerato: non ho visto molte app che utilizzassero la maggior parte delle sue funzionalità.

SqlDataReader era buono, ma lo racchiudevo in un file IEnumerable<T> dove la T era una rappresentazione digitata della mia riga di dati.

Linq è un sostituto di gran lunga migliore secondo me.

Answer 4

Ho usato il Oggetti di trasferimento dati pattern (originario del mondo Java, credo), con uno SqDataReader per popolare raccolte di DTO dal livello dati da utilizzare in altri livelli dell'applicazione.I DTO stessi sono classi molto leggere e semplici composte da proprietà con get/set.Possono essere facilmente serializzati/deserializzati e utilizzati per l'associazione dati, rendendoli abbastanza adatti alla maggior parte delle mie esigenze di sviluppo.

Answer 5

Sono un grande fan di Subsonico.Un file batch/CMD ben scritto può generare un intero modello a oggetti per il tuo database in pochi minuti;puoi compilarlo nella sua DLL e usarlo secondo necessità.Modello meraviglioso, strumento meraviglioso.Il sito sembra un accordo ASP.NET, ma in generale funziona meravigliosamente praticamente ovunque se non stai tentando di utilizzare il suo framework dell'interfaccia utente (di cui sono moderatamente deluso) o i suoi strumenti di generazione automatica a livello di applicazione .

Per la cronaca, ecco una versione del comando che utilizzo per lavorarci (in modo da non dover lottare troppo inizialmente):

sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true

Lo fa ogni volta...Quindi crea la DLL da quella directory (fa parte di un progetto NAnt, avviato da CruiseControl.NET) e via.Lo sto usando in WinForms, ASP.NET e anche in alcune utilità da riga di comando.Ciò genera il minor numero di dipendenze e la massima "portabilità" (tra progetti correlati, EG).

Nota

Quanto sopra ha ormai più di un anno.Anche se ho ancora un grande affetto nel mio cuore per SubSonic, sono passato a LINQ-to-SQL quando ho il lusso di lavorare in .NET 3.5.In .NET 2.0 utilizzo ancora SubSonic.Quindi il mio nuovo consiglio ufficiale dipende dalla versione della piattaforma.In caso di .NET 3+, vai con la risposta accettata.In caso di .NET 2.0, scegli SubSonic.

Answer 6

I DataSet sono ottimi per le demo.

Non saprei cosa farmene se me lo costringessi ad usare.

Utilizzo ObservableCollection

Poi di nuovo sono nello spazio dell'app client, WPF e Silverlight.Quindi passare un set di dati o una tabella dati attraverso un servizio è...grossolano.

I DataReader sono veloci, poiché sono un flusso solo in avanti del set di risultati.

Answer 7

Ho utilizzato DataSet digitati e non tipizzati, DataViewManagers, DataView, DataTable, DataRows, DataRowView e praticamente tutto ciò che puoi fare con lo stack sin dalla sua prima uscita in più progetti aziendali.Mi ci è voluto un po' per abituarmi a come funzionava.Ho scritto componenti personalizzati che sfruttano lo stack poiché ADO.NET non mi ha dato ciò di cui avevo veramente bisogno.Uno di questi componenti confronta i DataSet e quindi aggiorna gli archivi backend.So davvero come funzionano bene tutti questi elementi e coloro che hanno visto ciò che ho fatto sono rimasti molto colpiti dal fatto che sono riuscito ad andare oltre, ritenendo che fosse utile solo per l'uso demo.

Utilizzo l'associazione ADO.NET in Winforms e utilizzo anche il codice nelle app console.Recentemente ho collaborato con un altro sviluppatore per creare un ORM personalizzato che abbiamo utilizzato contro un modello di dati folle che ci è stato fornito da appaltatori che non somigliavano per niente ai nostri normali archivi dati.

Oggi ho cercato la sostituzione con ADO.NET e non vedo nulla che dovrei provare seriamente a imparare per sostituire quello che utilizzo attualmente.

Answer 8

Li utilizzo ampiamente, ma non utilizzo nessuna delle funzionalità "avanzate" che Microsoft stava realmente spingendo quando è uscito il framework per la prima volta.Fondamentalmente li sto usando solo come elenchi di tabelle hash, che trovo perfettamente utili.

Non ho visto buoni risultati quando le persone hanno provato a creare DataSet tipizzati complessi o hanno provato a impostare effettivamente le relazioni di chiave esterna tra tabelle con DataSet.

Naturalmente, io sono uno di quelli strani che in realtà preferisce un DataRow a un'istanza di oggetto entità.

Answer 9

Prima di linq ho utilizzato DataReader per compilare l'elenco dei miei oggetti di dominio personalizzati, ma dopo linq ho utilizzato L2S per riempire le entità L2S o L2S per riempire gli oggetti di dominio.

Una volta che avrò un po' più di tempo per indagare, sospetto che gli oggetti Entity Framework saranno la mia nuova soluzione preferita!

Answer 10

La scelta di uno strumento ORM moderno, stabile e supportato attivamente deve essere probabilmente il più grande incremento della produttività che qualsiasi progetto di dimensioni e complessità moderate può ottenere.Se stai concludendo che devi assolutamente, assolutamente, assolutamente scrivere il tuo DAL e ORM, probabilmente stai sbagliando (o stai utilizzando il database più oscuro del mondo).

Se stai creando set di dati grezzi e righe e cosa no, trascorri la giornata a provare un ORM e rimarrai stupito di quanto puoi essere più produttivo senza tutta la fatica di mappare le colonne sui campi o riempire tutto il tempo Oggetti comando SQL e tutti gli altri salti mortali che tutti abbiamo affrontato una volta.

Mi piace un po' di Subsonic, anche se per progetti su scala più piccola insieme a demo/prototipi, trovo anche Linq to Sql dannatamente utile.Odio EF con passione però.:P

Answer 11

Ho utilizzato DataSet tipizzati per diversi progetti.Modellano bene il database, impongono vincoli sul lato client e in generale rappresentano una solida tecnologia di accesso ai dati, soprattutto con le modifiche in .NET 2.0 con TableAdapter.

I DataSet tipizzati ricevono una cattiva reputazione da parte di persone a cui piace usare parole emotive come "gonfio" per descriverli.Ammetto che mi piace usare un buon mappatore O/R più che usare DataSet;è semplicemente "sembra" meglio usare oggetti e raccolte invece di DataTables, DataRows, ecc. digitati.Ma quello che ho scoperto è che se per qualsiasi motivo non puoi o non vuoi usare un mappatore O/R, i DataSet tipizzati sono una buona scelta solida che è abbastanza facile da usare e ti darà il 90% del vantaggi di un mappatore O/R.

MODIFICARE:

Alcuni qui suggeriscono che i DataReader siano l'alternativa "veloce".Ma se usi Reflector per esaminare le parti interne di un DataAdapter (da cui sono riempiti i DataTable), vedrai che utilizza... un DataReader.Set di dati tipizzati Maggio hanno un ingombro di memoria maggiore rispetto ad altre opzioni, ma devo ancora vedere l'applicazione in cui questo fa una differenza tangibile.

Utilizza lo strumento migliore per il lavoro.Non prendere la tua decisione sulla base di parole emotive come "schifoso" o "gonfio" che non hanno alcuna base fattuale.

Answer 12

Costruisco semplicemente i miei oggetti business da zero e non utilizzo quasi mai DataTable e soprattutto DataSet, tranne che per popolare inizialmente gli oggetti business.I vantaggi di crearne uno tuo sono testabilità, sicurezza dei tipi e intellisense, estensibilità (prova ad aggiungere a un DataSet) e leggibilità (a meno che non ti piaccia leggere cose come Convert.ToDecimal(dt.Rows[i]["blah"].ToString() )).

Se fossi più intelligente, utilizzerei anche un ORM e un framework DI di terze parti, ma non ne ho ancora sentito il bisogno.Sto realizzando molti progetti di dimensioni più piccole o aggiunte a progetti più grandi.

Answer 13

Non uso MAI i set di dati.Sono oggetti grossi e pesanti utilizzabili (come qualcuno ha sottolineato qui) solo per "demoware".Ci sono molte ottime alternative mostrate qui.