LINQ

RockNUG Code Samples

Steve Michelotti — Thu, 12 Nov 2009 18:11:17 GMT

Thanks to everyone who attended my LINQ to SQL presentation at RockNUG last night. The code samples can be downloaded here: LINQ to SQL demo code.

As a point of clarification from last night’s Q&A session after the presentation regarding using LINQ to SQL with true POCO classes that do not even have [Column] mapping attributes, you can have a class like this:

   1:  public class Contact

   2:  {

   3:      public int ID;

   4:      public string FirstName { get; set; }

   5:      public string LastName { get; set; }

   6:      public string Title { get; set; }

   7:  }

If you’re using LINQ to SQL with stored procedures then this class (even without the [Column] attributes) will work just fine. The one catch is that you can *not* have the class itself decorated with the [Table] attribute which is what happened during the Q&A at the end of last night when someone asked me to show it work without attributes. I commented the [Column] attribute but did not also comment the [Table] attribute on the class level. If I had also commented out the [Table] attribute, however, then I would have run into this (different issue) because of the “extra” HomeAddress and BusinessAddress properties I added to the partial class (so bear that in mind if you test).

If you watch my blog in the next couple of days (or just subscribe to the rss feed) I’ll put up a post dedicated strictly to the various mapping options you have with LINQ to SQL and downloadable code examples of each since the only mapping I showed last night was the attributed-based mapping (e.g., mapping with attributes, mapping with XML, mapping differences with auto-generated SQL vs. stored proces, mapping with true POCO, etc.). Thanks!

LINQ to SQL Again??

Steve Michelotti — Wed, 11 Nov 2009 02:26:39 GMT

Tomorrow night I’ll be at RockNUG presenting LINQ to SQL. Yes, LINQ to SQL. Again. In the last 2 years I have presented LINQ to SQL numerous times at various user groups and code camps. Why do I keep getting asked to present LINQ to SQL? Isn’t LINQ to SQL dead? Answer: No. LINQ to SQL is not dead!

This confusion all started back in October 2008 with a seemingly innocuous post on the ADO.NET team blog discussing the emphasis that Microsoft was going to put into the Entity Framework going forward. The developer community was immediately up in arms about this post for a variety of reasons. First, many developers and companies had already made a significant investment in developing with LINQ to SQL. Secondly, LINQ to SQL is great so why de-emphasize it? Third, the Entity Framework has had its share of challenges getting acceptance in the development community (and I’m being charitable) so the thought of replacing something “good” with something “not as good” was not met with enthusiasm.

This led to a “clarification message” by the ADO.NET team a few days later in which they clearly state: “LINQ to SQL is not dead.” This post may have been a somewhat weak defense of LINQ to SQL but the message was clear nonetheless. We’ve also seen others from Microsoft strongly advocate LINQ to SQL. For example, in this MVC presentation at MIX 09, Scott Hanselman states he’s using LINQ to SQL in the demo “because it’s awesome and it’s not dead.” This all leads to a somewhat confusing state of affairs because we find ourselves relying on quotes from a respected Microsoft guru like Scott Hanselman and others in an attempt to translate Microsoft’s marketing approach for their latest data access strategy. After all, one of the longest running jokes is that the last thing Microsoft needs is yet another data access framework.

So how do we make this pragmatic decision for ourselves when deciding on a data access strategy/framework? Although there are numerous data access choices, the top three frameworks that are typically examined are: 1) LINQ to SQL, 2) NHibernate, and 3) the Entity Framework (EF).

The Entity Framework vNext that will be released after .NET 4.0 looks very promising. Model first, POCO code only, foreign key relationships, and more make me enthusiastic to give EF another run next year. But…that’s next year. If you’re starting development on a new application today, you might think twice.

NHibernate is a great framework. No dispute there. On it’s own it’s solid but then when you add features such as Fluent NHibernate and LINQ to NHibernate it’s becomes an extremely compelling choice. However, there is a steeper learning curve with NHibernate as compared to some other frameworks such as LINQ to SQL. Additionally, some organizations (unfortunately) have policies against using open source software which disqualifies NHibernate in those environments.

