<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:copyright="http://blogs.law.harvard.edu/tech/rss" xmlns:image="http://purl.org/rss/1.0/modules/image/">
    <channel>
        <title>LINQ</title>
        <link>http://blogs.ugidotnet.org/rgm/category/LINQ.aspx</link>
        <description>LINQ</description>
        <language>it-IT</language>
        <copyright>Gian Maria  Ricci</copyright>
        <generator>Subtext Version 2.6.0.0</generator>
        <item>
            <title>Lambda expression ed expression Tree</title>
            <link>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91152.aspx</link>
            <description>Nel precedente post ho mostrato come le lambda expression non sono assolutamente la stessa cosa che un delegate anonimo, la ragione è che il compilatore può tradurre una lambda expression in due modi molto differenti, il primo è semplice codice IL, proprio come un delegate anonimo, mentre il secondo è un Expression Tree. La IQueryable, che è l'interfaccia utilizzata da LINQ to SQL, accetta quindi nel where due cose distinte, un delegate di tipo Func&amp;lt;T, Boolean&amp;gt; oppure un Expression&amp;lt;Func&amp;lt;T, Boolean&amp;gt;&amp;gt;, il compilatore se presente preferisce sempre compilare con una Expression, ecco perchè LINQ2SQL è in grado di tradurre lo StartsWith() con un LIKE. La conferma come sempre è nell'IL generato.     Senza andare in dettaglio dalla lambda come potete vedere viene generata una Expression, differente è il caso del delegate   MEntre un delegate è un insieme di istruzioni IL da cui LINQ2SQL non può capire nulla, un expression tree è un oggetto complesso che al suo interno contiene tutte le informazioni sull'espressione e quindi permette a LINQ2SQL di capire cosa fare. alk. Technorati Tags: Linq to SQL,Expression Tree&lt;img src="http://blogs.ugidotnet.org/rgm/aggbug/91152.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Gian Maria  Ricci</dc:creator>
            <guid>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91152.aspx</guid>
            <pubDate>Tue, 12 Feb 2008 19:40:39 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91152.aspx#feedback</comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/rgm/comments/commentRss/91152.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/rgm/services/trackbacks/91152.aspx</trackback:ping>
        </item>
        <item>
            <title>Lambda expression sono solo syntactic Sugar?</title>
            <link>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91147.aspx</link>
            <description>Se qualcuno fosse convinto che le lambda expression sono solamente Syntactic Sugar per esprimere delegate anonimi potrà essere piacevolmente sorpreso da questo esempio in LINQ to SQL.  FirstTestDataContext context = new FirstTestDataContext();
 context.Log = Console.Out;

IEnumerable&amp;lt;Customer&amp;gt; custs = context.Customers
  .Where(C =&amp;gt; C.CustomerID.StartsWith("A"));
Console.WriteLine("Recuperati {0} oggetti Customer", custs.Count());
custs = context.Customers
.Where(delegate(Customer C) { return C.CustomerID.StartsWith("A"); });
Console.WriteLine("Recuperati {0} oggetti Customer", custs.Count());
 
In sostanza la prima query usa una lambda expression del tipo C =&amp;gt; C.CustomerID.StartsWith("A") e la seconda usa invece un delegate anonimo ma il codice è lo stesso. Osserviamo le query che vengono eseguite.

SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[Contact
itle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Cou
try], [t0].[Phone], [t0].[Fax]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[CustomerID] LIKE @p0
-- @p0: Input NVarChar (Size = 2; Prec = 0; Scale = 0) [A%]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21022.8

