blogs.ASPItalia.com

Entity Framework e le performance con la Like

Stefano Mostarda — Tue, 09 Jun 2009 05:00:00 GMT

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

Stefano Mostarda — Tue, 02 Jun 2009 18:22:55 GMT

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

Stefano Mostarda — Mon, 18 May 2009 14:14:28 GMT

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

Stefano Mostarda — Thu, 07 May 2009 09:08:23 GMT

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

Stefano Mostarda — Sat, 11 Apr 2009 00:54:44 GMT

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

Stefano Mostarda — Sat, 21 Mar 2009 11:39:52 GMT

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

Stefano Mostarda — Mon, 16 Feb 2009 00:19:02 GMT

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

Stefano Mostarda — Sat, 31 Jan 2009 23:44:49 GMT

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

Stefano Mostarda — Sat, 27 Dec 2008 23:12:26 GMT

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

Stefano Mostarda — Tue, 09 Dec 2008 00:14:02 GMT

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

Stefano Mostarda — Fri, 28 Nov 2008 01:36:35 GMT

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

Stefano Mostarda — Wed, 29 Oct 2008 16:16:33 GMT

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

Stefano Mostarda — Wed, 29 Oct 2008 00:26:54 GMT

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

Stefano Mostarda — Mon, 27 Oct 2008 22:12:00 GMT

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?

Stefano Mostarda — Wed, 08 Oct 2008 20:04:38 GMT

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