blogs.ASPItalia.com

Entity Framework e le performance con la Like

2009-06-09T05:00:00+00:00

Nel bel mezzo della notte insonne ho deciso di fare qualche test per verificare quanto il problema mostrato in questo script fosse rilevante.

Ho creato una tabella con un solo campo di tipo varchar(50) e l'ho popolata con 500.000 righe. poi ho creato una console application ed ho eseguito la stessa query per 100 volte utizzando prima la sintassi LINQ To Entities e poi quella Entity SQL.

Il risultato è abbastanza impietoso perchè la sintassi LINQ To Entities impiega 1'02''815 mentre quella Entity SQL impiega 1''221. La differenza di 1 minuto su 100 query è enorme. questo fatto è da considerare quando si vogliono fare applicazioni scalabili con Entity Framework.. tenetelo a mente

Stay Tuned...

Tags: ADO.NET Entity Framework, LINQ

Entity Framework e la generazione di codice POCO

2009-06-02T18:22:55+00:00

Una delle cose più Sgradite di Entity Framework 4.0 è il fatto che il designer non genera classi POCO. Questa scelta è ovvia e rimarrà quella di default anche in RTM per mantenere la compatibilità col passato. La buona notizia è che per la RTM il team dovrebbe anche includere un template T4 per la generazione di classi POCO.

La certezza assoluta è che questo template genererà le classi aggiungendole allo stesso assembly in cui si trova l'EDMX. Ora che finalmente abbiamo un sistema OTTIMO-FANTASTICO-ECCEZIONALE-MERAVIGLIOSO-PERFETTO di generazione del codice, questa limitazione si può superare. Cercando un pò in rete e partendo dalla base del template esistente, sono arrivato a creare un template che permette di:

Generare le classi e l'objectcontext in classi separate.

Aggiungere le classi ad un assembly diverso da quello in cui si trova l'edmx. Nell'assembly dell'ObjectModel o del DomainModel ad esempio. (Facoltativo).

Aggiungere l'objectcontext ad un assembly diverso da quello in cui si trova l'edmx. Nell'assembly del DAL ad esempio. (Facoltativo).

Mantenete il proprio codice aggiunto alle entities anche quando l'entità viene rigenerata.

Ovviamente il tutto è molto Beta 1 ma credo sia un ottimo punto di partenza per capire come funziona il T4 e per avere classi POCO da subito. In altri post vedremo come ho risolto alcuni problemi. nel frattempo potete scaricare il template a questo indirizzo.

Tags: .NET Framework, .NET Framework 4.0, ADO.NET Entity Framework, ORM

.NET Framework 4.0 Beta 1: Entity Framework

2009-05-18T14:14:28+00:00

In questi minuti è uscita la beta 1 del .NET Framework 4.0. Ovviamente, per quanto mi riguarda, la cosa più interessante è Entity Framework 4.0. Le novità della nuova versione sono state annunciate già da tempo nel blog dedicato e quindi non ci sono cose nuove da scoprire.

Nonostante questo, credo che sia il caso di fare una carrellata in rigoroso ordine di preferenza personale :)

Supporto per mappare le stored procedure su tipi custom: fino ad ora le stored procedure potevano essere mappate solo verso entità o su tipi custom che però avessereo un mapping verso una tabella o view nel database. adesso finalente questo on sarà necessario. Basterà creare un ComplexType e mapparci la SP.
Designer decente. Finalmente il designer può defnirsi decente. innanzitutto c'è il supporto per i complex types ma soprattutto non ci sono crash ogni volta che si fa qualcosa di un pelino più complesso.
Customizzazione del codice generato tramite T4. Finalmente possiamo customizzarce il codice che genera il designer tramite un template. ovviamente possiamo anche suddividere le clasi su più file e molto altro ancora.
Persistence Ignorance. Gran bella novità per carità.... Ma non sempre mi è servità come le altre precedenti
Miglior supporto per lo sviluppo n-tier con API che semplificano la vita.
Foreign-key per semplificare la vita quando si inseriscono sul db entità in relazione tra loro (solo dopo la beta 1)
Possibilità di generare il database partendo dalle classi (Model first).
Lazy loading

