.NET 3.5

ASP.NET MVC Application – AlbumCredits.com

Steve Michelotti — Wed, 18 Nov 2009 15:15:35 GMT

Recently my company just released the first version of a new MVC web site: AlbumCredits.com. This project, led by Oskar Austegard, is was I consider a highly successful real-world implementation of MVC. In a time when most music these days is downloaded, the production and performance engineers, and recording professionals that work on the music don’t always get credit because there is no CD booklet to look through. Album Credits is almost like a LinkedIn for recording professionals. From the about page: AlbumCredits.com is “A fast, easy way to find production and performance credits from more than one million CDs and LPs.”

We leveraged a ton of great technologies during the development of this solution. To name a few:

Custom Controller factory based on StructureMap Inversion of Control (IoC) container
jQuery for all AJAX needs
T4MVC Templates
Data Annotations for Validation
xVal for client side validation
LINQ to SQL with stored procedures (including a few UDFs) for data access
SQL Server 2008 with Full Text Search
SQL Server Integration Services for the data feed
MvcFutures (functionality that will be baked in to MVC2)
Numerous custom HTML Helpers
Numerous third party jQuery plug ins including:

jQuery UI
jQuery Tools:

Tabs
Scrollable
Overlay

Tablesorter
jQuery Form
Jcrop
jWysiwyg

For unit testing – NUnit and NUnitEx
For mocking - Moq

Additionally, on the build server we used:

Cruise Control .NET
MSBuild
FxCop
StyleCop
NUnit

Album Credit starts with a nice AJAX auto-complete search box:

The site is then “deep linkable”. Want to see what engineers worked on a particular album? What other albums did they work on? Which other artists? You can literally relate any category together in your searching - think Six Degrees of Kevin Bacon but for the music industry.

It’s an example of a site that takes a very cool idea and melds it will a solid technical implementation. Check it out!

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!

MVC AJAX Form with jQuery Form Plugin and jQuery Thickbox

Steve Michelotti — Tue, 01 Sep 2009 11:28:11 GMT

In a previous post, I showed how to submit an AJAX form in MVC with the jQuery Thickbox and the built-in MVC AJAX helpers. If you read that post first, it will show the complete context for how to simply submit an AJAX form that is being rendered inside a jQuery Thickbox with built-in MVC AJAX helpers. But what if you want to stick to a pure jQuery solution? That is also simple enough to do. Instead of using the Ajax.BeginForm() method, you can use the jQuery Form Plugin. The code is almost identical to the previous implementation. The only differences are in the Index.ascx partial view:

   1:  <%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<MvcAjaxForm.Models.ContactMessage>" %>

2:

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

   4:      $(function() {

   5:          $("#contactForm").ajaxForm({ target: '#contactArea' });

   6:      });

   7:  </script>

8:

   9:  <h2>Contact</h2>

10:

  11:  <form id="contactForm" action="<%=Url.Action("Index", "Contact") %>" method="post">

  12:      <div id="contactArea">

  13:          Email Address: <%=Html.TextBox("EmailAddress") %> <br /><br />

  14:          Message: <%=Html.TextArea("MessageText")%>

  15:          <input type="submit" />

  16:      </div>

  17:  </form>

On line 11, you will now specify a normal HTML form just like you might specify any other form in MVC (you could also use the Html.BeginForm() method as well if you have that preference). The only additional thing you have to implement is the one line of code shown on line 5 above. This is making a call to the ajaxForm() method (that comes in the Form Plugin library) and passes in the options to indicate that the response from the server should be displayed in the “contactArea” div. This is just one example of how to use the Form plugin – you can also find numerous example within the Form Plugin’s documentation site.

MVC AJAX Form with Ajax.BeginForm() and jQuery Thickbox

Steve Michelotti — Mon, 31 Aug 2009 09:00:18 GMT

A relatively common scenario you might want in your application is the ability for a user to click a link that pops up a little dialog to submit some information. For example, let’s say you have this form where the user could click the “Contact this person” link:

After clicking this link, it pops up the following dialog where the user can type in their message:

Finally, once the user submits their message, it shows a little confirmation:

This scenario can be implemented with MVC with very few lines of code. First off, we’ll be using the AJAX HTML Message pattern so that the AJAX messages that are going across the wire are simple HTML snippets. Also, we’ll use jQuery Thickbox for our dialog. The first thing we need to do it to implement our “Contact this person” link:

   1:  <%=Html.ActionLink("Contact this person", "Index", "Contact", new { height = 200, width = 300 }, new { @class = "thickbox" }) %>

This is a pretty typical implementation of the jQuery thickbox. We’re specifying that we want an AJAX call to be made to our ContactController.Index() method. The HTML that this ActionLink renders will simply look like this:

   1:  <a class="thickbox" href="/Contact?height=200&amp;width=300">Contact this person</a>

The complete code for the ContractController looks like this:

   1:  public class ContactController : Controller

   2:  {

   3:      public ActionResult Index()

   4:      {

   5:          return View(new ContactMessage());

   6:      }

7:

   8:      [ActionName("Index")]

   9:      [AcceptVerbs(HttpVerbs.Post)]

  10:      public ActionResult SubmitMessage(ContactMessage message)

  11:      {

  12:          return this.View("Confirmation", message);

  13:      }

  14:  }

It is important to note that both views returned by the ContactController’s action methods are both partial views (i.e., Index.ascx and Confirmation.ascx) with our HTML snippets in there. We know that in the Index.ascx we want to do an AJAX form submission/post rather than a full page form submission. There are a couple of ways to do this including using the jQuery Form plugin. However, in this case, the MVC framework already comes built-in with this functionality so we don’t have to rely on the jQuery Form plugin (unless we want to). Most of the time we find ourselves using the Html property of the View which is of type HtmlHelper. However, there is also an Ajax property of the view of type AjaxHelper. The AjaxHelper has a BeginForm method that will allow you to submit the form via AJAX. You’ll need to make sure you include the MicrosoftAjax.js and MicrosoftMvcAjax.js scripts in your page to use the Ajax helpers. The complete implementation for the Index.ascx can just look like this:

   1:  <%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<MvcAjaxForm.Models.ContactMessage>" %>

2:

   3:  <h2>Contact</h2>

4:

   5:  <% using (Ajax.BeginForm("Index", "Contact", new AjaxOptions { UpdateTargetId = "contactArea" } )) { %>

   6:      <div id="contactArea">

   7:          Email Address: <%=Html.TextBox("EmailAddress") %> <br /><br />

   8:          Message: <%=Html.TextArea("MessageText")%>

   9:          <input type="submit" />

  10:      </div>

  11:  <% } %>

Notice the UpdateTargetId is specifying the “contactArea” div. This causes all HTML that is sent back on the form post (i.e., the confirmation message) to be displayed inside this div only. The complete code for this sample can be downloaded here.

FredNUG Code Samples

Steve Michelotti — Thu, 27 Aug 2009 16:30:28 GMT

Thanks to everyone who attended my presentation last night at FredNUG. The code samples can be downloaded here.

C# 3.0 Deep Dish with a slice of C# 4.0 – Code Samples

Steve Michelotti — Wed, 26 Aug 2009 14:04:51 GMT

Thanks to everyone who attended my presentation last night at CapArea on C# 3.0 and C# 4.0. You can download the C# 3.0 code samples, C# 4.0 code samples, and the PowerPoint presentation from here.

Several people asked me about some of the tools I was using during the presentation. A list of the tools that I use (and more) can be found here.

Feel free to email me with any questions.

Velocity CTP3 Set up for ASP.NET Session State

Steve Michelotti — Fri, 14 Aug 2009 07:46:02 GMT

Historically I have always viewed ASP.NET session state as “pure evil.” In-proc session state is about as unreliable as you can get given that you can have timeouts, ASP.NET might recycle itself, IIS might get bounced, no scalability, and cannot work in a web farm. SQL Session state is very resilient and works in web farm scenarios but the performance is not good and at that point you might as well be better off writing your own strongly-typed data access layer rather than blobbing everything in and out of the database. ASP.NET state server is the “middle man” of the various options but it’s not very fault tolerant. As part of Microsoft’s Velocity distributed cache they are providing an asp.net session state provider that is actually a *very* compelling option in my opinion for managing asp.net session state – more compelling than any of the traditional three choices. It’s an in-memory distributed cache and it provides *both* high performance as well as robust fault tolerance potentially giving the best of both worlds.

