SMWorld.NET - Il blog di Stefano Mostarda

ASP.NET 3.5 per tutti è un nuovo libro

Come già Daniele e Ricky hanno detto, il nostro nuovo libro è già in fase avanzata. Quello che tutti e due hanno detto è che questa non sarà una riedizione riveduta, corretta e ampliata per venire incontro alle novità di ASP.NET 3.5.
Oltre che a ribadire il concetto voglio anche portare altre prove: l'accesso ai dati ora consiste di 4 capitoli solo per dire come si può accedere, per come trattarli e visualizzarli ce ne sono altri 4. Quando si parla di LINQ To SQL, non si parla in termini di wizard e drag&drop delle tabelle, bensì si parla di come creare le classi a mano, di come si mappano verso il db, di come si gestisce la concorrenza, di come si invocano le stored procedure, insomma si affronta LINQ To SQL da un punto di vista dell'utilizzo reale e non da quello puramente demo dell'editor visuale. Dopo l'esperienza in MTV, posso garantire che chi continua ad usare LINQ To SQL a colpi di editor e Drag&Drop prima o poi la pagherà cara.
Nel capitolo della localizzazione ci saranno 3 pagine nuove dedicate alla costruzione di un provider custom per le risorse che attinge dal database. Nel capitolo sul deploy ci saranno distinzioni per ASP.NET 1.x, 2.0 e 3.5.
E poi signori
Insomma, abbiamo dato ascolto a tutte le cose buone come a tutte le critiche che ci sono arrivate ed alla fine abbiamo partorito un libro che nel panorama è l'unico ad affrontare linguaggi, svilluppo, sicurezza, e deploy a partire dalla 1.0 per finire alla 3.5.

E poi volete perdervi il gusto di leggere in prima assoluta un capitolo intero su ASP.NET MVC? ;)

Stay Tuned...

Tags: ASP.NET 3.5 per tutti

ASP.NET Ajax Roadmap

Ad inizio mese, Microsoft ha rilasciato un documento sulla roadmap che intende seguire per migliorare il proprio framework per AJAX. La versione 1.0 è ormai abbastanza stabile grazie alle correzioni fatte con la versione integrata nel framework 3.5 e quindi è ora di guardare avanti.
Chi ha seguito ASP.NET Ajax sin dai tempi in cui si chiamava Atlas sa bene che quello che è stato partorito da MS è un topolino di fronte alla quantità enorme di feature comprese nelle prime CTP. Questo è andato a vantaggio di una maggior stabilità ma a discapito di una serie di funzionalità assolutamente necessarie per sviluppare una vera applicazione AJAX. Infatti, la parte client del framework è estremamente scarna in quanto contiene fondamentalmente solo uno strato di astrazione per rendere le API Cross-Browser e qualche funzione.
Adesso le cose cambiano. L'intenzione è quella di reintrodurre il meccanismo di templating e di databinding one-way e two-way in maniera però completamente diversa rispetto a quanto fatto vedere nelle prime CTP dove il tutto era troppo complicato e lento. Inoltre hanno l'intenzione di creare un motore di interrogazione per il DOM molto simile a JQuery.
Insomma, le premesse sono più che buone perchè quello che vogliono fare è rendere ASP.NET Ajax un framework serio e se mantengon oquello che dicono, credo che dovrò rivedere un pò le mie idee e soprattutto il modo in cui ho scritto alcune applicazioni. :)

Stay Tuned...

Tags: AJAX, ASP.NET 2.0, ASP.NET AJAX

Entity Framework ed il mapping