Then you’ve got trusty ol’ LINQ to SQL. In the last year, LINQ to SQL has continued to provide a solid data access choice. I strongly agree with the numerous points that Ian Cooper made in this post showing support for LINQ to SQL. In short, there are numerous reasons to learn and use LINQ to SQL. Among them:

LINQ to SQL is a stable release and has withstood the test for 2 years now. You don’t have to wait for the next release (like EF) – you can use it *now*.
Open source is not always an option (depending on your environment). LINQ to SQL is good to go here.
The skills you learn in LINQ to SQL are transferrable. In other words, if you learn LINQ to SQL now and later decide to switch to EF next year, you won’t be starting from scratch. Your knowledge will be transferrable.
There are also some cool OSS projects for LINQ to SQL such as Fluent LINQ to SQL.

And finally, LINQ to SQL is just flat out *good*. While it may not be perfect (no framework is) the designers of LINQ to SQL inside Microsoft really got far more right than wrong when creating LINQ to SQL. You can use it with a RAD designer or you can hand code all your classes. You can use it with C# attributes for mapping or external XML mapping files (or fluent mapping with OSS libraries). You can use it with auto-generated SQL or stored procedures. You can use it with POCO classes. You can use it in an N-Tier application without having to worry about serialization of your entities. It supports lazy loading or eager loading. The list goes on.

Having implemented numerous production applications with LINQ to SQL, I’m happy with it. But I’ll continue to learn more about it and other data access technologies as well as they come out.

If you’re in Rockville tomorrow night and have a desire to start learning LINQ to SQL, come on out!

Interesting LINQ Exercise

Steve Michelotti — Thu, 06 Aug 2009 20:24:21 GMT

A co-worker posed an interesting LINQ problem to me tonight so I figured I’d share. They had a collection of items and wanted an algorithm that would create a “collection of collections” where the first three items would be grouped together, second three items, on so on. For example, given a sequence like this: { “a”, “b”, “c”, “d”, “e”, “f”, “g”, “h” }, it would create a structure that contained 3 groups – the first element would be { “a”, “b”, “c” }, the second would be { “d”, “e”, “f” } and the third { “g”, “h” }. They already had an algorithm working fine but it was using a “brute force” approach and took about 15-20 lines of code. It “felt like” you could solve the same problem more elegantly with a LINQ solution and with less lines of code.

Here was my first solution:

   1:  var list = new List<string> { "a", "b", "c", "d", "e", "f", "g", "h" };

   2:  var results = new List<IEnumerable<string>>();

   3:  int numBlocks = list.Count % 3 == 0 ? list.Count / 3 : (list.Count / 3) + 1;

4:

   5:  for (int i = 0; i < numBlocks; i++)

   6:  {

   7:      results.Add(list.Skip(i * 3).Take(3));

   8:  }

First, I have to figure out the number of “blocks” or elements that the structure (the collection of collection) should have. Next, for each “block position” I leverage the LINQ Skip method in conjunction with the Take method (essentially like a paging operation). I was reasonably happy with the first solution but I kept feeling like I could do it with less lines of code and without the “for” loop. The problem with eliminating the for loop is that it was providing the outer loop and with LINQ you basically have to loop over something. After a little digging, I came across the Enumerable Range method which I hadn’t used before. This allowed me to solve the problem with 1 line of code:

   1:  var list = new List<string> { "a", "b", "c", "d", "e", "f", "g", "h" };

   2:  int numBlocks = list.Count % 3 == 0 ? list.Count / 3 : (list.Count / 3) + 1;

   3:  var results = Enumerable.Range(0, numBlocks).Select(i => list.Skip(i * 3).Take(3)).ToList();

Now we’ve got our collection of collection and can iterate over it:

   1:  foreach (var item in results)

   2:  {

   3:      foreach (var innerItem in item)

   4:      {

   5:          Console.WriteLine(innerItem);

   6:      }

   7:  }

While I was originally happy that I found a way to do it with 1 line of code, it’s not really a great solution because it’s just a little “too clever”. The for loop is going to be easier to understand for the poor developer that comes behind you and has to maintain your code. Also, the second solution is not as efficient because the Range method creates an array just so i can loop over it just so it can make it workable in LINQ. Bottom line, the first solution is better. But of course, if someone has an even better solution, please do not hesitate to share it in the comment section below.

