.NET 3.5

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 ComponentController vs. ViewUserControl

Steve Michelotti — Mon, 07 Jul 2008 01:29:25 GMT

At some point when creating a web app, you're going to want some reusable UI components. This might be because you want the same visual UI snippet repeated more than once on a single page or it might be because you want to use the same component on multiple pages. In a traditional ASP.NET web app, typically you would use a User Control for this type of thing. In MVC you still have the option of using a User Control but you also have the option of rendering your UI snippet with a ComponentController. So the question is, when do you use which? There are pros and cons to each.

The most common scenario for a user control is that you pass in the Model from the containing view page. For example, consider a AddressEditor user control that you use multiple times on a page to edit Contacts - once for Home address and once for Work address. It might look like this:

<%=Html.RenderUserControl("~/Views/Home/AddressEditor.ascx", new AddressViewData(ViewData.Model.Contact.HomeAddress))%>

This is fine for those simple cases but what happens when you want your user control to have its own self contained logic? For example, what if you're buildng a portal or a portal-like website where you want to have several self-contained "widgets" in your page. You don't want the parent controller having to keep track of the models for 10 different widgets and then have to pass them in to each one. A good answer to this is to use a ComponentController rather than a View user control. A ComponentController can render its own views and the containing page can just look like this:

   1:  <div id="firstWidget" class="widget">

   2:      <%=Html.RenderComponent<MvcWidget.Controllers.WidgetCompController>(c => c.Widget1()) %>

   3:  </div>

In this case, the controller class basically looks like most any other controller class with the exception that it inherits from ComponentController:

   1:  public class WidgetCompController : ComponentController

   2:  {

   3:      public void Widget1()

   4:      {

   5:          IWidgetManager widgetManager = new Widget1Manager();

   6:          List<Foo> list = widgetManager.GetFooData();

   7:          RenderView("Widget1", list);

   8:      }

   9:  }

However, there still are some uses for view user controls here. Let's say you want to render your widgets via an AJAX call. One feature of the "normal" MVC controllers is that the views rendered can be either aspx or ascx. Rendering an ascx user control from an MVC Controller would be a good choice when you want to implement the AJAX HTML Message Design Pattern where you're returning only an HTML snippet from the server rather than an entire page. In this case, we can render our user controls with an AJAX jQuery call. So if we had a couple of HTML divs (called "secondWidget" and "thirdWidget") and a WidgetController class with actions methods Widget2() and Widget3(), we could simply implement this simple jQuery function:

   1:  <script type="text/javascript">

   2:      $(function() {

   3:          $('#secondWidget').load('/Widget/Widget2');

   4:          $('#thirdWidget').load('/Widget/Widget3');

   5:      });

   6:  </script>

These are some rough ideas to get you started. The complete code sample can be downloaded here.

MVC JSON - JsonResult and jQuery

Steve Michelotti — Sat, 28 Jun 2008 11:35:04 GMT

The latest release of the MVC framework provides the JsonResult for Controller actions. I was surprised that I did not find a weatlh of examples for usage so I figured it shouldn't be too hard to get a decent example going. It turns out, it was even easier than I anticipated. I wanted to create an example where I would invoke an AJAX call to dynamically populate a dropdown list.

jQuery has recently received a huge surge of interest of the ASP.NET MVC community so I've been getting up to speed on it myself. I am quickly turning into a true believer and I've been impressed not only with how few lines of javascript it takes me to get things done but also how (relatively) easy it was to learn. In addition to numerous examples on the jQuery web site I also recommend jQuery In Action.

Getting an AJAX request with jQuery and JSON in MVC is actually pretty simple. The first step is to have a Controller action that returns a JsonResult:

   1:  public JsonResult GetStateList()

   2:  {

   3:      List<ListItem> list = new List<ListItem>() {

   4:          new ListItem() { Value = "1", Text = "VA" },

   5:          new ListItem() { Value = "2", Text = "MD" },

   6:          new ListItem() { Value = "3", Text = "DC" }

   7:      };

   8:      return this.Json(list);

   9:  }

