C#: Cosa altro usi oltre DataSet


20

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

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

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

-Eric Sipple

20

Dal .NET 3.5 è uscito, ho usato esclusivamente LINQ. È davvero così bello; Non vedo più alcun motivo per usare una di quelle vecchie stampelle.

Per quanto LINQ sia, penso che qualsiasi sistema ORM ti consentirebbe di eliminare quel dreck.

  0

Intendi LINQ to SQL (ovvero L2S)? 11 dic. 092009-12-11 15:50:34

  0

Ovviamente, visto che stiamo parlando dell'accesso al database. Anche se LINQ to Everything Else è altrettanto buono. 16 dic. 092009-12-16 03:21:41


4

Ci siamo allontanati dai set di dati e abbiamo creato i nostri oggetti ORM liberamente basati su CSLA. Puoi ottenere lo stesso lavoro con un DataSet o LINQ o ORM ma riutilizzarlo è (lo abbiamo trovato) molto più facile. 'Meno codice rende più felice'.


1

Io li uso estesamente ma non uso nessuna delle funzionalità "avanzate" che Microsoft stava davvero spingendo quando il framework è stato rilasciato. Fondamentalmente li sto semplicemente usando come Liste di Hashtables, che trovo perfettamente utili.

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

Ovviamente, sono uno dei più strani che in realtà preferisce un DataRow a un'istanza dell'oggetto entità.


1

Pre linq Ho usato DataReader per riempire la lista dei miei oggetti di dominio personalizzati, ma post linq Ho usato L2S per riempire le entità L2S, o L2S per riempire gli oggetti di dominio.

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


3

Ero stufo di 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 gonfio: non ho visto molte app che utilizzano la maggior parte delle sue funzionalità.

SqlDataReader era buono, ma ho usato per avvolgerlo in un IEnumerable<T> dove la T era una qualche rappresentazione digitato della mia riga di dati.

Linq è un sostituto di gran lunga migliore a mio parere.


0

Ho appena creato i miei oggetti di business da zero e non utilizzo quasi mai DataTable e, soprattutto, non il DataSet, eccetto che per popolare inizialmente gli oggetti di business. I vantaggi di creare il tuo sono testabilità, sicurezza di tipo 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, userei anche un ORM e un framework DI di terze parti, ma non ne ho ancora sentito il bisogno. Sto facendo molti progetti di dimensioni più piccole o aggiunte a progetti più grandi.


2

I dataset sono ottimi per le dimostrazioni.

Non saprei cosa fare con uno se mi hai fatto usare.

Io uso ObservableCollection

Poi di nuovo io sono nello spazio di applicazione client, WPF e Silverlight. Quindi passare un set di dati o datatable attraverso un servizio è ... grossolano.

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


1

Selezionare uno strumento ORM moderno, stabile e attivamente supportato deve essere probabilmente il più grande incremento della produttività, quasi ogni progetto di dimensioni e complessità moderate. Se stai concludendo che devi assolutamente, assolutamente, assolutamente scrivere il tuo DAL e ORM, probabilmente stai sbagliando (o stai usando il database più oscuro del mondo).

Se si stanno eseguendo set di dati e righe non elaborati, trascorrete la giornata per provare un ORM e sarete sorpresi di quanto sia più produttivo poter essere senza il lavoro ingrato di mappare le colonne ai campi o per tutto il tempo riempiendo gli oggetti di comando Sql e tutti gli altri che saltavamo tutti noi una volta.

Mi piacciono alcuni Subsonic, anche se per progetti su piccola scala insieme a demo/prototipi, trovo che anche Linq to Sql sia dannatamente utile. Odio EF con una passione però. : P


3

Ho utilizzato il pattern Data Transfer Objects (originariamente dal mondo Java, credo), con un SqDataReader per popolare raccolte di DTO dal livello dati per l'utilizzo in altri livelli dell'applicazione. Le DTO stesse sono classi molto leggere e semplici composte da proprietà con get/sets. Possono essere facilmente serializzati/deserializzati e utilizzati per l'associazione dei dati, rendendoli piuttosto adatti alla maggior parte delle mie esigenze di sviluppo.


-1

NON utilizzo MAI i set di dati. Sono oggetti pesanti di grandi dimensioni solo utilizzabili (come qualcuno ha indicato qui) per "demoware". Qui ci sono molte alternative fantastiche.

  0

"Oggetti pesanti"? Questo termine ha davvero qualche significato? 19 nov. 092009-11-19 20:07:22

  0

Sì, c'è un significato significativo. Serializzare un set di dati con anche solo poche righe in un file XML e dare un'occhiata a quanto è grande. Quindi crea un oggetto di trasferimento dati semplice (la risposta di Jesse). Basta definire una semplice classe con membri per ogni colonna e quindi una classe List <DTO>. Serializzalo in un file XML e dai un'occhiata alla differenza. 25 nov. 092009-11-25 17:02:16

+1

Se serializzi davvero i DataSet e li passi sopra il filo o qualcosa del genere, e c'è un vero problema di prestazioni, questa è una cosa.Ma ho visto "DataSet bloat" usato come giustificazione per fare codice orribile, string-letterale-carico che usa DataReader ovunque nei troppi negozi in cui ho lavorato. 11 dic. 092009-12-11 15:32:01

  0

Certamente sostituire una cattiva implementazione con un'altra è una pessima soluzione - ma devo ancora vedere una soluzione che utilizza set di dati che non possono essere implementati meglio come più efficacemente senza uno. I dataset sono utili per "DEMOware" e un holdover da PRENET ADO 11 dic. 092009-12-11 16:10:05

  0

