none
[VB 2008] Gestione dei dati RRS feed

  • Discussione generale

  • Vorrei intavolare una discussione su quali metodi usate/preferite per la gestione dei dati con il .NET Framework.

    Questa è la prima volta che uso VB 2008 per un progetto (fino a ieri usavo ancora VB 2003) e mi chiedevo come fosse evoluta la situazione dal punto di vista della gestione dei dati. Vedo che ci sono ancora i Dataset e il modello di binding è rimasto all'incirca lo stesso (tableadapter + bindingsource + dataset). Purtroppo con il .NET framework 1.1 c'erano diversi problemi così, per le applicazioni più complesse, solitamente creavo delle classi che interrogavano il database (SQL Server) manualmente (creavo delle Stored Procedure e leggevo/scrivevo i dati tramite i parametri). Ci sono cose, ad esempio, che sono piuttosto fastidiose, ad esempio:

    - accesso ai grandi database lento (riempire un intero dataset con un DB di qualche centinaio di MB è impensabile);
    - query con JOIN da gestire con le espressioni nei Datatable (ad es. se in una tabella ho un riferimento, per visualizzare un dato della tabella di riferimento devo inserire un campo expression nel DataTable altrimenti non posso visualizzarlo in un DataGrid).

    Inoltre, anche se il Dataset gestisce una cache locale dei dati che è molto comoda, bisogna stare molto attenti a gestire il tempo di connessione con il database per aggiornarlo (solitamente usavo un thread esterno per farlo così l'applicazione non si bloccava).

    Che ne pensate?
    mercoledì 30 dicembre 2009 12:43

Tutte le risposte

  • Personalmente, da quando utilizzo Visual Studio 2008 ricorro o a LINQ to SQL o ad Entity Framework che incapsulano tutte le problematiche di ADO.NET e, a mio modo di vedere, sono molto più semplici da manutenere.
    Prova a leggere i seguenti link:
    http://msdn.microsoft.com/it-it/library/bb425822(en-us).aspx linq to sql
    http://msdn.microsoft.com/it-it/library/aa697427(en-us,VS.80).aspx Entity framework
    mercoledì 30 dicembre 2009 18:39
    Moderatore
  • Si avevo pensato di dare un'occhiata a LINQ di cui ho studiato qualcosa in giro per la rete ma non ho approfondito più di tanto. Darò un'occhiata domattina stesso a quei link.

    Unica domanda: reputi LINQ più flessibile/potente dei semplici DataSet? Potresti eventualmente argomentare con esempi (anche in giro per internet)?

    Ti ringrazio ancora,
    Alessandro.
    mercoledì 30 dicembre 2009 19:50
  • Cosa intendi per più potente.
    LINQ e Entity Framework consentono di lavorare con oggetti tipizzati, cosa che non è possibile fare con i dataset (a patto di non utilizzare quelli tipizzati).
    Inoltre permete di astrarre, in un certo qual modo, lo strato di accesso ai dati dalla struttura database.
    Infine hai a disposizione la possibilità di utilizzare il lazy loading, cioè l'effettivo accesso alla banca dati viene effettuato solo quando serve e non sempre come fai per i dataset.
    Mi spiego, se effettui una query linq to sql, non ottieni effettivamente l'accesso ai dati, ma lo hai solamente quando richiedi i dati (perchè, ad esempio effettui un ciclo sui dati, oppure li conti, etc., etc.).
    Altra cosa interessante è che se hai le relazioni nella banca dati (e, visto che la banca dati è relazionale dovresti averle), LINQ to SQL e Entity Framework è in grado di ricostruire la struttura delle relazioni e questo ti evita di dover fare le join a mano (se ne occupa il motore di LINQ).
    Ti consiglio di dargli un'occhiata, secondo me butti i dataset.
    Prova a vedere qualche web cast su http://www.microsoft.com/italy/beit.
    In particolare prova http://www.microsoft.com/italy/beit/Generic.aspx?video=ada76047-d117-45a4-99a4-6da0f00a13a0 o http://www.microsoft.com/italy/beit/Generic.aspx?video=a5399f1e-24b7-4489-8aac-5a0a78ff9a72 o http://www.microsoft.com/italy/beit/Generic.aspx?video=4f47129b-afe9-4600-bc1a-463b4fc9103b

    Poi, siamo qui a disposizione!
    mercoledì 30 dicembre 2009 20:03
    Moderatore
  • Wow... in effetti è tutto un'altra cosa lavorare così. Certo LINQ to SQL comunque non mi genera un livello di astrazione tale da semplificarmi il lavoro sulle entità di business (di cui, per questo progetto, posso fare a meno) per le quali dovrei utilizzare LINQ to entities ma comunque mi evita un sacco di problemi tra i quali quelli che elencavo prima: sicuramente le transazioni verso il database sono più veloci perché LINQ carica lo stretto indispensabile e le eventuali relazioni vengono caricare on-demand (a meno di specificare un DataLoaderOption) e le JOIN le gestisce per conto suo in base alle relazioni che imposto sul database. Sicuramente un'ottimo strumento... non si finisce proprio mai di imparare.

    Grazie Massimo.

    EDIT: Mi correggo. Eventualmente la logica di business non è un grosso problema: posso implementarla sia nella partial class del designer (senza separazione di livello) oppure implementare le classi "LINQ to SQL" nel livello di accesso ai dati ed utilizzare il livello dei dati per la mia logica di business. Il problema che balza subito agli occhi è l'impossibilità di usare il designer per gestire il binding delle interfacce (o almeno non ho capito come si possa fare).
    giovedì 31 dicembre 2009 10:32