Here I'm using the System.Web.Mvc.ListItem class (which is used as items in the SelectList) to simply return a contrived list of US states to populate a dropdown list. All I have to do is call the Json() method passing in my object and it will automatically be serialized to JSON. When the request is made the AJAX call can be seen in the Web Development Helper which is an invaluable tool to any AJAX development:

Notice the "application/json" in the request header and the textual representation of the JSON that is being returned from my JSON controller action.

The jQuery to make this happen is quite succinct:

   1:  <script type="text/javascript">

   2:  $(function() {

   3:      $('#btnFillList').click(function() {

   4:          $.getJSON("/Home/GetStateList", null, function(data) {

   5:              $("#stateList").fillSelect(data);

   6:          });

   7:       });

8:

   9:       $('#btnClearList').click(function() {

  10:          $("#stateList").clearSelect();

  11:       });

  12:  });

  13:  </script>

Notice on line #4 the use of the $.getJSON() jQuery method. Then I've simply written a re-usable jQuery method called fillSelect() which will work on the JSON format returned by the ListItem class returned by my controller action:

   1:  $.fn.clearSelect = function() {

   2:      return this.each(function() {

   3:          if (this.tagName == 'SELECT')

   4:              this.options.length = 0;

   5:      });

   6:   }

7:

   8:  $.fn.fillSelect = function(data) {

   9:      return this.clearSelect().each(function() {

  10:          if (this.tagName == 'SELECT') {

  11:              var dropdownList = this;

  12:              $.each(data, function(index, optionData) {

  13:                  var option = new Option(optionData.Text, optionData.Value);

14:

  15:                  if ($.browser.msie) {

  16:                      dropdownList.add(option);

  17:                  }

  18:                  else {

  19:                      dropdownList.add(option, null);

  20:                  }

  21:              });

  22:          }

  23:      });

  24:   }

On line #13 above you'll see the strongly-typed "Text" and "Value" properties that I have the luxury of using because of the native JSON serialization into objects.

The complete code sample can be downloaded here. It's barely 50 lines of code in all.

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.

Leverage EntLib Validation Application Block in MVC

Steve Michelotti — Tue, 17 Jun 2008 19:47:32 GMT

One of the areas of MVC that is still an open area in development is how best to handle UI validations. There are numerous approaches currently being examined.

The Enterprise Library's VAB is great because it allows you to specify all your validation logic in your business layer where it belongs rather than in your UI. Additionally, it comes with the PropertyProxyValidator to automatically display validation messages in the UI and avoid having to put hundreds of validators on a page. However, the PropertyProxyValidator is a traditional ASP.NET validator control and does not work in the MVC framework.

The good news here is that duplicating the functionality of the PropertyProxyValidator in the MVC framework is not difficult. Currently, the MVC framework comes with some built-in extension methods to enable the developer to easy create UI elements hanging off the HtmlHelper property. I've written a couple of similar extension methods following the same pattern that essentially produce the same output as the ProperyProxyValidator. This enables us to write UI code without cluttering our mark up with a ton of validator controls:

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

   2:  <%=Html.Validator("FirstName", ViewData.Model.ValidationResults)%>