Ormai utilizzo Entity Framework da quasi un anno, e presso un cliente lo sto facendo adottare perchè questo vuole utilizzare solo tecnlogia proprietaria Microsoft. LINQ To SQL non è abbastanza potente quindi la scelta è ovvia.
Quando mi ritrovo a spiegare Entity Framework l'argomento più complicato non è l'Object Tracking o il supporto per scenari su più layer, logici o fisici che siano, o l'EntitySql; l'argomento più complesso è il Mapping. Senza dubbio il mapping in un ORM è il concetto più semplice da capire, ma con Entity Framework nonostante il facile compito si è riusciti a colpire la classica mosca col bazzuca, ma tant'è e così ce lo teniamo.
All'inizio, ho utilizzato il designer in ctp ma la mia voglia di imparare era tale che dopo pochi giorni sono passato direttamente a fare le cose a manina. Passare da dei tool che ti creano tuto da video a scrivere un xml a mano è pura follia, ma ormai non riesco a farne a meno, il designer proprio non lo so usare :)
Alla lunga però paga perchè scrivere il mapping a mano e verificare gli errori fa capire quali sono le necessità di Entity Framework e fa più o meno intuire come lavora il motore.
Ai Community Days, stavo impazzendo con Roberto perchè lui non riusciva a riprodurre l'ereditarietà Table Per Type e io invece.... nemmeno :). Lui utilizzava il tool e io non sapevo nemmeno cosa stesse facendo quindi mi sono buttato sul file XML. Dopo un vago girare a vuoto, mi sono accorto che nel file SSDL (quello della descrizione dello storage e occhio ho detto storage e non database) non c'era la descrizione dell'associazione tra la tabella primaria e quella secondaria con i campi aggiuntivi. Dimenticando di descrivere quest'associazione, Entity Framework non sapeva come mettere in join le tabelle e generava un'eccezione. Qui si scatena un putiferio; le eccezioni di mapping sono la cosa più oscura del mondo; per la semplice mancanza dell'associazione siamo finiti per avere un messaggio di perdita di dati dovuta alla non conoscenza del lato C della tabella padre. Pensandoci bene, uno particolarmente malato forse potrebbe anche arrivare a capire l'errore ma non sono molto fiducioso.

Insomma, tutto questo per dire una cosa: fatevi i file XML a mano. Probabilmente la prima settimana riuscirete a mappare solo 4 tabelle sulle classi analoghe sputando anche svariato sangue, ma state tranquilli che lo sforzo verrà ampiamente ripagato dopo poco tempo. Personalmente adoro questa piccola applicazione che è una miniera di informazioni per il mapping.

Stay Tuned...

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

Community Days 2008: il giorno dopo

A distanza di ormai 15 ore dalla chiusura dei fantastici Community Days 2008 mi ritrovo a scrivere le mie impressioni.

Innanzitutto l'agenda. Ricordo nel lontano mese di Maggio davanti ad una pizza 4 loschi individui: io, Daniele, Andrea ed Ugo. Lo scopo della cena era quello di mantenere la concentrazione per più di 20 minuti consecutivi per stabilire le track. A fine serata convinsero le idee di: Andrea per la track Underground, mia e di Daniele per server Infrastructure+Application Development, tutti SP1+Tutorial. Direi che nel complesso l'impostazione generale è venuta piuttosto bene e dalla risposta del pubblico direi che almeno per stavolta possiamo autodarci una pacca sulla spalla :D.

Passiamo alle sessioni. Innanzitutto spaziale quella di Marco e Alessio; non l'ho vista ma ci fosse stata una sola persona di quelle presenti che mi ha detto il contrario (ed erano in tanti). Alla prima esperienza si sono subito fatti trovare pronti. Che dire: eccezionali. Un grande complimento va a Cristian che, grazie alla sessione che Daniele gli ha ammollato, è riuscito ad avere un bellissimo feedback :D. Non parliamo della sua in 3D dove ha fatto iperfaville (trigonometria applicata a parte). Ricky semplicemente fantastico, nono ho seguito nemmeno la sua di sessione, ma da quando è finita a quando la gente l'ha lasciato andare sono passati quasi 40 minuti e questo è indice di alto gradimento. Poi ci sono io con le mie 3 sessioni. Quella su ASP.NET presa in ereditarietà da Daniele è stata iperdivertente quanto faticosa, parlare dei DynamicData e di Routing per 90 minuti è stata una cosa faticosa ma che ha prodotto ottimi risultati. A quella sulla sicurezza con WCF eravamo pochi intimi ma quei pochi mi sembra abbiano apprezzato. Per quella sulle applicazioni web-service based devo dire che Ugo mi ha dato soddisfazione. Alla sua prima esperienza era talmente teso che all'inizio non riusciva nemmeno ad alzare la testa ma una volta che si è sciolto ha parlato di Dependency Injection come in pochi sanno fare. Inoltre, farla vedere la DI applicata alla pipeline di WCF per risparmiare centinaia di righe di codice ripetitivo, dire che queste cose le abbiamo sviluppate noi e che sono in produzione sul sito di MTV da un gusto particolare :). La sessione sicuramente meglio riuscita IMHO. E poi Ugo è maschio si sa :).