Ci sono altre piccole feature che scopriremo col tempo, ma direi che ormai è il momento di provarle sul campo :D.

Maggiori informazioni e le informazioni per il download sono disponibili nel nostro mini-sito dedicato al .NET Framework 4.0.

Stay Tuned...

Tags: .NET Framework 3.5, .NET Framework 4.0, ADO.NET Entity Framework, LINQ, ORM, .NET Framework

Windows Comunication Foundation al Basta! On Tour di Milano

2009-05-07T09:08:23+00:00

Come già ampiamente annunciato, Giovedì 28 e Venerdì 29 Maggio a Milano ci sarà il Basta! On Tour. A Differena dell'edizione di Marzo a Roma, questa volta non si terranno sessioni singole ma sarà una due giorni dedicata solamente a workshop che permettono così di dedicarsi interamente ad un argomento garantendo così molti approfondimenti che spesso in una sessione singola non sono possibili. Personalmente devo dire che questo tipo di organizzazione mi piace molto :D.

Per quanto mi riguarda, terrò una track su WCF dove parlerò di svariati argomenti come la sicurezza, la tracciabilità delle chiamate, l'estendibilità ed altro ancora quindi preparatevi perchè l'agenda è parecchio succulenta ;).

Visto che la modalità dell'evento mi piace parecchio, direi che l'iscrizione è un MUST. Visto che non ci facciamo mai mancare occasioni, vi ricordo che gli iscritti alla community hanno uno sconto del 15% (utilizzando il promotion code "aspitalia") e che comunque fino al 15 Maggio la tariffa è ridotta del 15%, quindi...... non avete scuse per non esserci.

Stay Tuned...

Tags: .NET Framework 3.0, Windows Communication Foundation

Virtual Earth è finalmente dotato di una ricerca decente

2009-04-11T00:54:44+00:00

Tempo fa scrissi un articolo su Virtual Earth dicendo che la ricerca era il vero tallone d'achille di questa tecnologia. Non ho mai lavorato in maniera diretta con google maps, ma virtual earth mi sebrava davvero ben fatto con api semplici e ottime potenzialità. Tuttavia, il fatto che per trovare casa mia bisognasse inserire l'indirizzo, il cap la città e lo stato mi sembrava un'ottima causa per spingere l'adozione ai minimi storici.

Leggo oggi che Microsoft ha rilasciato una nuova versione di Virtual Earth ed un aggiornamento del controllo. la maggior parte delle novità sono interne e non visibili agli sviluppatori, ma il fatto che ora la ricerca sembra trovare tutto senza problemi o necessità di inserire tutti i dati di un indirizzo mi fa ben sperare. Ripeto, non ho lavorato direttamente con google maps, ma se dopo altre prove mi convinco che la ricerca è efficiente, probabilmente comincierò a considerare Virtual Earth un prodotto molto più serio.

Stay Tuned...

Prime impressioni su ASP.NET MVC

2009-03-21T11:39:52+00:00

Sto lavorando ormai da un paio di mesi su ASP.NET MVC. Premetto che sulla parte architetturale del pattern non ne sapevo niente quindi il mio primo approccio è stato puramente pratico. Dopo la prima fase di totale nausea e scomodità ho cominciato comunque ad apprezzare questo modo di sviluppare applicazioni web. I punti che mi interessa sottolineare sono:

Produttività