Notice that a property called "ValidationResults" is being passed in to this Validator. When the form is submitted, it goes to a controller action (let's say "Save" for this example):

   1:  public ActionResult Save(int id)

   2:  {

   3:      Contact contact = new Contact();

   4:      contact.ContactID = id;

   5:      BindingHelperExtensions.UpdateFrom(contact, Request.Form);

6:

   7:      ValidationResults validationResults = Validation.Validate(contact);

   8:      if (validationResults.IsValid)

   9:      {

  10:          contactManager.SaveContact(contact);

  11:          return RedirectToAction(Views.Index);

  12:      }

  13:      else

  14:      {

  15:          ContactViewData contactViewData = new ContactViewData(contact);

  16:          contactViewData.ValidationResults = validationResults;

  17:          ViewData.Model = contactViewData;

  18:          return View(Views.EditContact);

  19:      }

  20:  }

So if the contact object in this example is valid, we save it to the database and proceed as normal to the next redirect action. However, if the contact is not valid, we redisplay the edit contact page again and this time we pass the ValidationResults along with the existing contact object in the Model to the View. This Validator control will grab the appropriate validation messages for the specified control/property and display any validation messages for that specific control. The following is the complete code for the Validator extension methods:

   1:  public static class ValidationControlExtensions

   2:  {

3:

   4:      public static string Validator(this HtmlHelper html, string controlToValidate, ValidationResults validationResults)

   5:      {

   6:          return Validator(html, controlToValidate, validationResults, new { style="color:Red;" });

   7:      }

8:

   9:      public static string Validator(this HtmlHelper html, string controlToValidate, ValidationResults validationResults, object htmlAttributes)

  10:      {

  11:          return Validator(html, controlToValidate, controlToValidate, validationResults, htmlAttributes);

  12:      }

13:

  14:      public static string Validator(this HtmlHelper html, string controlToValidate, string propertyName, ValidationResults validationResults, object htmlAttributes)

  15:      {

  16:          if (validationResults == null)

  17:          {

  18:              return null;

  19:          }

20:

  21:          var filteredResults = validationResults.Where(r => r.Key == propertyName);

  22:          if (filteredResults.Count() == 0)

  23:          {

  24:              return null;

  25:          }

26:

  27:          StringBuilder errorMessage = new StringBuilder();

  28:          foreach (ValidationResult validationResult in filteredResults)

  29:          {

  30:              errorMessage.Append(validationResult.Message);

  31:              errorMessage.Append("<br/>");

  32:          }

33:

  34:          TagBuilder builder = new TagBuilder("span");

  35:          IDictionary<string, object> attribueDictionary = new RouteValueDictionary(htmlAttributes);

  36:          builder.Attributes = ToStringDictionary(attribueDictionary);

  37:          builder.InnerHtml = errorMessage.ToString();

  38:          return builder.ToString();

  39:      }

40:

  41:      /// <summary>

  42:      /// ToStringDictionary is Internal to System.Web.Mvc.HtmlHelper

  43:      /// </summary>

  44:      /// <typeparam name="TKey"></typeparam>

  45:      /// <typeparam name="TValue"></typeparam>

  46:      /// <param name="dictionary"></param>

  47:      /// <returns></returns>

  48:      internal static Dictionary<string, string> ToStringDictionary<TKey, TValue>(IDictionary<TKey, TValue> dictionary)

  49:      {

  50:          if (dictionary == null)

  51:          {

  52:              return new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);

  53:          }

  54:          return dictionary.ToDictionary<KeyValuePair<TKey, TValue>, string, string>(entry => Convert.ToString(entry.Key, CultureInfo.InvariantCulture), entry => Convert.ToString(entry.Value, CultureInfo.InvariantCulture), StringComparer.OrdinalIgnoreCase);

  55:      }

  56:  }

One note here is that you can see I'm using a class called TagBuilder inside my method. This is actually an internal class in the System.Web.Mvc assembly. I just cracked open Reflector and did a complete copy/paste of that code into my own assembly so that I could leverage it. But what would be really nice is if Microsoft would change the accessibility on that class to public to more easily enable scenarios like this when people want to build their own control extension methods.

CMAP Presentation - C# 3.0 Language Features Code Samples

Steve Michelotti — Wed, 07 May 2008 20:27:51 GMT

The code samples from my recent presentation at the CMAP Main meeting can be downloaded here: C# 3.0 New Language Features. The direct download link is here.

CMAP Presentation - C# 3.0 Language Features

Steve Michelotti — Mon, 05 May 2008 00:30:34 GMT

This Tuesday I'll be giving of presentation on C# 3.0 New Language Features at the CMAP Main Meeting: www.cmap-online.org/Meetings/Details/2008-05-06.aspx . This is CMAP's .NET 3.5 Launch Event.

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.

CMAP Code Camp Spring 2008 - Code Samples

Steve Michelotti — Mon, 21 Apr 2008 01:40:18 GMT

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

Presentation at CMAP Code Camp Spring 2008

Steve Michelotti — Fri, 11 Apr 2008 02:02:40 GMT

This Saturday I'll be giving a presentation on LINQ to SQL at the Spring 2008 Maryland CMAP Code Camp: www.cmap-online.org/CodeCamp/