To take it one step further, the LINQ SelectMany method will allow you to take the collection and collections and flatten it back out to the original single collection like this:

   1:  var flattened = results.SelectMany(x => x);

Richmond Code Camp – code samples

Steve Michelotti — Mon, 27 Apr 2009 14:23:57 GMT

For those of you who attended my presentation this past weekend at the Richmond Code Camp, you can download the code samples that I used during my presentation here.

Presentation at SOMD NUG – LINQ to SQL

Steve Michelotti — Mon, 09 Mar 2009 00:46:36 GMT

Tomorrow I’ll be giving a presentation at Southern Maryland .NET User Group on LINQ to SQL. Details of the event can be found here: http://www.communitymegaphone.com/ShowEvent.aspx?EventID=1022.

Custom C# 3.0 LINQ Max Extension Method

Steve Michelotti — Sat, 07 Feb 2009 02:48:58 GMT

The System.Core assembly in .NET 3.5 contains the main LINQ methods for dealing with objects such as the Max() extension method. Like many of the LINQ extension methods, the Max() method has many overloads that allow you to do things like this:

   1:  List<int> list = new List<int> { 1, 2, 17, 14, 21, 4 };

   2:  Console.WriteLine("Max: " + list.Max()); //<- "Max: 21"

This is all well and good but what if you need to do something a little more interesting? There are endless examples to think of but for the sake of this discussion, let’s say we have a directory and we want to find the latest/newest file in that directory. This isn’t very complicated and there are several ways to do it but one simple example might be this:

   1:  private string GetNewestFileInDirectory(string directory)

   2:  {

   3:      FileInfo latestFile = null;

   4:      foreach (var fileName in Directory.GetFiles(directory))

   5:      {

   6:          FileInfo currentFile = new FileInfo(fileName);

   7:          if (latestFile == null || currentFile.LastWriteTimeUtc > latestFile.LastWriteTimeUtc)

   8:          {

   9:              latestFile = currentFile;

  10:          }

  11:      }

  12:      return latestFile.Name;

  13:  }

For each file in the directory, we’re comparing the last write time and, if it’s greater than any other file timestamp, we store it in the temporary latestFile variable which will eventually be returned. But wouldn’t it be nicer to be able to use some sort of Max() method in this scenario where we’re considering that the “max” is based on the file’s timestamp? The FileInfo object doesn’t support any type of IComparable interface so that’s no help – and even if it did, it wouldn’t be much help because there’s no clear idea what it would be based on (e.g., file size? file name? file date?).

Let’s first see what we can do with the OOB Max() extension method. We could do something like this:

   1:  IEnumerable<FileInfo> fileList = Directory.GetFiles(directory).Select(f => new FileInfo(f));

   2:  var result = fileList.Max(f => f.LastAccessTimeUtc);

   3:  Console.WriteLine("Result is: " + result); //<- "Result is: Result is: 2/6/2009 8:10:54 PM"

Notice on line 1 I’m creating an IEnumerable<FileInfo> in a single line of code by leveraging the Select() extension method. The Directory.GetFiles() method just returns an array of strings, but I need a collection of the actual FileInfo objects so i can get at the file properties. Being able to do this on 1 line of code is much more succinct than having to instantiate and object, loop over the source, and continually call the Add() method of the collection.

Line 2 gives of the Max date which is, in fact, the latest date that we’re looking for. However, the problem is that I am trying to get the *actual* file that is the latest – just knowing the latest date by itself doesn’t do me a whole lot of good. What I really want to be able to do is the have a Max() method that will determine a “max” of any arbitrary object based on a simple expression that I can specify on-demand. In other words, I want to be able to write the code above but have the result be of type FileInfo so that I can get a reference to the actual FileInfo object that happens to have the maximum date in my collection. This can be done by writing your own customized extension method in roughly a dozen lines of code like this:

   1:  public static T Max<T, TCompare>(this IEnumerable<T> collection, Func<T, TCompare> func) where TCompare : IComparable<TCompare>

   2:  {

   3:      T maxItem = default(T);

   4:      TCompare maxValue = default(TCompare);

   5:      foreach (var item in collection)

   6:      {

   7:          TCompare temp = func(item);

   8:          if (maxItem == null || temp.CompareTo(maxValue) > 0)

   9:          {

  10:              maxValue = temp;

  11:              maxItem = item;

  12:          }

  13:      }

  14:      return maxItem;

  15:  }