Sviluppare applicazioni sfruttando le webform è molto più semplice e veloce. Il fatto di avere a disposizione gli eventi è molto comodo così come un ciclo di vita molto più articolato che ci permette di infilarci ovunque. Tuttavia, non è vero come ho sentito dire che una pagina sviluppata con MVC richiede oltre il doppio del tempo. Certo quando l'interazione è particolarmente complessa probabilmente si deve lavorare parecchio, ma grazie ad ajax e jQuery il tutto diventa molto più semplice e a volte anche più pulito rispetto alle webform (vedi updatepanel). Ora che ho una certa dimestichezza posso dire che una funzionalità con un'interazione mediamente complessa sviluppata con MVC richiede circa il 15% in più del tempo. Certo è sempre più tempo, ma se ci si mettono i benefici che si traggono dall'utilizzo di MVC, è un tempo accettabile.

Performance

Non ho in mano numeri reali, ma la differenza si vede ad occhio nudo. Eliminando viewstate, ciclo di vita e altre menate varie delle webforms, ASP.NET MVC vince 6-0 6-3 6-2 in 60 minuti e senza possibilità di replica.

Curva di apprendimento

Questo è il grosso neo. Non dico che ASP.NET MVC sia così complesso, ma in generale il cambio di paradigma di sviluppo rende il passaggio più complesso poichè per certi versi è completamente agli antipodi rispetto alle webforms. Questo in un team composto prettamente da figure junior richiede almeno 3/4 di settimane di studio e test. Rispetto a quanto ci vuole per passare da classic ASP ad ASP.NET webforms la curva è molto più complessa.

Eleganza

A chi dice che il codice con ASP.NET MVC sia più elegante io rispondo dicendo che non è assolutamente vero. Le porcate si possono fare tanto in MVC quando con le webforms e con la stessa facilità. La realtà è che MVC offre una grande opportunità per separare bene il codice dall'interfaccia e renderlo testabile, ma laddove la testabilità non interessa (e parliamoci chiaro LA VERA TESTABILITA' INTERESSA SOLO UNA PICCOLA PARTE DEI SITI CHE SI SVILUPPANO NEL MONDO) con webforms possiamo ugualmente scrivere dei siti eleganti facilmente manutenibili e con un'ottimo grado di separazione del codice. Sfruttando a dovere usercontrol e custom control, le pagine risultano anche più leggibili delle view di mvc ed il codice è ugualmente ben organizzato. Certo non è testabile via tool, ma nella maggior parte dei casi.. chissene.

Finale

Dovete fare un sito e siete indecisi se utilizzare ASP.NET MVC o le webforms? La prima discriminante è la testabilità. Se questa è obbligatoria, allora MVC è la sola scelta, se la risposta è no, webforms parte favorito. La seconda discriminante è la quantità di interazione tra la pagina e l'utente. Se questa è molto complessa (diversi roundtrip al server, modifiche pesanti dell'html, etc etc) webforms è la via più semplice. Se invece si fa prettamente visualizzazione di dati e navigazione, ASP.NET MVC costituisce una valida alternativa.

My 2 cents ... Stay tuned ...

Tags: ASP.NET, ASP.NET 3.5, ASP.NET MVC, Pattern

Entity Framework in action è in disponibile in MEAP

2009-02-16T00:19:02+00:00

Da giovedì scorso il mio libro Entity Framework in action è ufficialmente disponibile in MEAP dal sito Manning.

Per ora sono disponibili i capitoli di introduzione, quello sul querying e quello sul mapping più una appendice dedicata a LINQ in generale ma molto presto ne vedrete anche altri.

E' inutile dire che la mia soddisfazione è immensa. Il libro è ancora ben lontano dall'essere perfetto ma mi piace come sta venendo su . speriamo piaccia anche a voi :D.

Stay tuned.

Tags: .NET Framework 3.5, ADO.NET Entity Framework, LINQ, ORM

Entity Framework e l'EDM

2009-01-31T23:44:49+00:00

Penso che nessuno possa mettere in dubbio che il file di mapping sia una delle cose più complesse di Entity Framework. Microsoft ha prodotto un editor per semplificarne l'uso proprio perchè spesso, la differenze tra uno e l'altro ORM non è la potenza, ma la velocità di startup. In questo Entity Framework non ha quasi rivali, pochi click ed il dominio è generato con tanto di mapping verso il database.