Non ho seguito quasi nessuna sessione, a parte un pezzo di quella su Entity Framework e un pezzo sulle architetture, ma ho sentito parlare la gente ed ho capito che in generale sono tutti rimasti estremamente soddisfatti di qualunque cosa abbiano visto.

Infine una menzione per chi è rimasto fuori: a Mauro per il Context (lui sa perchè), a Roberto per la discussione (che spero andrà avanti) su Entity Framework, ad Alessandro per il suo caro termine "picchiare", Raf, Gab, Pietro, Mighell, Lica, Lorenzo alle Bahamas e a tutti coloro che non ho nominato per mancanza di memoria.

WCF LINQ To SQL il SP1 e la serializzazione

Oggi stavo facendo una prova con LINQ To SQL e ad un certo punto ho notato che il codice delle classi autogenerato da Visual Studio non inserisce più gli attributi DataMember e DataContract per la serializzazione WCF.
A questo punto ho creato un servizio WCF ed ho esposto la classe e questa veniva serializzata correttamente. Confesso che lo sconforto mi è preso un pochino perchè non capivo cosa stesse succedendo. Armato di reflector vado ad esaminare l'assembly e scopro che gli attributi in realtà sono lì.
Andando più a fondo, ho scoperto che una dele nuove caratteristiche del SP1 è che WCF non ha più bisogno degli attributi di mapping poichè questi vengono automaticamente iniettati dal compilatore sul'interfaccia pubblica di una classe. Ovviamente, si può modificare il tutto inserendo a mano l'attributo DataContract sulla classe e DataMember sulle sole proprietà da esporre con WCF.

Buono a sapersi.... ma uno dei cardini di WCF non era che l'esposizione delle proprietà doveva essere esplicitata dallo sviluppatore?

Stay Tuned...

Tags: .NET Framework, .NET Framework 3.0, .NET Framework 3.5, LINQ, LINQ to SQL, Windows Communication Foundation

Una noisa limitazione di LINQ To SQL

Lo sappiamo tutti: LINQ To SQL è stato concepito appositamente con delle limitazioni. Mapping 1:1 con il database (con conseguente obbligatorietà di avere una classe di correlazione per il mapping many-to-many), ereditarietà che non supporta tutti e 3 i modelli, classi apposite per gestire riferimenti a entità (EntitySet e EntityRef), ecc ecc.

Dal mio punto di vista, la prima e la seconda limitazione sono accettabili per un tool che nasce con lo scopo di gestire progetti semplici. La terza, tuttavia, proprio non la accetto. Per motivi di Lazy Loading e riferimenti al DataContext, EntitySet non è serializzabile. Questo significa che se in un servizio WCF proviamo a esporre un'entità Fattura che ha una EntitySet di oggetti DettaglioFatttura, riceviamo una bella eccezione di serializzazione a runtime.

Il workaround è presto trovato, basta evitare di mettere il DataMember sulla proprietà in questione e farne una copia che espone una lista generica di oggetti DettaglioFattura, e non un EntitySet, preoccupandosi di valorizzarla correttamente. Facendo così i problemi si risolvono, ma il disappunto rimane per una cosa che poteva essere fatta meglio e non costringerci al workaround.

P.S. A nessun Ughetto è stato fatto male durante la stesura di questo post, anzi, è lui che ha fatto del male a me :D

Stay Tuned...

Tags: .NET Framework 3.0, LINQ to SQL, Windows Communication Foundation, .NET Framework 3.5, LINQ, Database

Il nuovo speciale in arrivo su LINQ

Se è vero che alla follia non c'è mai fine allora non so veramente dove andremo a finire. Non bastavano 2 siti nuovi di zecca dedicati alle più grandi novità di casa Microsoft degli ultimi anni? Non bastava uno speciale mastodontico su tutto il framework 3.5? Non bastava un Community After Hour durante il lancio di Visual Studio? Non bastavano articoli, script, focuson, blog?
Beh, la risposta è: NO.