I recently set up Velocity CTP3 in my development environment and there were a couple of minor gotchas. Many of the samples on the web were either incomplete or outdated (i.e., based on previous versions prior to CTP 3). The links I found most helpful (in addition to the Velocity help file) to get everything set up were: Build Better Data-Driven Apps With Distributed Caching, How to: Configure a Session State Provider, and Andrea Col’s Blog. Putting all these links together, I was able to get it working. This post will walk through all of the set up steps in a single place.

Step 1 – Download and run installer

Download Velocity CTP 3 from this location.

Step 2 – Accept firewall defaults

Step 3 – Cache Host Configuration

Create a new database called “Velocity” in SQL Server Management Studio. On the Cache Host Configuration screen, specify these values:

Storage Location type: SQL Server database
Connection string: data source=<YourDBServer>;Initial Catalog=Velocity;Integrated Security=SSPI
Cluster Name: “DevCluster” (this could really be anything)
Cluster Size: Small (1-4)

Leave all other defaults.

Step 4 – Configure with PowerShell

Start PowerShell Administration Tool found in the “Microsoft Distributed Cache” fold in Program Files off the Start menu. The first time you run it can you choose “A” for always run software from this untrusted publisher.

Execute: Start-CacheCluster

Execute: New-Cache -CacheName ASPNETSessionCache -TTL 60

For verification you can look at the statistics for the cache you just created:

Execute: Get-CacheStatistics -CacheName ASPNETSessionCache

Step 5 – Configure web.config

The best reference I found for the web.config for CTP3 is here. You can copy/paste that and either leave as is or tweak if desired. For example, you might want to change config values in the sessionState section for cookieless, etc. depending on your scenario.

Hope this helps ease the set up process.

MVC RadioButtonList HTML Helper – Take 3

Steve Michelotti — Fri, 07 Aug 2009 07:33:09 GMT

In two previous posts, I talked about ways to create your own HTML Helper to generate a radio button list. In the first post I leveraged the FluentHtml library to create a table layout. In the second post I switched this to using a div instead of a table. The crux of the issue was that I wanted to make sure the the “id” and “name” attributes were set correctly and MVC out of the box doesn’t seem to do this properly. Recently I discovered a way to successfully do this without “wrapping” the FluentHtml library but by using it directly while leveraging a “RadioSet” like this:

   1:  <%=this.RadioSet(m => m.Name).Options(Model.FooBarList) %>

To produce HTML that looks like this:

   1:  <div id="Name">

   2:      <input id="Name_Foo" name="Name" type="radio" value="Foo" /><label for="Name_Foo" id="Name_Foo_Label">Foo</label>

   3:      <input id="Name_Bar" name="Name" type="radio" value="Bar" /><label for="Name_Bar" id="Name_Bar_Label">Bar</label>

   4:  </div>

which is exactly what I want. However, there are a couple of gotchas I ran into for making this work properly. First off, it’s important to note that the Options() method above is taking an IEnumerable<SelectListItem> and FooBarList is IEnumerable<SelectListItem>. The first thing I tried was creating my list like this:

   1:  private static IEnumerable<SelectListItem> CreateFooBarList()

   2:  {

   3:      var list = new List<string> { "Foo", "Bar" };

   4:      return new SelectList(list);

   5:  }

This resulted in HTML that was broken as the id’s and value’s were not set correctly:

   1:  <div id="Name">

   2:      <input id="Name" name="Name" type="radio" value="" /><label for="Name" id="Name_Label">Foo</label>

   3:      <input id="Name" name="Name" type="radio" value="" /><label for="Name" id="Name_Label">Bar</label>

   4:  </div>

So realized it was probably because that SelectListItem constructor just didn’t assign the Value property when a list of strings was sent in. So I changed to this:

   1:  private static IEnumerable<SelectListItem> CreateFooBarList()

   2:  {

   3:      var list = new List<SelectListItem>

   4:      {

   5:          new SelectListItem { Text = "Foo", Value = "Foo" },

   6:          new SelectListItem { Text = "Bar", Value = "Bar" }

   7:      };

   8:      return new SelectList(list);

   9:  }