Tuttavia, l'editor nella versione attuale è monco. Non supporta Complex Types (ok non moriremo per questo, però...), non supporta le DefiningQuery, sovrascrive ogni modifica fatta a mano nello storage layer (ogni tanto mi capita di metterci della roba che mi serve e doverla rimettere ad ogni aggiornamento mi rode), Non supporta il mapping di stored procedure polimorfiche, non supporta le QueryView. Insomma, ci sono diverse cose che qualunque progetto un tantinello più avanzato richiede e che il designer non supporta. Attenzione però, per quanto riguarda i complex types, se li si introduce a mano il designer smette di funzionare, mentre negli altri casi continua a funzionare tranquillamente.

Queste lacune mi hanno fatto pensare ancora una volta di più che conoscere il mapping è fondamentale. Personalmente ritengo le DefiningQuery una delle feature più interessanti perchè permettono di creare delle view direttamente nel modello. Queste view sono interrogabili filtrabili etc etc e spesso risolvono tutti quei problemi di mapping che non sono gestibili in maniera nativa. Non emergendo nel designer, quanti le conoscono? Quanti le hanno mai usate? Nella mia esperienza in alcune aziende la risposta è: zero.

Mi riprometto di parlare di più di questa interessante feature di EF. Nel frattemo ribadisco quello che ho detto ad una persona tempo fa: non dire che una cosa non la puoi mappare se prima non sei passato per le DefiningQuery.

Stay Tuned...

Tags: .NET Framework 3.5, ADO.NET Entity Framework, LINQ, ORM

Entity Framework e le Navigation Properties

2008-12-27T23:12:26+00:00

Una relazione è per sua natura bidirezionale. Quello che non è sempre bidirezionale è la sua rappresentazione nel domain model. Prendiamo ad esempio la relazione tra clienti e ordini. Avere a disposizione il cliente di un ordine ha senso, ma ha senso avere a disposizione la lista degli ordini di un cliente? la risposta esatta come sempre è.... dipende. Ora non voglio disquisire sulla validità o meno della relazione ma su come Entity Framework affronta il problema.

Per default, il wizard si accorge della relazione tra le tabelle e genera un domain model dove le relazioni tra le classi sono bidirezionali, quindi un ordine ha la relazione verso il cliente e il cliente ha una relazione verso gli ordini. Supponiamo che non ci sia utile in alcun modo la relazione tra cliente e ordine. La logica vuole che questa sia eliminata. Il primo problema è che il designer non lo permette; bisogna andare a mano nel codice ed eliminare la proprietà Ordini dalla classe Cliente e nel conceptual model del file di mapping eliminare il riferimento alla proprietà cancellata ed il gioco è fatto. Il secondo problema risale a LINQ to Entities. Abbiamo bisogno della proprietà Ordini per fare le nostre query? In tutti i progetti che ho seguito la risposta è stata no. Grazie al fatto che comunque l'ordine mantiene la proprietà Cliente si riesce a risalire a qualunque dato di cui si ha bisogno. L'unico vero problema sono le query generate a run-time. La regola numero uno è che bisogna sempre vedere le query generate per evitare problemi.

Comunque per ora la mia linea guida è quella di non creare proprietà inutili che complicano solo la vita.

Stay tuned...

Tags: .NET Framework, .NET Framework 3.5, ADO.NET Entity Framework, LINQ, ORM

Dubbio amletico sul codice SQL di Entity Framework con il Table per Hierarchy

2008-12-09T00:14:02+00:00

Stavo facendo un pò di prove per smanettare con la gestione del Table per Hierarchy in Entity Framework. Innanzitutto dopo un impatto iniziale alquanto dramamtico, devo dire che il designer visuale mi ha aiutato non poco a disegnare la struttura partendo dalla classe autogenerata dal database. Visto che il designer è forse la cosa uscita peggio da Entity Framework, tutto sommato direi che questa è una buona cosa.