Dalla prossima settimana arricchiremo la nostra offerta di contenuti aprendo le porte ad un nuovo format: lo screencast. Come è ormai nostra usanza, affronteremo questa nuova sfida con uno speciale. La sezione media esiste già da diverso tempo, ma contiene registrazioni di sessioni che abbiamo tenuto per le varie conferenze. Questa volta abbiamo deciso di fare qualcosa di apposito.

6 screencast su LINQ e tutti i suoi flavour dalla durata decisamente breve (10-15 minuti) e dal taglio esclusivamente pratico. Non posso nascondere una punta di orgoglio nel dire queste cose perchè il primo sito del network ad affrontare questa nuova avventura è LINQItalia.

Come sempre, anche se gli screencast li faccio io, non sono di certo il solo artefice di questo speciale; Alessio ha affrontato la parte Player (In Siverlight) mentre Daniele ha come sempre coordinato le attività.

Insomma, ad Aprile niente dolce dormire, ma tanti nuovi contenuti per la community :). E poi chissà, se le cose vanno bene, mica ci si deve fermare qui ;)

Stay tuned...

Tags: .NET Framework 3.5, LINQ, LINQ to SQL, LINQ to XML, XML

LINQItalia.com e SilverlightItalia.com sono online

In questi minuti i 2 nuovi pargoli del network stanno emettendo i loro primi vagiti. Per me che sarò anche Content Manager di LINQItalia.com il momento è particolarissimo.

Personalmente provo un misto tra gioia, orgoglio e terrore.
Gioa perchè il fatto di voler affrontare questa nuova sfida significa che sento di potercela fare.
Orgoglio perchè essere Content Manager di un sito mi fa sentire apprezzato per quello che ho fatto fino ad adesso.
Terrore perchè gestire un sito è una cosa che non ho mai fatto e nonostante le rassicurazioni dei compagni di viaggio sono ancora sotto terrorizzato :).

Per quanto riguarda LINQItalia.com le cose in cantiere sono tante; da qui alla fine della stagione ci saranno contenuti come articoli e script ma stiamo pensando anche a delle succulente novità che siamo sicuri faranno felici molti di voi. :)

Il primo passo è fatto, non mi rimane che fare un grande in bocca al lupo ad Alessio e Marco che come me si sono imbarcati in questa avventura (loro gestiscono SilverlightItalia.com n.d.r) ad augurare un felice LINQ a tutti :).

Stay Tuned...

Tags: .NET Framework 3.5, LINQ, Silverlight, XAML

FWC il giorno dopo

A distanza di una pizza ed una bella dormita dalla fine della conferenza di ieri a L'Aquila è arrivato il momento di tirare le somme di una giornata davvero bella.
In realtà la nostra esperienza parte da lunedì sera quando insieme agli organizzatori della conferenza siamo andati a cena fuori, sparandoci almeno 2 etti e mezzo di carbonara a testa ed una grigliata mista di carne che ci ha tenuti tutta la notte attaccati alla bottiglia :).

Poi la conferenza; per me è stato emozionante l'annuncio live di Daniele della nascita dei due nuovi pargoli (in articolare per LINQItalia visto che lo gestisco io).

Poi si parte con Pietro che ha mostrato come IIS7 sia uno dei prodotti più belli sfornati da Microsoft negli ultimi decenni. La pipeline integrata con ASP.NET è un autentico gioiello.

Dopo è il mio turno, anzi il turno di LINQ To ... appena salito sul palco una delle prime domande che ho fatto al pubblico è stata "Quanti di voi credono che LINQ sia solo un motore per lavorare con il database?". Come era facile aspettarsi molti hanno alzato la mano perchè ciò che è permeato durante la beta e anche adesso è solo LINQ To SQL. Mi ero preparato a questa evenienza e quindi avevo già impostato una sessione che non parlasse di LINQ To SQL ma di LINQ To Objects, LINQ To XML, LINQ To DataSet e solo alla fine di LINQ To SQL. La risposta del pubblico è stata fantastica; decine di domande, curiosità e apprezzamenti per LINQ in tutti i suoi Flavours con un'ovvia preponderanza per LINQ To SQL.