I figured now that I was using an actual strongly-typed SelectList I would be all set. But unfortunately, the rendered HTML was even worse now:

   1:  <div id="Name">

   2:      <input id="Name" name="Name" type="radio" value="" /><label for="Name" id="Name_Label">System.Web.Mvc.SelectListItem</label>

   3:      <input id="Name" name="Name" type="radio" value="" /><label for="Name" id="Name_Label">System.Web.Mvc.SelectListItem</label>

   4:  </div>

It turns out that the way I had to fix this was to specify *all* arguments on the SelectList constructor with the dataTextField and dataValueField as shown on line #8 below:

   1:  private static IEnumerable<SelectListItem> CreateFooBarList()

   2:  {

   3:      var list = new List<SelectListItem>

   4:      {

   5:          new SelectListItem { Text = "Foo", Value = "Foo" },

   6:          new SelectListItem { Text = "Bar", Value = "Bar" }

   7:      };

   8:      return new SelectList(list, "Value", "Text");

   9:  }

Now the HTML and all attributes are correct. You would *think* that the constructor of the SelectList would be smart enough to identify that the IEnumerable collection that was sent in was of type IEnumerable<SelectListItem> (which is what it ultimately wants) and set those arguments for you automatically. But it looks like that was a naive assumption on my part. Easy enough to add a simple extension method to do this for you throughout your codebase. Make sure to watch out for this in your own code – I won’t make this mistake again.

Alternate MVC Screen Navigation

Steve Michelotti — Fri, 07 Aug 2009 06:08:14 GMT

Suppose you have a simple sequential screen flow in your application like this:

One typical scenario for this is that each screen has its own associated Controller (for the example we’ll say Controller1, Controller2, etc. but obviously they would have meaningful names in the real world). When the user submits Screen1 then the code Controller 1 will have something like this:

   1:  return this.RedirectToAction("Index", "Controller2");

In fact, each controller would have to have code like this that essentially “points to” the next controller in the sequential screen navigation. But if Screen 2 and Screen 4 swapped positions in the order, you’d have to:

Change the code in Screen 1 to point to Screen 4 instead of 2
Change the code in Screen 4 to point to Screen 3 instead of 5
Change the code in Screen 2 to point to Screen 5 instead of 3

So in a case like this, it might make more sense to encapsulate this sequential order in a single place. The goal would be to be able to change the code in each controller to something like this:

   1:  return this.RedirectToNextAction();

It’s actually not very much work to implement something like this. First, you’d want to encapsulate everything in some type of “PageManager” class that has a GetNextStepFrom() method where you give it a controller name and it gives you back the next controller. I’ve oversimplified an example in the interests of keeping this example simple:

   1:  class PageManager

   2:  {

   3:      public string GetNextStepFrom(string controller)

   4:      {

   5:          int index = controllerList.IndexOf(controller);

   6:          return controllerList[index + 1];

   7:      }

8:

   9:      private List<string> controllerList = InitializeControllerSequence();

10:

  11:      private static List<string> InitializeControllerSequence()

  12:      {

  13:          return new List<string> {

  14:              "Controller1",

  15:              "Controller2",

  16:              "Controller3",

  17:              "Controller4",

  18:              "Controller5"

  19:          };

  20:      }

  21:  }

At this point, we’re ready to implement our RedirectToNextAction() method which is what makes all this work. The best way is to sub-class all your controllers and put this protected method in the base class:

   1:  protected ActionResult RedirectToNextAction()

   2:  {

   3:      var controllerName = this.RouteData.Values["Controller"].ToString();

   4:      var nextController = PageManager.GetNextStepFrom(controllerName);

   5:      return this.RedirectToAction("Index", nextController);

   6:  }

Notice that to get the name of the current controller, I’m having to get it from the RouteData dictionary. What would be really nice if I could just do this.Name to get the name of the controller. If you use the MVC T4 templates, it does give each controller class a Name property (although right now it’s actually a public field) but it’s not usable for this implementation in its current format because the Name property is not on the base class so can’t be used polymorphically. Note that in C# 4.0, you could rewrite line #3 above to be:

   1:  dynamic thisController = this;

   2:  var controllerName = thisController.Name;

This would be leveraging a form of duck typing but may be overkill for a scenario like this since you’re essentially relying on Reflection at this point.

In any case, scenarios like these are good candidates for encapsulating the concern of screen navigation flow to an independent component outside the controllers.

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);