Dopo aver mappato tutto come si deve, ho eseguito una semplice query per trovare tutti gli oggetti: ctx.Company().ToList();

Quello che mi ha sorpreso è vedere che il generatore di codice di Entity Framework ha generato questo SQL:

SELECT
[Extent1].[Type] AS [Type],
[Extent1].[CompanyId] AS [CompanyId],
[Extent1].[Name] AS [Name],
[Extent1].[BillingAddress] AS [BillingAddress],
[Extent1].[BillingCity] AS [BillingCity],
[Extent1].[BillingZipCode] AS [BillingZipCode],
[Extent1].[BillingCountry] AS [BillingCountry],
[Extent1].[ShippingAddress] AS [ShippingAddress],
[Extent1].[ShippingCity] AS [ShippingCity],
[Extent1].[ShippingZipCode] AS [ShippingZipCode],
[Extent1].[ShippingCountry] AS [ShippingCountry],
[Extent1].[WSUserName] AS [WSUserName],
[Extent1].[WSPassword] AS [WSPassword],
[Extent1].[WSEnabled] AS [WSEnabled]
FROM [dbo].[Company] AS [Extent1]
WHERE ([Extent1].[Type] = 'C') OR ([Extent1].[Type] = 'S')

Ora, type è la colonna che mi fa da discriminatore tra i vari tipi che la tabella contiene, ma visto che tanto sto chiedendo tutti i tipi, è necessaria quella OR? Non capisco se sta li per sicurezza così che se ci sono altri record con un type diverso questi vengono ignorati, oppure sta li per errore.

Stay tuned...

Tags: .NET Framework 3.5, ADO.NET Entity Framework, LINQ, ORM

Entity Framework e le cancellazioni a cascata

2008-11-28T01:36:35+00:00

Sono masochista oltre ogni limite: utilizzo Entity Framework e non uso il designer. Non è un problema di funzionamento del tool, è che ormai la struttura degli XML, seppur difficile all'inizio, mi è chiara e poi sono sempre i soliti 4 nodi che devo usare e grazie all'intellisense in Visual Studio è anche piuttosto facile.

Stasera per fare una prova ho voluto usare il tool visuale. Dopo aver creato la classica situazione ordini-dettagli, mi accorgo che se cancello un'ordine senza aver caricato i dettagli la cancellazione scoppia. Subito penso ad un problema di foreign key sul db, ed infatti il problema risiedeva li. tutto bello aggiorno il modello e noto che nella sezione del ssdl la delete cascade è fedelmente riportata.

Riprovo e ricevo ancora errore e qui comincio ad interrogarmi perchè non capisco il problema. Alla fine scopro che pur aggiornando il modello, nel ssdl la delete-cascad veniva corretaente riportata, menre nel csdl no, lasciando un bel buco aperto. La soluzione per me è stata semplice perchè ho cancellato il file edmx e l'ho ricreato; per quelli che non possono permettersi di fare una cosa del genere, ricordatevi di aggiornare a mano il csdl.

 <Association Name="FK_OrderDetail_Order"> 
    <End Role="Order" Type="EFInactionOrdersModel.Store.Order" Multiplicity="1"> 
        <OnDelete Action="Cascade" /> 
    </End> 
     ...
 </Association>

Stay Tuned...

Tags: .NET Framework 3.5, ADO.NET Entity Framework, LINQ, XML

Entity Framework vNext

2008-10-29T16:16:33+00:00

Ieri pomerggio l'ulimo slot è stato dedicato a Entity Frameork vNext. Devo dire che le novità sembrano molto interessanti. A parte il supporto per la Persistence Ignorance che era una cosa nota, ci sono altre caratteristiche che saltano agli occhi.