This extension method has 2 generic type arguments. The first – T – in this case will be the FileInfo object. The second – TCompare – in this case will be the DateTime representing the result of the LastAccessTimeUtc property. In order to make this work correctly, you must have the “where TCompare : IComparable<TCompare>” generic constraint to ensure that whatever value specified implements IComparable. The rest of the algorithm is pretty similar conceptually to the original code.

Now you have a Max() extension method that can be generalized to limitless scenarios. Do you want to find the file with maximum size? Maximum name (alphabetically)? Maximum creation timestamp? Instead of a FileInfo object, you could use it against a collection of Person objects to find the person with the max age or max last name or max date of birth or max date hired, etc., etc. You could also do the same thing for other extension methods (e.g., Min(), etc.).

CMAP Code Camp Fall 2008 - Code Samples

Steve Michelotti — Mon, 27 Oct 2008 15:20:27 GMT

The code samples from my recent presentation at the Maryland CMAP code camp can be downloaded here:

N-Tiered LINQ to SQL

MVC and Unit Testing

LINQ to SQL - Return Scalar Value from a Stored Procedure

Steve Michelotti — Wed, 09 Jul 2008 02:55:06 GMT

One of the best things about LINQ to SQL is that is really does have solid support for stored procedures. However, it's not quite as friendly as dynamic LINQ to SQL with scalar values because you can't take advantage of anonymous types. Instead you must return an actual known type. Furthermore, this can't be a primitive so you can't return string or bool directly. You also can't use a class that doesn't have a default (parameterless) constructor so that also rules out nullable types like Nullable<bool>.

Consider a trival stored procedure that looks like this:

   1:  CREATE PROCEDURE [dbo].[GetFirstName]

   2:      @ID int

   3:  AS

   4:  BEGIN

   5:      SELECT FirstName

   6:      FROM   Contacts

   7:      WHERE  ContactID = @id

   8:  END

We just want to return a single scalar string here. So we have to create a dummy class that looks like this:

   1:  public class DummyClass

   2:  {

   3:      public string FirstName { get; set; }

   4:  }

Then our DataContext method can look like this:

   1:  [Function(Name = "dbo.GetFirstName")]

   2:  public ISingleResult<DummyClass> GetFirstName(int id)

   3:  {

   4:      IExecuteResult result = this.ExecuteMethodCall(this, (MethodInfo)MethodInfo.GetCurrentMethod(), id);

   5:      return (ISingleResult<DummyClass>)result.ReturnValue;

   6:  }

And add to that, we'll need an extra consuming method that defensively checks for an empty resultset:

   1:  public static string GetFirstName(int id)

   2:  {

   3:      using (MyDataContext dataContext = new MyDataContext())

   4:      {

   5:          var result = dataContext.GetFirstName(id).FirstOrDefault();

   6:          if (result != null)

   7:          {

   8:              return result.FirstName;

   9:          }

  10:          else

  11:          {

  12:              return null;

  13:          }

  14:      }

  15:  }

So all this works just fine but it seems like a lot of work to go through just to get a simple scalar value from a stored procedure. Not to mention that I don't want to have to go through this every single time I need a scalar value from a stored procedure in my app. Visual Studio will essentially generate the DummyClass for me but what if I'm hand-crafting my LINQ to SQL and am not currently using Visual Studio code generation? I don't want to have to go through that every time. So what can we do to make this slightly more developer-friendly?

First off, I want to avoid code duplication if at all possible. Not only if I return multiple scalars at different places in my app but also I'd prefer to avoid the duplication if these scalars are different data types (e.g., sometimes strings, sometimes Boolean, etc.). What we can do is to create a simple generic class called Scalar that looks like this:

   1:  public class Scalar<T>

   2:  {

   3:      public T Value { get; set; }

   4:  }

