DAL "DataSet tipizzati" o Oggetto aziendale personalizzato

Question

Vorrei le vostre opinioni in merito alle best practice di "DataSet Designer" e DAL (Data Access Layer). Uso Visual Studio 2010 Framework .NEt 4.0.

Per la mia comprensione "DataSet Designer" mi permette di creare automaticamente rigorosamente digitato DataSet con DataTable e l'adattatore, questo consisterà in DAL direttamente in Visual Studio 2010.

Vorrei sapere: - In caso di reale scenario "DataSet Designer" funziona bene, o è meglio scrivere oggetto business personalizzato. - Se esiste un'altra nuova soluzione introdotta in .net 4.0

Grazie per il vostro supporto! :-)

Answer 1

Personalmente preferisco oggetti business personalizzati con la loro flessibilità ma è più lavoro. Guarda anche con Entity Framework e Linq To Sql. Entity Fx ha molta più flessibilità in .NET 4.0. Questo article dovrebbe iniziare su Entity Fx.

Answer 2

Suggerirei un ORM come Entity Framework o Nhibernate.

Data Set odora troppo il modo di pensare del database e personalmente ho avuto molti problemi a lavorare con loro. Si rompono spesso e generano errori strani che sono difficili da risolvere.

Alcune altre questioni correlate si possono trovare interessanti

What are the advantages of using an ORM?

ASP.NET DataSet vs Business Objects/ORM

Answer 3

utilizzare ADO.NET Entity Framework, che è dove il futuro di ORM di Microsoft sta andando. Oppure, considera uno open source come NHibernate ...

HTH.

Answer 4

In caso affermativo dovrei esaminare EntityFramework. Ci arelots di great tutorial là fuori per iniziare.

Answer 5

Con l'avvento del framework .Net 4.0 e l'introduzione di LINQ to SQL, ho adottato un DAL personalizzato per gli oggetti di business strettamente scritti. Abbiamo sperimentato brevemente Entity Framework, ma alla fine abbiamo concluso che è molto simile ai DataSet in quanto il codice generato automaticamente, sebbene a portata di mano, è troppo gonfio di spazzatura extra che alla fine non abbiamo usato.

Abbiamo riscontrato che scrivendo LINQ nel nostro DAL ed estraendo i dati nelle nostre classi personalizzate, siamo in grado di semplificare l'accesso ai dati e controllare l'utilizzo dei dati a livello funzionale. È stato un processo molto pratico, ma ci sono voluti un po 'di tempo per gli sviluppatori junior.

Answer 6

NHibernate. Soprattutto se stai usando Oracle.

Answer 7

Sono personalmente d'accordo con Joel Etherton, condizionatamente.

Se si dispone di un progetto abbastanza piccolo che anche con il gonfiamento di EF non si sta ancora guardando troppo codice shenanigan, direi che la convenienza che offre è utile. Tuttavia in codebase più grandi, può diventare molto da mettere le mani in giro così tanto gonfio.

L'altro vantaggio di EF rispetto agli oggetti di business meno recenti che non viene menzionato, è che con l'implementazione EF probabilmente si aggiorneranno più facilmente alle versioni .NET più recenti sfruttando i vantaggi del successivo .NET senza dover riscrivere un gruppo di codice a mano. (Questa può anche essere un'arma a doppio taglio poiché l'aggiornamento a new .NET con EF può influenzare il comportamento del tuo in contrapposizione a un testo scritto a mano è meno probabile che venga influenzato.)

Detto questo, io d'accordo con Joel Etherton, scrivi il più semplice dal quale puoi implementare LINQ, il dal è sempre troppo importante per rendere eccessivamente complesso ogni volta che può essere evitato.

Answer 8

Devo lavorare con set di dati digitati ed è un incubo. Se hai un'opzione, non usarli mai. Tutto è meglio

Answer 9

Se non si vuole sprecare tempo non si imparano i DataSet. Studia i concetti generali della mappatura oggettuale relazionale, i loro pro e contro. Guarda i progetti come Hibernate per Java o Doctrine per PHP. Gli approcci alla base di DataTable e DataSet che forniscono solo il wrapping degli oggetti del database sono finiti. Il tuo framework dovrebbe guidarti a progettare il tuo modello di dominio, non lo schema del database.

Answer 10

Nella mia azienda abbiamo utilizzato DataSet tipizzati per un po 'di tempo e abbiamo avuto un'esperienza generalmente positiva. Capisco che molte persone non piace DataSet, e ci sono certamente più recenti strumenti di accesso ai dati non mancano, ma dal momento che hai chiesto uno scenario del mondo reale, ecco alcune delle mie esigenze e risultati:

• necessità di essere in grado di leggere SQL Server, MS Access, e le fonti di dati FoxPro
accesso
• SQL Server è solo attraverso chiamate sProc (non la mia scelta)
• relativamente facile da imparare, soprattutto agli sviluppatori nuovi a ASP.NET

Ho esplorato personalmente l'accesso ad un livello basso ado.net, set di dati digitati, linq-to-sql e semplicemente scrivendo classi di accesso ai dati personalizzate. Non ho ancora visionato il Entity Framework, poiché la versione inclusa in VS2008 sembrava avere alcune recensioni contrastanti, e non avevo accesso a VS2010 fino a poco tempo fa (ho intenzione di recensire EF qualche volta ancora quest'anno).

Abbiamo scelto di utilizzare i DataSet digitati perché sembravano offrire uno sviluppo più rapido contro SPROCS e abbiamo trovato un tutorial molto completo di Scott Mitchell sul sito di asp.net: http://www.asp.net/data-access/tutorials.

Per quanto riguarda la nostra esperienza fino ad ora, è stata soprattutto buona. La finestra di progettazione DataSet genera un'enorme quantità di codice anche per un numero ridotto di tabelle (< 20). Apportare modifiche ai SPROCS ha causato alcuni grattacapi, ma mi piacerebbe che mi venisse mostrato uno strumento che facilitasse la cosa.

Una cosa che potresti provare a rendere più semplice la tua decisione: inventare un piccolo problema di dominio come una pagina di modifica del cliente o una pagina di inserimento degli ordini e implementarla più volte utilizzando una varietà di tecnologie. Ci vuole del tempo per farlo, ma è un buon modo per imparare e puoi confrontare le tecnologie per te stesso. Lo abbiamo fatto e ci è sembrato di aiutare molto.