La prima è il supporto di un modello di sviluppo EDM-free. praticamente si generano le classi POCO. poi nell'objectcontext si mappano le classi al database attraverso degli attributi e i file di mapping di EF vengono generati a run-time. Questo consente di generare classi in maniera semplice senza avere nessun riferimento al db e di lasciare tutto il mapping ad EF. Non so onestamente come si gestiscono feature come l'ereditarietà, ma vedremo. questo approccio è sicuramente interessante quando il domain model è molto semplice.

Un'altro scenario supportato dal designer è quello di disegnare visualmente le classi e generare direttamente il database dalla loro struttura. Ad ogni cambiamento delle classi si da ora a possibilità di allineare il database, Questa cosa mi piace di meno perchè la vedo pericolosa, ma comunque in uno scenario di Domain-Model first ha il suo perchè.

Il lazy loading viene ora implementato in maniera trasparente impostando la proprietà deferredloadingenabled dell'objectcontext a true (non ricorda vagamente linq to sql?). Ovviamente, per mantenere la compatibilità, questa proprietà di default è a false e va impostata oni volta a true (se se ne ha bisogno).

Insomma, Entity Framework sembra diventare sempre più potente. Se alcuni problemi di mapping verranno risolti ed il designer viene reso stabile, penso che avremo per le mani un gran bel prodotto pronto per competere con tutti gli altri.

Stay Tuned...

Tags: .NET Framework 3.5, ADO.NET Entity Framework, LINQ, ORM, PDC 2008

Cache a tutta Velocity

2008-10-29T00:26:54+00:00

Titolo banalissimo ma la giornata l'ho dedicata a Velocity. Visto che oggi è stata anche rilasciata la CTP2 perchè non dargli una vera occhiata da vicino. La prima sessione ha mostrato quello che già si sapeva dalla CTP1 ovvero la suddivisione in l'architettura di base che ogni developer deve conoscere per usare velocity, mentre la seconda ha mostrato la vera potenza di questo framework di caching. Infatti sono state mostrate alcune cose che spiegano come il prodotto sia ben fatto.

Innanzitutto c'è una gestione dei lock, quindi si possono recuperare oggetti e loccarli fino al rilascio o alla scadenza di un tempo (Ovviamente ci sono 2 API distinte una per recuperare i dati senza lockare e un aper locckare). Quello che più mi piace è il lock ottimistico dei dati. Ogni dato in cache ha un numero di versione e quindi se lo si recupera e poi riaggiorna, ma nel frattempo qualche altro processo ha modificato il dato nella cache, l'aggiornamento va male. Insomma un locking ottimistico come sul database.

La replicazione della cache è fantastica in quanto avviene in un thread separato e quindi le performance dell'applicazione non vengono intaccate. Ovviamente in caso di caduta di un nodo, i dati sono replicati e velocity è in grado di recuperare comunque i dati senza causare problemi all'applicazione che rimane "ignorante" da questi problemi. Ovviamente velocity può essere usato anche in locale e vedendo come la cache di ASP.NET cede di fronte a carichi elevati, questa è una buona cosa.

La cosa che comunque più mi piace è che gli oggetti possono essere ritrovati usando LINQ. Sebbene questa cosa era scontata, la cosa bella è che la ricerca avviene tramite un provider che implementa IQueryable<T> e non tramite la classica ricerca IEnumerable<T>.

Naturalmente, Velocity usa WCF come meccanismo di trasporto quindi ho qualche dubbio sulle performance reali, ma stando alle statistiche che hanno mostrato sembra che abbiano trovato la chiave per spingere sull'accelleratore.

Che dire Velocity sembra promettente, speriamo bene :)

Stay tuned...

Tags: Cache, PDC 2008, Architettura

Svelato il C# 4.0 alla PDC

2008-10-27T22:12:00+00:00

I tre mariachi stanno seguendo in questo momento la sessione sul C# 4.0 alla PDC. Come sempre Anders Hejsberg è il mattatore della scena e sta spiegando il futuro come solo il papà del linguaggio sa fare.

Le novità sono molto interessanti.