This means I can re-write my DataContext method like this:

   1:  [Function(Name = "dbo.GetFirstName")]

   2:  public ISingleResult<Scalar<string>> GetFirstName(int id)

   3:  {

   4:      IExecuteResult result = this.ExecuteMethodCall(this, (MethodInfo)MethodInfo.GetCurrentMethod(), id);

   5:      return (ISingleResult<Scalar<string>>)result.ReturnValue;

   6:  }

So since I'm using generics here, I never have to write another dummy class again - regardless of whether I've got a string or Boolean or whatever. I can always just re-use Scalar<T>.

Additionally, I had to write a consuming method that checked to see if DummyClass was null and if not return its value; otherwise return null. Now that I know I'm always going to use the Scalar class for all my scalar queries, I can move this into a re-usable extension method like this:

   1:  public static T GetScalar<T>(this Scalar<T> scalar)

   2:  {

   3:      if (scalar != null)

   4:      {

   5:          return scalar.Value;

   6:      }

   7:      else

   8:      {

   9:          return default(T);

  10:      }

  11:  }

So basically, all I've had to do is create that trivial Scalar<T> class and that 1 extension method which consisted of 1 IF statement and now anytime I need a scalar value from a stored procedure in my app, it becomes as trivial as writing my data context method with the re-usable Scalar<T> and this:

   1:  public static string GetFirstName(int id)

   2:  {

   3:      using (MyDataContext dataContext = new MyDataContext())

   4:      {

   5:          return dataContext.GetFirstName(id).FirstOrDefault().GetScalar();

   6:      }

   7:  }

Now, the one catch - the one thing to notice here is that the property name in Scalar<T> is "Value". That means that I'd have to change my stored procedure to alias my scalar data like this:

   1:  SELECT FirstName as Value

Although this is a downside, I believe it's well worth it in order to realize all the other benefits of quick implementation and avoiding duplicate and unnecessary code.

MVC Control Extensions - Automatically Set Control Names

Steve Michelotti — Mon, 23 Jun 2008 03:03:44 GMT

To set a normal text box in the MVC framework, the most typical code would look like this:

   1:  <%=Html.TextBox("FirstName", ViewData.Model.Contact.FirstName)%>

The key here is that you should set the name of the textbox to be the exact same name of the property name. If you do this, then it enables you to use extension methods such as the UpdateFrom() method to automatically populate your object from Request.Form parameters when you post to your controller action. This is all well and good but it is very easy to make a typo when typing the "FirstName" string for example. Wouldn't it be nice if this all just happened automatically?

Well, I found a very elegant solution to this last week when I was browsing the latest code of the Validation Framework on CodePlex. In the MVC quick start code for the Validation Framework, they provide extension methods for creating a "ValidatedTextbox", for example, that works with that validation framework which looks like this:

   1:  <%=Html.TextBoxValidated(() => ViewData.Model.Product.ProductName)%>

Not only is this solution elegant but I quickly realized that this could be easily generalized to so many other scenarios. Not just in the context of this validation framework but also for creating the most "normal" textbox scenario. By using this method, I can now re-write the first example like this:

   1:  <%=Html.TextBox(() => ViewData.Model.Contact.FirstName)%>

The resulting HTML that is produced will populate the textbox with the value from the FirstName property and it will also name the textbox "FirstName". So the HTML the gets rendered in the browser is:

   1:  <input type="text" name="FirstName" id="FirstName" value="Bill" />

It turns out that there is not many lines of code required to pull this off. The lambda expression is specified in the mark up and a Linq Expression is used for the method parameter. The complete code for the Textbox extension methods is as follows:

   1:  public static class ControlExtensions

   2:  {

   3:      public static string TextBox<T>(this HtmlHelper htmlHelper, Expression<Func<T>> expression)

   4:      {

   5:          return TextBox<T>(htmlHelper, expression, null);

   6:      }

7:

   8:      public static string TextBox<T>(this HtmlHelper htmlHelper, Expression<Func<T>> expression, object htmlAttributes)

   9:      {

  10:          MemberExpression memberExpression = expression.Body as MemberExpression;

  11:          if (memberExpression == null)

  12:          {

  13:              throw new ArgumentException("The specified expression is not a valid MemberExpression.", "expression");

  14:          }

15:

  16:          Func<T> compile = expression.Compile();

  17:          T value = compile.Invoke();

18:

  19:          return htmlHelper.TextBox(memberExpression.Member.Name, Convert.ToString(value), htmlAttributes);

  20:      }

  21:  }