Dopo pranzo comincia Daniele, che dopo aver markettato per 40 minuti sulle nuove feature di Visual Studio 2008 ha finalmente cominciato a scrivere il codice che tutti si aspettavano. La sessione scorre via liscia, tra un bug e l'altro delle CTP Extension in Visual Studio, fino al momento delle domande dove la gente continuava a chiedere di LINQ più che di ASP.NET a tal punto che siamo dovuti intervenire io e Pietro per rispondere.

Infine è il turno di Cristian (Silverlight) che snocciola animazioni con xaml, come se fossero noccioline (cubi che girano, si allargano, immagini che ruotano bottoni che interagiscono con javacsript etc etc.). Certo quando ha parlato di IChar, IBottle, TuoTubo e ScatolaDiSapone forse è andato troppo oltre, ma proprio per questo gli vogliamo bene :). Nel complesso come parla lui di queste cose credo in Italia non ci sia veramente nessuno.

Gli utlimi byte li dedico agli organizzatori Daniele e Stefano che hanno fatto davver un gran bel lavoro perchè organizzare una conferenza non è mai facile e ci sono molte più cose da fare di quello che si immagini.

Gli ultimissimi byte vanno invece alle persone che ad ogni conferenza affrontano il caldo, il freddo, il maltempo e qualunque catastrofe naturale pur di esserci. Domande, partecipazione, battute, curiosità e voglia di apprendere; questo è stato grazie a voi un evento ancora più bello.

I byte finali vanno come saluto al mini-speaker Alessio Bochicchio che si destreggiava abilmente nella tombolata delle estrazioni dei premi :)

Stay Tuned...

Tags: .NET Framework, .NET Framework 3.5, 10annidi, ASP.NET 3.5, ASPItalia.com, IIS, LINQ, Silverlight, Visual Studio, Windows Presentation Foundation, Windows Server, XAML

LINQ To SQL ed il Fetching

Partiamo da un concetto: LINQ To SQL è fantastico. E' un ORM For Dummies nel senso che ha una facilità di apprendimento ed utilizzo semplicemente impressionante ed una serie di feature comunque sufficienti per poterci basare un'applicazione. Molti definiscono LINQ To SQL un ORM For Dummies perchè limitato a SQL Server, non Persistence Ignorant e con feature molto ridotte rispetto a giganti come NHibernate; tuttavia, io credo sia solo invidia per l'intellisense in Visual Studio ed il Compile Time Checking delle query :).

Eppure, nonostante tutto, ci sono quelle cose che sembrano punture di zanzare ma in realtà sono pugnalate al cuore. La principale è: le politiche di fetching si possono impostare solo sul DataContext ed una sola volta. All'inizio, LINQ To SQL permetteva di decidere a livello di query come tirare giù le associazioni dal db, se in eager o in lazy loading. Per default, le entità associate venivano caricate in lazy con la possibilità di cambiare, tramite LoadOptions, in eager. Questa possibilità, in realtà, rappresentava un problema per il team di sviluppo che doveva gestire una serie di casistiche di caricamento eccessive, quindi è stata tagliata la testa al toro e si è spostato il tutto sul DataContext invece che sulla singola query.

Qui saltano fuori i doloretti. Se io volessi tirarmi giù una fattura ed i suoi dettagli, e poi un cliente ed i suoi ordini (il tutto in eager loading), e volessi utilizzare lo stesso DataContext l'unica via è impostare a priori le politiche di fetching cioè quando si crea il DataContext. Infatti, se lo facessi nel metodo che esegue la query, mi ritroverei con una bella eccezione quando recupero i clienti perchè il fetching è stato impostato già una volta nel metodo che ritrova la fattura.

Come detto, l'unica via è impostare in fase di creazione del DataContext tutte le politiche di fetching che questo dovrà seguire. Ovviamente la cosa va fatta contesualizzata; se la si facesse generalizzata, si caricherebbero sempre gli ordini di un cliente anche se si vuole recuperare solo il suo dettaglio. Per fare questo, è la pagina stessa che deve inviare al DAL le informazioni su come caricare le cose che poi verrano cercate. Questo implica che se dobbiamo modificare una politica di fetching dobbiamo farlo in tutte le pagine coinvolte.