La principale, come tutti sanno, è che il C# supporterà i linguaggi dinamici attraverso una nuova parola chiave dynamic. Questa è una piccola svolta nel mondo statico del C#, infatti d'ora in poi potremo aggiungere nuove proprietà a qualunque classe direttamente a runtime. Sinceramente questa cosa non dico che è una mezza schifezza, ma come minimo mi lascia perplesso. Non dubito che i linguaggi dinamici abbiano una loro posizione, ma fino ad adesso non mi è mai capitato di avere bisogno di questa feature nelle mie applicazioni. Vedremo...

Un'altra importante novità è la riscrittura del compilatore che adesso diventa un servizio (Compiler as a Service mi dice Ughetto) che espone le porprie API permettendo una nuova serie di funzionalità e la semplificazione di alcune esistenti. Adesso potremo scrivere codice C# in una stringa ed eseguirla a runtime evitando di usare la reflection. Insomma se non si era ancora capito, la tipizzazione sembra diventare sempre meno importante. :)

Poi c'è la covarianza per quanto riguarda le liste di oggetti. Non è che ci ho onestamente capito molto, quindi aspetto Cristian che sicuramente saprà spiegare meglio di me :).

L'ultima novità che mi ricordo riguarda la possibilità di assegnare un valore di default ai parametri delle funzioni e di poter passare alle funzioni i parametri specificando il nome. Quest significa che se una funzione accetta 10 parametri, ma ne dobbiamo passare solo 2 e gli altri possono mantenere quello di default possiamo scrivere qualcosa del genere: Call(par1: "Valore", par2: 2);

Insomma niente di particolarmente emozionante, io non vedo molto bene la mancanza di tipizzazione. Che ci volete fare, già solo vedere che la dinamicità in C# è abbilitata grazie ad una classe statica che si chiama Dynamic non è il massimo :)

Stay tuned...

Tags: .NET Framework, .NET Framework 4.0, PDC 2008

Chi si ricorda dei DataSet?

2008-10-08T20:04:38+00:00

Mi ricordo le prime demo che ho visto riguardo al .NET. Per l'accesso ai dati il DataSet sembrava l'autentica panacea per tutti i mali. A distanza di ormai 7 anni (un'infinità in termini informatici), i DataSet sono diventati il male impersonificato.

Fondamentalmente questo è quanto di meglio potesse accadere per certi tipi di applicazioni, ma parliamoci chiaro, in Italia si fanno una miriade di piccole-medie applicazioni che non hanno alcuna complessità e che quindi non trarrebbero vantaggio alcuno dall'uso di un bel domain model con un datalayer che persiste tramite ORM o a mano. In questi casi i DataSet non sono solo la linea più veloce, ma anche quella più giusta. Se una piccola applicazione è pagata poco o necessità di essere sviluppata in poco tempo, i DataSet offrono quella velocità di sviluppo e semplicità di apprendimento che un'applicazione con domain model non offre.

Insomma tutto questo discorso per dire che per la voglia di sfighettare, si finisce spesso per costruire dei castelli quando basterebbe un appartamento da 50Mq. Ho visto un'applicazione scritta con domain model che gestisce solo 4/5 entità e richiede quindi almeno il doppio del codice rispetto al dataset. Per carità, l'applicazione è performante e bella da vedere, ma con i dataset la si faceva ancora in quasi metà tempo e senza grandi sforzi. La domanda interessante e che quando ho chiesto il perchè di questa scelta la risposta è stata: "i dataset sono il male, fare un tree tier aiuta a mantenere tutto pulito". Ineccepibile, se non fosse che per finire l'applicazione ci hanno messo 5 giorni in più in 2 persone.

Il consiglio è sempre lo stesso: fidatevi ancora dei dataset. Non hanno un campo di applicazione ampio, ma ce l'hanno e forse potrebbe essere proprio il vostro :D.

Stay tuned...

Tags: ADO.NET, Architettura, ORM, Pattern