Ora vedi, questo mi fa pensare che non hai lavorato molto con i DataSet di ADO.NET, e forse non ne sai proprio nulla. I data set ADO.NET sono disconnessi; sono contenitori per i dati. Fanno rispettare le cose come le relazioni con i database e il nullability, motivo per cui hanno così tanti metodi e proprietà che la gente chiama "gonfia". Posso capire perché la gente non li preferirebbe come una questione di stile, ma sono una solida alternativa per coloro che non si preoccupano di uno stile più orientato al database (piuttosto che orientato al modello di oggetti). 14 dic. 092009-12-14 15:53:19


3

Sono un grande fan di SubSonic. Un file batch/CMD ben scritto può generare un intero modello di oggetto per il database in pochi minuti; puoi compilarlo nella sua DLL e usarlo come necessario. Modello meraviglioso, strumento meraviglioso. Il sito fa sembrare un affare ASP.NET, ma in generale funziona meravigliosamente ovunque se non stai cercando di usare il suo framework UI (di cui sono moderatamente deluso) o i suoi strumenti di auto-generazione a livello di applicazione .

Per la cronaca, qui è una versione del comando che uso per lavorare con esso (in modo che non c'è bisogno di combattere troppo duro inizialmente):

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

che lo fa ogni volta. .. Quindi compilare la DLL da quella directory - questo fa parte di un progetto NAnt, attivato da CruiseControl.NET - e via. Lo sto usando in WinForms, in ASP.NET, anche in alcuni programmi di utilità da riga di comando. Questo genera il minor numero di dipendenze e la massima "portabilità" (tra i progetti correlati, EG).

Nota

Quanto sopra è ormai ben più di un anno di età. Mentre nutro ancora 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. Nel caso di .NET 3+, vai con la risposta accettata. In caso di .NET 2.0, vai su SubSonic.


1

Ho usato DataSet tipizzati per diversi progetti. Modellano bene il database, rafforzano i vincoli sul lato client e, in generale, costituiscono una solida tecnologia di accesso ai dati, in particolare con le modifiche apportate a .NET 2.0 con TableAdapter.

I DataSet tipizzati ottengono un brutto colpo da persone che amano usare parole affascinanti come "gonfiate" per descriverle. Concederò che mi piace usare un buon O/R mapper più che usare DataSet; semplicemente "sente" meglio usare gli oggetti e le raccolte invece di digitare DataTable, DataRows, ecc. Ma quello che ho trovato è che se per qualsiasi motivo non puoi o non vuoi usare un mappatore O/R, digitato I DataSet sono una buona scelta solida che è abbastanza facile da usare e ti porterà il 90% dei vantaggi di un mappatore O/R.

EDIT:

Alcuni suggeriscono che qui DataReaders sono l'alternativa "fast". Ma se si utilizza Reflector per esaminare i componenti interni di un DataAdapter (che vengono riempiti da DataTable), si noterà che utilizza ... un DataReader. I DataSet digitati possono avere un ingombro di memoria più ampio rispetto ad altre opzioni, ma devo ancora vedere l'applicazione dove questo fa una differenza tangibile.

Utilizzare lo strumento migliore per il lavoro. Non prendere la tua decisione sulla base di termini emotivi come "grossolani" o "gonfiati" che non hanno alcuna base fattuale.

  0

Non sono sicuro che il tuo commento sia valido: un DataSet viene popolato tramite un DataAdaptor che utilizza un DataReader ma quando sono disponibili i dati? Se si deve attendere fino al completamento della lettura di tutte le righe, ovviamente deve essere più lento. 02 giu. 102010-06-02 06:24:34

  0

Dipende da cosa stai facendo con i dati, però. Forse stai elaborando una grande serie di dati riga per riga; forse stai operando sul set completo e non puoi fare nulla finché non hai tutto. Forse stai ricevendo l'equivalente di una riga, e non importa quale usi. * Sempre * evitando DataSet è l'ottimizzazione prematura. E se è necessario modificare e mantenere i dati, i DataSet sono molto più facili da utilizzare rispetto a DataReader e oggetti temporanei. Evitarli significa offuscare il tuo codice senza motivo. 05 giu. 102010-06-05 16:58:52


2

Ho utilizzato DataSet tipizzati e non tipizzati, DataViewManager, DataView, DataTable, DataRows, DataRowViews e praticamente tutto ciò che si può fare con lo stack da quando è stato rilasciato in più progetti aziendali. Mi ci è voluto un po 'per abituarmi a come ha funzionato. Ho scritto componenti personalizzati che sfruttano lo stack dato che ADO.NETdid non mi ha dato quello di cui avevo veramente bisogno. Uno di questi componenti confronta DataSet e quindi aggiorna i negozi di backend. So davvero come tutti questi elementi funzionano bene e quelli che hanno visto quello che ho fatto sono rimasti molto colpiti dal fatto che sono riuscito a superare la sensazione che fosse utile solo per l'uso dimostrativo.

Uso il binding ADO.NET in Winforms e utilizzo anche il codice nelle app della console. Recentemente ho collaborato con un altro sviluppatore per creare un ORM personalizzato che abbiamo utilizzato contro un datamodel pazzo che ci è stato fornito da appaltatori che non assomigliavano ai nostri normali archivi di dati.

Ho cercato oggi per la sostituzione di ADO.NET e non vedo nulla che dovrei seriamente cercare di imparare a sostituire quello che attualmente uso.