Alla fine, dopo averci ravanato un pò sopra, sono arrivato alla mia idea definitiva di come utilizzare LINQ To SQL in un 3 tier con tutti i compromessi che ne derivano, ma sarà argomento di un post entro le 48 ore :)

Stay Tuned...

Tags: .NET Framework 3.5, LINQ, ORM

LINQ To SQL ed un problema di null

L'altro giorno mi stavo dilettando scrivendo una query LINQ per estrarre il prossimo numero di fattura per l'anno in corso. La query è tutto sommato semplice:

(from c in MyDataContext.Invoice
where c.IssueDate.Year == DateTime.Now.Year
select c.Number).Max()

Ora il problema scatta per la prima fattura dell'anno. Infatti, il risultato della query da db è null poichè non esiste ancora una fattura per l'anno in corso. La conseguenza è che LINQ cerca di mettere null in un int (poichè il campo Number è int) ed il tutto scoppia. La soluzione è semplice, basta castare il campo Number a nullable ed usare GetValueOrDefault per avere il valore di default che desideriamo in caso di null.

(from c in MyDataContext.Invoice
where c.IssueDate.Year == DateTime.Now.Year
select (int?)c.Number).Max().GetValueOrDefault(1)

Stay tuned...

Tags: .NET Framework 3.5, LINQ

Future Web Conference e .NET 3.5

Il 2008 è un anno che promette bene. Non bastano le promesse per la 2.0 di Silverlight, il lancio di Visual Studio 2008, SqlServer 2008, Windows Server 2008 il summit, la PDC, il MIX.

Per iniziare nel migliore dei modi e non farci mancare assolutamente nulla, abbiamo organizzato subito un bell'evento che, guarda caso, è rivolto al futuro più presente che ci sia. Infatti, il .NET Framework 3.5 e Visual Studio 2008 sono già stati rilasciati anche se il lancio ancora non c'è ancora stato. Posso già dire, con cognizione di causa, che alcuni clienti lo stanno già utilizzando per applicazioni in produzione (in primis il nostro sito).

Tutto questo per dire che l'evento a L'Aquila verterà sul .NET Framework 3.5 e quindi LINQ, Silverlight, ASP.NET 3.5 con una puntatina ad IIS. Inutile dire che sarà un'occasione per toccare con mano da subito le novità che ci aspettano, conoscerci di persona, e magari farci anche una bella mangiata tutti insieme (che non guasta mai :D) .

Personalmente mi occuperò di LINQ ed in modo particolare di LINQ To SQL cercando per quanto possibile di mostrare come LINQ può ridurre, drasticamente ed in maniera molto robusta e patternizzata, il codice del'90% delle applicazioni che sono attualmente in giro.

Nei prossimi giorni bloggherò un pò su quello che ci aspetta, giusto per stuzzicare un pò la vostra voglia di partecipare (sia mai che convinco qualcuno a venire)

Stay Tuned...

Tags: .NET Framework, .NET Framework 3.5, ASP.NET 3.5, IIS, LINQ, Silverlight, Silverlight 2.0, Windows Server, XAML, Visual Studio

LINQ To SQL vs NHibernate

Durante il mio viaggio nel mondo degli ORM mi sto soffermando molto su LINQ To SQL e NHibernate e come strutturare un 3Tier con questi. NHibernate è tutt'altra bestia e come sappiamo tutti è infinitamente più potente rispetto a LINQ To SQL e rende lo sviluppo con Persistence Ignorance assolutamente semplice. Tuttavia, ci sono comunque delle cose che mi fanno preferire LINQ To SQL per molti scenari.

E-Commerce: un tipo di applicazione come questa necessita di query che vanno per il 95% a consultare il database e per il restante 5% a scrivere. Applicazioni del genere hanno un modello ad oggetti abbastanza semplice e non hanno bisogno di meccanismi di persistenza troppo complessi perchè spesso gli oggetti hanno un mapping 1:1 con le tabelle del db. In questi casi non scomoderei mai NHibernate perchè sarebbe come sparare con un cannone per colpire una zanzara, mentre LINQ To SQL esprime il suo massimo potenziale in questi scenari.