Recuperati 4 oggetti Customer
SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[Contact
itle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Cou
try], [t0].[Phone], [t0].[Fax]
FROM [dbo].[Customers] AS [t0]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21022.8
Come si può facilmente vedere la prima query che fa uso di lambda expression è molto efficiente perchè effettua direttamente una query con l'operatore LIKE, mentre la seconda recupera tutti gli oggetti customer dal database e poi li filtra con il delegate anonimo che è stato definito.
Lascio a voi il capire il perchè ;), ma questo basti per far capire che una lambda expression è qualcosa di più che "Syntactic Sugar".
Alk.
Technorati Tags: Lambda expression,LINQ to SQL&lt;img src="http://blogs.ugidotnet.org/rgm/aggbug/91147.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Gian Maria  Ricci</dc:creator>
            <guid>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91147.aspx</guid>
            <pubDate>Tue, 12 Feb 2008 14:44:47 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91147.aspx#feedback</comments>
            <slash:comments>3</slash:comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/rgm/comments/commentRss/91147.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/rgm/services/trackbacks/91147.aspx</trackback:ping>
        </item>
        <item>
            <title>Linq to Sql: Usare mapping file invece di attributi</title>
            <link>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91139.aspx</link>
            <description>Utilizzando il designer le vostre classi di accesso ai dati conterranno una serie di attributi necessari affinche Linq to Sql possa gestire le operazioni di persistenza dei dati. Se non amate gli attributi e preferite invece file di mapping xml la soluzione è utilizzare l'utility SqlMetal.exe fornita con visual studio, che vi permette di generare tutte le classi per un intero database. Ecco ad esempio come generare tutto il dominio per il database NorthWind sqlmetal /server:LAPTOPVM1SQLEXPRESS /database:northwind /map:NorthwindVer1.map /code:NorthwindVer1.cs  La sintassi è veramente facile, basta infatti specificare il nome del server, il database ed i nomi dei file da generare, uno (il punto map) contiene il mapping, mentre l'altro contiene il codice di tutte le classi. A questo punto basta includere il file .cs nella propria solution ed il gioco e chiamare il costruttore del DataContext passando manualmente il MappingSource   Northwind database = new Northwind(
   "server=LAPTOPVM1\\SQLEXPRESS;Database=Northwind;Integrated Security=SSPI",
   XmlMappingSource.FromUrl( "NorthwindVer1.map"));

 
La classe XmlMappingSource del namespace System.Linq.Data.Mapping permette infatti di generare l'oggetto MappingSource dal file di mapping, mentre nel DataContext generato con il designer si trova questa riga
private static System.Data.Linq.Mapping.MappingSource mappingSource = 
  new AttributeMappingSource();
 
che mostra chiaramente come in questo caso il MappingSource venga generato dagli attributi delle classi. Se si controllano le classi generate dal SQLMetal con l'opzione map attiva si nota che non sono più presenti gli attributi per il mapping.
Quale delle due soluzioni adottare è questione di gusto personale, ma per chi come me viene da NHibernate avere il file di mapping può essere interessante.
alk.
Technorati Tags: Linq to Sql,MappingSource&lt;img src="http://blogs.ugidotnet.org/rgm/aggbug/91139.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Gian Maria  Ricci</dc:creator>
            <guid>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91139.aspx</guid>
            <pubDate>Tue, 12 Feb 2008 10:13:31 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91139.aspx#feedback</comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/rgm/comments/commentRss/91139.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/rgm/services/trackbacks/91139.aspx</trackback:ping>
        </item>
        <item>
            <title>LINQ, le prime impressioni</title>
            <link>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91137.aspx</link>
            <description>Dopo avere giocato con Linq to entities e linq to xml (che trovo veramente comodo) ho iniziato a giocare con LINQ to SQL. Debbo dire che le prime impressioni sono decisamente buone, il prodotto è sicuramente molto valido e vale la pena guardarlo. La prima considerazione che mi è venuta guardando le classi generate è la trasparenza rispetto all'ORM, utilizzando le oramai straconosciute Customers e Orders del database Northwind, si nota infatti che la relazione è fatta utilizzando due classi speciali la EntityRef&amp;lt;T&amp;gt; e la EntitySet&amp;lt;T&amp;gt;. Queste due classi sono automaticamente utilizzate dal designer per gestire i riferimenti, mentre NHibernate ad esempio mappa normalmente i riferimenti e anche property o field di tipo IList.  D'altra parte LINQ to SQL non vuole essere un ORM a 360°, anche perchè supporta solamente SQL Server, per cui queste piccole intromissioni di classi proprietarie nel dominio non danno sicuramente fastidio. alk. Technorati Tags: LINQ to Sql,Persistence Ignorance&lt;img src="http://blogs.ugidotnet.org/rgm/aggbug/91137.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Gian Maria  Ricci</dc:creator>
            <guid>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91137.aspx</guid>
            <pubDate>Tue, 12 Feb 2008 09:16:14 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/rgm/archive/2008/02/12/91137.aspx#feedback</comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/rgm/comments/commentRss/91137.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/rgm/services/trackbacks/91137.aspx</trackback:ping>
        </item>
    </channel>
</rss>