Notice that since this is a MemberExpression where we're just getting a value from a property, we can simply use the Member.Name to get at the "FirstName" string. And then we can use the Compile() method of the Expression<TDelegate> class to get executable code in the form of a delegate that represents the lambda. Now that we have the Func<T> we can simply call Invoke() to get at the value of the FirstName property. Now that we have the name and value, we can pass it to the already existing TextBox extension methods.

This technique can really be generalized to any MVC control. It can also be generalized to create composite controls as they have done in the Validation Framework above. In my opinion, Microsoft should consider including this type of thing in the base MVC library. But if not, it's easy enough to add to your own MVC helper libraries.

LINQ - Cannot assign value to member XXX. It does not define a setter.

Steve Michelotti — Mon, 21 Apr 2008 02:27:39 GMT

One of the great things about LINQ to SQL is that you can add additional properties to the auto-generated classes via partial classes. However, occasionally people will run into this exception: System.InvalidOperationException: Cannot assign value to member 'XXX'. It does not define a setter. Why does this sometimes happen whereas other times the "extra" properties added via the partial class work perfectly? To answer this, let's take an example.

Suppose we have a contacts class (I've left out the gets/sets but assume properties in the code sample):

   1:  class Contact

   2:  {

   3:      public int ContactID;

   4:      public string FirstName;

   5:      public string LastName;

   6:  }

If you examine the auto-generated code that Visual Studio has produced for you, you'll notice that each property has been decorated with a [Column] attribute with the mapping to the appropriate database column and the class itself has been decorated with a [Table] attribute (I've left the attributes out for brevity).

Now suppose we want to add a new read-only property class FullName via a partial class like this:

   1:  partial class Contact

   2:  {

   3:      public string FullName

   4:      {

   5:          get

   6:          {

   7:              return FirstName + " " + LastName;

   8:          }

   9:      }

  10:  }

When you do this with in conjunction with the auto-generated code, everything works flawlessly.

   1:  var contacts = from c in dataContext.Contacts

   2:                 select c;

However, suppose that you want to access the data with a stored procedure called GetContacts by dragging that stored procedure to the data context design surface so that you can return the rows like this:

   1:  var contacts = dataContext.GetContacts();

In this case, what you will notice is that the designer creates a class called GetContactsResult that will be returned by the stored procedure call and is very similar to the Contact class above with each attribute decorated by the [Column] attribute to map to the appropriate database column. However, you will encounter the dreaded exception from above if you attempt to run the code with the following partial class:

   1:  partial class GetContactsResult

   2:  {

   3:      public string FullName

   4:      {

   5:          get

   6:          {

   7:              return FirstName + " " + LastName;

   8:          }

   9:      }

  10:  }

The important distinction is that in the first example, the designer decorated the Contact class with the [Table] attribute but in the second example the GetContactsResult class was not decorated with any attribute. The LINQ mapper will allow the extra read-only properties when the class is decorated with this [Table] attribute but not in the case where the attribute is absent. In this case, the mapper assumes that every property should be assigned. If there is a property that does not have a corresponding value in the query, it will still try to map it but it will send in null to the setter. If it does not have a setter, the exception above will be thrown. So the easiest solution is to simply decorate your partial classes with the Table attribute:

   1:  [Table]

   2:  partial class GetContactsResult

   3:  {

   4:      public string FullName

   5:      {

   6:          get

   7:          {

   8:              return FirstName + " " + LastName;

   9:          }

  10:      }

  11:  }

This is all well and good but keep in mind that, if you're running into situations like this, then perhaps using the auto-generated code is not the best option. You can manually handcraft your entity classes, use stored procedures, and still get plenty of power and benefit from LINQ in the column mappings, connection management, etc.