Community: una community ha forum, blog, articoli, script tutti riconducibili ad un modello a oggetti anche qui estremamente semplice. Ad esempio, un articolo ed un post sul forum o su un blog hanno molto in comune (Autore, data, soggetto, testo, ecc). Anche qui, vale lo stesso discorso per la categoria precedente meglio LINQ To SQL.

Gestionali: qui il discorso si complica; con questi tipi di applicazione e con l'avvento di ajax capita spesso che si possano creare maschere con tantissimi dati dentro ed un commit finale che deve persistere grafi complessi. In questo caso la scelta tra uno o l'altro dipende da quanto il mapping 1:1 imposto da LINQ To SQL sia accettabile. Io opterei per NHibernate quando la cosa è troppo gravosa mentre in altri casi LINQ To SQL è un'ottima scelta.

Le considerazioni che ho fatto, ovviamente, tengono conto solo delle problematiche relative al mapping senza tenere in considerazione prestazioni, tipo di database, supporto degli editor, ed altro ancora.

Detto questo, viva LINQ To SQL viva NHibernate, viva il mapping manuale, viva le applicazioni che funzionano :D.

Stay tuned...

Tags: .NET Framework 3.5, Architettura, LINQ, NHibernate, ORM

NHibernate entra nel mio mondo

Non sono mai stato un grande fan di NHibernate e degli ORM in generale. Questo perchè ho l'impressione a pelle di perdere il potere sulla base dati e sul lavoro anche se poi so cche non è così.
Ora comincio a convertirmi. E' da idioti non ammettere che NHibernate sia importante per gran parte delle applicazioni odierne. Prima con LINQ To SQL, poi con ADO.NET EF ed ora con NHibernate mi rendo conto che il futuro è quello: ORM per il lavoro spicciolo di persistenza e integrazione custom per le operazioni batch o query speciali o altro ancora. C'è ancora una sacca di applicazioni che non traggono benefici, o ne traggono pochi, da NHibernate quindi bisogna comunque essere in grado di scriversi a mano il DAL delle applicazioni.
Detto questo non ho intenzione di inaugurare una sezione su NHibernate perchè penso che ci sia già parecchio materiale in giro e finirei per dire cose già dette e stradette da altri; quello che voglio dire è semplicemente che NHibernate da ieri ha un nuovo utilizzatore.

Stay Tuned...

Tags: NHibernate, ORM

Linq non è solo interazione con il Database

Sto usando massivamente LINQ in questo periodo, vuoi per preparare gli script per la sezione, vuoi perchè lo trovo estremamente affascinante, vuoi perchè a volte non ho niente di meglio da fare che smanettarci un pochino :).

E' ovvio che la grande novità che LINQ introduce è l'interazione tipizzata verso il database, vedi Linq to Sql ed il più ampio ADO.NET EF. Però ridurre LINQ solamente a questi campi sarebbe estremamente riduttivo. Infatti la sua potenza di elaborazione di oggetti in memoria è molto elevata (INQ To Objects). Fare query su liste, di oggetti, fondere n liste, ricercare insiemi, cercare parole all'inteno di frasi, insomma tutte quelle operazioni che fino ad adesso si sono espresse tramite codice si possono esprimere con un linguaggio molto simile ad una query. La vera potenza di Linq secondo me sta li.

Questo anche perchè trovo LINQ To Sql ancora molto acerbo (anche se super-perfetto per certi scenari), e ADO.NET EF è ancora lontano. Questo è il principale motivo che mi ha spinto ad organizzare la rubrica nel mondo in cui lo è adesso, ovvero una approfondita introduzione alla potenza della sintassi LINQ, senza puntare dritti al database. Io credo che una volta vista la maggior parte della sintassi e analizzato come fare query su oggetti e su file xml fnalmente si smetterà di polemizzare sulle limitazioni di LINQ verso i database e si apprezzerà finalmente la sua eccezionale potenza in tutti gli altri campi (ovverò il restante 90% dell'applicazione).

Stay Tuned...

Tags: .NET Framework 3.5, LINQ