Crad's .NET Blog

Quando scriviamo interrogazioni con LINQ, non dobbiamo mai perdere di vista ciò che in realtà esse sono, ossia alberi di funzioni e Lambda expression. Per questa ragione, un qualcosa come 1 var customers = db.Customers 2 .Where(c => c.CompanyName.StartsWith("A")) 3 .Join(db.Orders, 4 (c => c.CustomerID), 5 ...

Ieri ne ho parlato tessendone le lodi, perchè tutto sommato reputo LINQ un buon ORM, che forse però soffre di qualche peccato di gioventù. Visto che per natura sono un po' rompiballe e non mi accontento mai, infatti, vi vengo a raccontare un paio di aspetti (anzi tre) che mi sono subito saltati all'occhio e che non mi sconfinferano granché. Punto 1 Le entity (generate da un'ottimo designer, poco da dire) non sono serializzabili a causa delle dipendenze da EntitySet e EntityRef. Si tratta di una brutta limitazione, che non mi permette di esporle direttamente MBV con Remoting, tanto per fare un...

In questi giorni sto spulciando un pochino questo ORM e fino ad ora le mie impressioni sono senz'altro positive; LINQ to SQL, a mio modo di vedere, è un prodotto che ha dalla sua un'estrema produttività, almeno per un paio di ragioni: Intanto l'ottima integrazione con il designer di Visual Studio, che si interfaccia con la base dati e ci consente di modellare il dominio applicativo veramente in brevissimo tempo: la comodità del designer del DataSet applicata ad un Domain Model + ORM, praticamente il mio sogno La semplicità e la naturalezza di LINQ come linguaggio di...

Il più grande punto di forza di Microsoft LINQ è senza dubbio quel syntactic sugar che ci permette di scrivere query simil-SQL, strong typed e direttamente all'interno del codice C# (o VB.NET che sia). Supponiamo di voler recuperare, dagli assembly in memoria, l'elenco delle classi che iniziano per una data lettera. In C# 3.0 posso scrivere qualcosa tipo 1: var types = 2: from assembly in AppDomain.CurrentDomain.GetAssemblies() 3: from type in assembly.GetTypes() 4: ...

C# 3.0 permette una notazione compatta per le proprietà che si limitano semplicemente a wrappare un corrispondente field: 1: public string Descrizione { get; set; } Sulle prime mi è sembrata un'innovazione piuttosto utile, se non altro per le entity di dominio, che notoriamente non hanno logica e che risultano essere parecchio più veloci da scrivere e leggibili. Così utili che ho anche realizzato un accessor per farle supportare da NHibernate (lo trovate qui). Poi ho iniziato a sperimentare un po' e... beh... mi convincono fino ad un certo punto. Perchè? Beh, ovviamente devono avere...