Guy Barrette

Must read:

In my previous post about using LINQ to SQL in multi layered apps, I mentioned that this query was not optimal because I would need to build the POCOs from the objects returned by LINQ.  This would mean that objects would be created twice. 

Enterprise Library 4.0 March 2008 CTP was released yesterday.

My good friend Mario Cardinal just got one article published on MSDN.  It's called The Hidden Roles of Software Architects.  Check it out:
http://msdn.microsoft.com/en-us/library/cc431351.aspx

Team Suite Vnext will be FREE (but ad supported)

The P&P group recently published a set of WCF security related guidance.  You'll find on this CodePlex site a series of articles and videos.

In a previous post, I was explaining how surprised I was when I discovered that you lose LINQ to SQL change tracking features when working in a multi layered application or when you expose your business logic thru a service layer.  Thanks to everyone (especially Barry Gervin, Rocky Lhotka, Julie Lerman and Rick Strahl) who pointed me to articles, blog posts and code samples, I was able to make sense of all of this.

When coding apps that use LINQ to SQL, it is very important to check the SQL code generated to make sure that your queries are optimals.  To do this in a Console app, you simply use this code to output the query to the Console window: