Action Filters give you the ability to run custom code before or after an action (or page) is hit. Applying action filters to your MVC app is simple because they are implemented as attributes that can be placed on a method (an individual Action), or a class (the entire Controller).

To show how easy this is, we’re going to take the out-of-the-box ASP.NET MVC template, and very slightly tweak it to begin logging. We’ll add one class (our custom Action Filter), and salt the existing pages with our new “LogRequest” attribute.

Creating a Custom Action Filter

To create your own action filter, you simply have to inherit from the base “ActionFilterAttribute” class that’s already a part of the MVC framework. To make this easier on myself, I’ve also implemented the IActionFilter interface so that Visual Studio can auto-generate my two methods for me.

At this point, my custom action filter looks like this:

The ActionFilterAttribute and IActionFilter interface comes from the System.Web.Mvc namespace.

Applying Our Custom Action Filter

Now that we have created our action filter, we need to apply it to our Controllers or optionally, to our Actions. Because logging is something that you would likely want on all of your “pages”, we’ll simply add it at the controller level. Here is what we’ve added to the two existing controllers that were supplied in the ASP.NET MVC template.

That’s it! The ASP.NET MVC framework will automatically call our methods (OnActionExecuting and then OnActionExecuted) when a request comes in to any of those two controllers.

At this point, all we have to do is actually implement our logging code. Because I want to be able to easily report against my site’s activity, I’m going to log to a SQL database. Now, it’s important to note that action filters are executed synchronously (for obvious reasons), but I don’t want the user to have to wait for my logging to happen before he can enjoy my great site. So, I’m going to use the fire and forget design pattern.

When we’re all done, this is what our logger will look like:

Conclusion

There are a lot of features in MVC that could each merrit their own articles, but Action Filters are definately one feature that shows off the advantages of the MVC design pattern. Action Filters make perfect sense for cross-cutting concerns like logging, but you can get creative with how and why you use them.

This article isn’t here to show you the best way to do logging, but rather how and why you would use ASP.NET MVC Action Filters. Here’s the source code, play around with it: MVC_CustomActionFilter_Logging.zip

First, the Challenge

A common challenge of web applications is passing complex types and (more difficultly) stateful objects from one page to another. This difficulty is due to the disconnected nature of the web. There have been many attempts to solve this problem (sessions, ViewState, etc), but ASP.NET MVC’s new “Model Binders” functionality definitely takes the gold medal for being the cleanest, simplest and most powerful.

We’re going to build a couple of simple MVC pages, one that display a list of customers and the other displays their address details. You can download the solution at the end of the article (compiled for Visual Studio 2008 SP1 / ASP.NET MVC Preview 5).

What Are the Benefits?

ASP.NET MVC Model Binders give you the following benefits:

• Complete control over the deserialization of complex types passed into your Action methods. This in itself has many sub-benefits: less bloat in your HTML and in passing objects back to the server, cleaner URL’s, etc.
• Unified and testable code. This feature really holds to the “Single Responsibility” (or separation of concerns) principle. This one place is where you will handle restoring your objects from the memento you come up with.

By the end of this article, we’ll see how easy it is pass complex “Customer” objects around our application and we’ll talk about how to create unit tests to ensure the quality of our methods. Our customer information will be stored in a SQL database, and the customer class will be generated by the LINQ to SQL as a concrete representation of a record in our database.

Before we dive into our application, let’s take a look at a snippet of code and see how MVC model binders make a difference.

MVC ModelBinder vs. Traditional ASP.NET

To demonstrate this functionality simply, consider the following scenario. You’re looking at the “List” page for your users. The list of users is in an HTML <table>, and the first column is a link to that user’s “Edit” page.

Let’s assume our link will produce the following URL: “/Users/Edit.aspx?UserID=123″. In traditional ASP.NET, we would probably have the following code at the top of our page.

This may not seem that bad, but if you think about it, we’ll have to re-write this code in every page that we want to pass a user object to and for every parameter that we need to have passed to the page. This approach isn’t very object oriented, and you’re constantly reminded of the fact that you’re just grabbing data out of the query string.

Now, notice the difference between what you have to do in traditional ASP.NET, and ASP.NET MVC (thanks to Model Binders):

Notice how much simpler that was? OK, so you might be wondering “where is the code?”… “How is the ‘currentUser’ parameter being passed in?” Now it’s time to see the magic.

Creating and Registering Model Binders

Because ASP.NET MVC is designed to make things simple and easy to use, creating and registering your own Model Binders is a quick task. There are really only two things you have to do to handle the ‘serialization / deserialization’ part, and there is one simple line of code to register your custom model binder with the MVC framework. Let’s break it down here.

First of all, we need to decide how we want to ‘tokenize’ our object (meaning, what string representation do we want to make so that we can get our object back later). You currently have three options here, but I would like to see a fourth one by the time MVC goes live (I’ll explain in a minute).

Essentially, the three choices you have all boil down to the same thing:

• Make your class implement the IConvertible interface, and provide your code for how it should ‘convert’ to a string.
• Make your class implement the IFormattable interface, and do the same as the above.
• Or, simply override “ToString” and put your logic there.

I’m going to use this third approach because it’s simple, but you certainly could go with one of the above. In some cases, it would be best to use the first choice (the IConvertible). You may want to choose this so that you can free up your “ToString” method to provide a user-friendly looking string representation of your object, and then use the ConvertTo method to provide your memento.

Example: ‘ToString()’ might return “Khouri, Timothy”, and ‘ConvertTo()’ might return ‘ID:1234′.

Because my “Customer” class is being auto-generated by LINQ-to-SQL, I’m going to create a class file that extends it a little to provide my own “ToString” method. This is not an “extension method”, but rather just a partial class file. Here’s my code:

public partial class Customer
{
   public override string ToString()
   {
       // I could just return “ID.ToString()”, but I
       // want to be a little silly to prove that I have full
       // control over how my memento is going to look

       return Convert.ToBase64String(
               BitConverter.GetBytes(this.ID)
           ).Replace(“=”, “_”);
   }
}

Basically, this will convert any instance of a Customer class to a string that looks something like “CwAAB0__”. Now, I need to make my ModelBinder that will take that string, convert it back to the ID of the Customer, and then re-create the Customer object (which in this case, will be a simple task for LINQ-to-SQL).

As was mentioned before, creating our own custom ModelBinder is very simple. We’re going to inherit from “DefaultModelBinder”, and then override the “ConvertType” method. The ‘value’ object that gets passed in could be a string, or an array of strings, so I’ll have to check for that. Here’s the code:

That’s it! We’ve now created a ModelBinder that will tell MVC how to convert that token back into a real, tangible Customer object. Next we’ll see how to register and use our custom parameter converting model binder.

In our global application file (Global.asax), we are already registering our routing information for MVC (which tells the framework where to look for our Controllers and Actions). Now we’re going to add this simple line of code that tells the MVC framework to how to reconstitute our Customer class. Here’s the code:

Seeing the Results

There is no better way to fully appreciate what is happening here other than seeing the result for yourself. In my ‘list customers’ page, I’m building the link to the details page in a very object-oriented way:

Here’s is what our page will look like:

And here is the details page. Notice the URL. If you scroll up you’ll see that I never told MVC to call the parameter “targetCustomer”, but MVC automatically figured that out because that’s what the parameter is named in my “Details” method.

Testing Your Converter

As I stated above, I wanted to mention why this approach is good in terms of testability. Basically, because this bit of functionality is so small and specific, it is fully testable. You can use your favorite ‘mock’ framework to create a FakeHttp request with your token in the query string, and see if it correctly creates the Customer class.

As a side note: don’t forget that my model binder is hitting the data access layer, so if you are going to create unit tests you’ll want to also mock the DAL as well.

And now, here is the solution (compiled for Visual Studio 2008 SP1, ASP.NET MVC Preview 5): SingingEels_MVC_ModelBinders.zip

For those of you who are not familiar with Test Driven Development (TDD) or it’s benefits, consider the following scenario. Let’s assume that you have been contracted to build a site that deals with customer management. One of the client’s business rules is that customers must have at least a first name, last name and a zip code. This is a fairly straight forward request that will help us easily get into TDD.

Creating MVC Apps With Unit Tests

To prove that MVC is meant for testing, the Visual Studio template for a new ASP.NET MVC (Preview 5) project will automatically ask if you want to include a Unit Test project as well.

The default Test Project that comes with the ASP.NET MVC Visual Studio template is pretty basic, and includes a test class for each of the default Controller’s that come with your MVC app.

So, the steps to start our project are very simple:

1. File -> New -> Project
2. ASP.NET MVC Web Application
3. Yes, create a unit test project.

Business Rules as Tests

So, after learning what our business rules are, our next step in TDD is to express those business rules in the form of unit tests. To do this, we’ll add a class to our Test Project that will handle testing all things “Customers” related. We’ll need to decorate the class with the “TestClass” attribute, and each method with the “TestMethod” attribute. Our “customers test class” should look like this:

Now that we have a stub for our tests, we need to do a *little* bit of implementing our code in our CustomersController class in our ASP.NET MVC app. All we are going to do is create the method stub that is responsible for creating new customers. Once we do that, we can come back and finish our test method.

I mentioned earlier in the article that using a ModelBinder will make writing tests easier, and that may seem confusing at first. ModelBinders are run by the ASP.NET MVC framework, and will not be used by our Test Project, so how can they help in writing unit tests?

The answer is simple: Object Oriented Programming. Basically, because ModelBinders allow me to write my ASP.NET MVC Action Methods with complex objects as parameters, I can test against them in a much more OO fashion. Example:

So now we are ready to write our tests, but first we should mention a little “gotcha” that needs to be addressed. Because I only want to test my business rules, and not the code that ultimately writes the customer record to the database, I need to prevent my code from actually running the “store in database” part of my code. This is known as “mocking”.

Testing One Step at a Time

There are three pieces to our business rule that we are going to test individually: Required first name, last name and zip. To do this, we’re going to create an instance of our CustomersController, and call Create method. We’re going to pass in a customer object that *should fail validation*, and then we’ll check to make sure that, in fact, the Create method did fail.

This may seem odd (to hope for failure), but again remember that we want to test to make sure that validation is working, so we have to pass in bad data and look for the validation to come back.

Here’s our code that we’ll put inside of our “EnsureRequiredFields” method mentioned earlier in the article:

Now, when we run our tests in Visual Studio we will fail until we code the appropriate validation in our Create method. Here’s what that will look like:

Now you keep coding your app until you pass that test (which in this case should be pretty easy). So, once we add this code to our Create method, we’ll be good to go:

Conclusion

Hopefully this article has been able to demonstrate how easy it is to start down the path of TDD with the ASP.NET MVC framework. The demo project for this article can be downloaded here: MvcDemo_Testing_CreateCustomer.zip.

This article will demonstrate some basic AJAX functionality that comes with the ASP.NET MVC framework. We’ll also see how simple it is to get the same usefulness of our web application even if we disable JavaScript capabilities in our browser.

Our demo site will have a “news” section where users can view the latest news, and subscribe to our newsletter. This functionality will be provided through AJAX calls. Our goal is to achieve this same functionality for non-ajax-enabled browsers without duplicating a lot of work.

AJAX Extensions in ASP.NET MVC

If you’ve been playing around in ASP.NET MVC even a little, you likely have noticed how simple it is to use AJAX in your web app. Take for example creating a link to our “News List” page (which is actually in our demo app). To make a standard link that goes to the “News” controller and executes the “List” action would look something like this:

But what would we do if we wanted that link to use AJAX to pull the latest news and update a simple <div> on our page? All we would have to do is use the “Ajax.ActionLink” method, and supply an extra parameter that has the ‘AJAX options’ in there. Here’s what that would look like:

That code will build an HTML link that also has some JavaScript in the onclick event for handling the AJAX stuff. It’s important to know that since this is a regular old HTML link, if the JavaScript part fails (either due to a bug, or if scripts are disabled), then the browser will navigate to the URL as if there was no JavaScript at all. And that brings us to the next point!

Coding Your ActionMethod to Detect AJAX Requests

Because one of our main goals is not to have to duplicate a lot of work, we want the same code to run for the user if he’s using AJAX or not. The only part that has to change really is the “View” that gets sent back to the client. In order to accomplish this, we’re going to use the “IsMvcAjaxRequest” method that comes in the System.Web.Mvc.Ajax namespace (in the AjaxExtensions class).

And then to use it in our ActionMethod, here’s what we would do:

Notice that we don’t have to duplicate any logic for getting the latest news. The only bit of custom logic that is needed is to determine which view to send. This can be done for form posts too (as you can see in the screen shots below or by downloading the project at the end of the article). Here’s what the results of the above will look like for an AJAX enabled, and a non-AJAX enabled browser:

After clicking on the “view news” link with AJAX enabled:

After clicking “view news” with JavaScript (and therefore AJAX) disabled:

If you notice the URLs in the second and third screen shots, you’ll see that with AJAX disabled the browser simply navigated to where the link was pointing. Thus, a graceful degradation was achieved.

Conclusion

With little effort, we achieved an AJAX enabled ASP.NET MVC site, and cleanly/gracefully allowed non-AJAX users to enjoy the same benefits of our demo app. The project was written in Visual Studio 2008 SP1 with the ASP.NET MVC Beta 1 bits installed. Because the DLL’s are bin-deployed, you should be able to download and run the project even if you don’t have the MVC beta install. Check it out for yourself: SingingEels_MvcAjaxMashup.zip

It’s true that much of the ASP.NET framework has been pluggable for a while (example: Membership and Profiles). Also, we have always had a choice of server-side language from the start (example: C# or VB). But only recently with the birth of ASP.NET MVC do we have a clean and straight forward solution to swap out the “ASP” language for our own.

By the end of this article, we will have made our own language (called “HoTMeaT”), we will have registered our custom ViewEngine and we will notice just how easy it is to swap out this seemingly ‘fixed’ area of ASP.NET. At the end of the article, you can download the entire demo project – including the source code for the language.

A Sneak Peek Into the Language

Before we get into a “step-by-step” of how to write our own ViewEngine, I want to show you how amazing this new “HoTMeaT” language is going to look. Since I’m currently on a WPF kick, I’m going to copy some of that great functionality by taking “binding” to the next level.

Here’s the code for the Customers/List page. We won’t need to do anything different in our code, because really, the “Controller” doesn’t care about how “View” will look. It’s only responsible for getting the data.

Now, how would you display a list of those people in your own custom HTML template? Well, if you were using WebForms (traditional ASP.NET), you would probably use a Repeater and then do data binding in the code behind. If you are using ASP.NET MVC, you would probably just write a for-loop with sloppy inline ASP. But, with HoTMeaT…

And here’s the HTML that it generates:

Now that’s pretty cool. But before we go on, there is a myth that needs to be dispelled. I’ve heard multiple people say that if you use / build a custom ViewEngine that you’ll suffer some great performance hit. That is completely not true. The HoTMeaT view engine (which parses the HTML for custom tags, and performs data binding at runtime for each request) runs at 0.00015 seconds. That means that it can handle hundreds of requests per second from my laptop. So no, there are no performance concerns (unless of course you’re a bad programmer).

Creating and Registering your Custom ViewEngine

ASP.NET MVC was built to allow developers to change certain parts of the pipe-line in a similar way. For example, creating and registering a ViewEngine is much like creating your own custom model binder and then registering it at runtime. We’ll create a class that inherits from “IViewEngine”. Then (just like with registering a ModelBinder) we’ll register our custom ViewEngine in the Global.asax file. Here’s the code:

Inside of our ViewEngine class we only have to provide the functionality for two methods – CreateView and CreatePartialView. Those methods will return an instance of a class that implements “IView”. The View class has one method in it – Render.

Here’s the code for our ViewEngine:

How Do I Build my View?

So now that we’ve created our ViewEngine and registered it in the Global.asax, we have to actually do something in our View class. As was mentioned above, the only method that we have to implement is “Render”, which passes in the viewContext (which gives us the Controller, ViewData, RouteData, etc) and a TextWriter for us to render to. So, if you wanted to make a *very* basic view engine that simply shells out a static file, you could do this:

And that’s really it! We’ve just made our own ViewEngine which creates a simple View that writes out the contents of a file. Now, you may be wondering what happened to my great new “HoTMeaT” language where we could do all that great data-binding right in our HTML. If you want to see all that code, then you can download the source project and take a look at the code yourself. That code is intentionally left that so as not to detract from the main point of the article. So here’s the full demo project with all of the code including the “HotMeatViewEngine”: SingingEels_CustomMvcViewEngine.zip

So What Is “HoT MeaT”?

Back in college I had a very “build it yourself to learn it” mentality (and really I still do today). So, I wanted to understand Sockets and client/server programming, so I made my own “web server”. All it did was shell out static HTML files. Then for some reason, my friend and I decided that we would make our own language: HTMT (“Hyper Text Meta Transformation” – aka “HoT MeaT”). I think we were bored in C++ 101, and bordom leads to invention! We got to the point of displaying the time on the server and basically stopped there. So that’s the story behind the name.

First, the Challenge

A common challenge of web applications is passing complex types and (more difficultly) stateful objects from one page to another. This difficulty is due to the disconnected nature of the web. There have been many attempts to solve this problem (sessions, ViewState, etc), but ASP.NET MVC’s new “Model Binders” functionality definitely takes the gold medal for being the cleanest, simplest and most powerful.

We’re going to build a couple of simple MVC pages, one that display a list of customers and the other displays their address details. You can download the solution at the end of the article (compiled for Visual Studio 2008 SP1 / ASP.NET MVC Preview 5).

What Are the Benefits?

ASP.NET MVC Model Binders give you the following benefits:

• Complete control over the deserialization of complex types passed into your Action methods. This in itself has many sub-benefits: less bloat in your HTML and in passing objects back to the server, cleaner URL’s, etc.
• Unified and testable code. This feature really holds to the “Single Responsibility” (or separation of concerns) principle. This one place is where you will handle restoring your objects from the memento you come up with.

By the end of this article, we’ll see how easy it is pass complex “Customer” objects around our application and we’ll talk about how to create unit tests to ensure the quality of our methods. Our customer information will be stored in a SQL database, and the customer class will be generated by the LINQ to SQL as a concrete representation of a record in our database.

Before we dive into our application, let’s take a look at a snippet of code and see how MVC model binders make a difference.

MVC ModelBinder vs. Traditional ASP.NET

To demonstrate this functionality simply, consider the following scenario. You’re looking at the “List” page for your users. The list of users is in an HTML <table>, and the first column is a link to that user’s “Edit” page.

Let’s assume our link will produce the following URL: “/Users/Edit.aspx?UserID=123″. In traditional ASP.NET, we would probably have the following code at the top of our page.

This may not seem that bad, but if you think about it, we’ll have to re-write this code in every page that we want to pass a user object to and for every parameter that we need to have passed to the page. This approach isn’t very object oriented, and you’re constantly reminded of the fact that you’re just grabbing data out of the query string.

Now, notice the difference between what you have to do in traditional ASP.NET, and ASP.NET MVC (thanks to Model Binders):

Notice how much simpler that was? OK, so you might be wondering “where is the code?”… “How is the ‘currentUser’ parameter being passed in?” Now it’s time to see the magic.

Creating and Registering Model Binders

Because ASP.NET MVC is designed to make things simple and easy to use, creating and registering your own Model Binders is a quick task. There are really only two things you have to do to handle the ‘serialization / deserialization’ part, and there is one simple line of code to register your custom model binder with the MVC framework. Let’s break it down here.

First of all, we need to decide how we want to ‘tokenize’ our object (meaning, what string representation do we want to make so that we can get our object back later). You currently have three options here, but I would like to see a fourth one by the time MVC goes live (I’ll explain in a minute).

Essentially, the three choices you have all boil down to the same thing:

• Make your class implement the IConvertible interface, and provide your code for how it should ‘convert’ to a string.
• Make your class implement the IFormattable interface, and do the same as the above.
• Or, simply override “ToString” and put your logic there.

I’m going to use this third approach because it’s simple, but you certainly could go with one of the above. In some cases, it would be best to use the first choice (the IConvertible). You may want to choose this so that you can free up your “ToString” method to provide a user-friendly looking string representation of your object, and then use the ConvertTo method to provide your memento.

Example: ‘ToString()’ might return “Khouri, Timothy”, and ‘ConvertTo()’ might return ‘ID:1234′.

Because my “Customer” class is being auto-generated by LINQ-to-SQL, I’m going to create a class file that extends it a little to provide my own “ToString” method. This is not an “extension method”, but rather just a partial class file. Here’s my code:

public partial class Customer
{
public override string ToString()
{
// I could just return “ID.ToString()”, but I
// want to be a little silly to prove that I have full
// control over how my memento is going to look

return Convert.ToBase64String(
BitConverter.GetBytes(this.ID)
).Replace(“=”, “_”);
}
}

Basically, this will convert any instance of a Customer class to a string that looks something like “CwAAB0__”. Now, I need to make my ModelBinder that will take that string, convert it back to the ID of the Customer, and then re-create the Customer object (which in this case, will be a simple task for LINQ-to-SQL).

As was mentioned before, creating our own custom ModelBinder is very simple. We’re going to inherit from “DefaultModelBinder”, and then override the “ConvertType” method. The ‘value’ object that gets passed in could be a string, or an array of strings, so I’ll have to check for that. Here’s the code:

That’s it! We’ve now created a ModelBinder that will tell MVC how to convert that token back into a real, tangible Customer object. Next we’ll see how to register and use our custom parameter converting model binder.

In our global application file (Global.asax), we are already registering our routing information for MVC (which tells the framework where to look for our Controllers and Actions). Now we’re going to add this simple line of code that tells the MVC framework to how to reconstitute our Customer class. Here’s the code:

Seeing the Results

There is no better way to fully appreciate what is happening here other than seeing the result for yourself. In my ‘list customers’ page, I’m building the link to the details page in a very object-oriented way:

Here’s is what our page will look like:

And here is the details page. Notice the URL. If you scroll up you’ll see that I never told MVC to call the parameter “targetCustomer”, but MVC automatically figured that out because that’s what the parameter is named in my “Details” method.

Testing Your Converter

As I stated above, I wanted to mention why this approach is good in terms of testability. Basically, because this bit of functionality is so small and specific, it is fully testable. You can use your favorite ‘mock’ framework to create a FakeHttp request with your token in the query string, and see if it correctly creates the Customer class.

As a side note: don’t forget that my model binder is hitting the data access layer, so if you are going to create unit tests you’ll want to also mock the DAL as well.

And now, here is the solution (compiled for Visual Studio 2008 SP1, ASP.NET MVC Preview 5): SingingEels_MVC_ModelBinders.zip

For those of you who are not familiar with Test Driven Development (TDD) or it’s benefits, consider the following scenario. Let’s assume that you have been contracted to build a site that deals with customer management. One of the client’s business rules is that customers must have at least a first name, last name and a zip code. This is a fairly straight forward request that will help us easily get into TDD.

Creating MVC Apps With Unit Tests

To prove that MVC is meant for testing, the Visual Studio template for a new ASP.NET MVC (Preview 5) project will automatically ask if you want to include a Unit Test project as well.

The default Test Project that comes with the ASP.NET MVC Visual Studio template is pretty basic, and includes a test class for each of the default Controller’s that come with your MVC app.

So, the steps to start our project are very simple:

1. File -> New -> Project
2. ASP.NET MVC Web Application
3. Yes, create a unit test project.

Business Rules as Tests

So, after learning what our business rules are, our next step in TDD is to express those business rules in the form of unit tests. To do this, we’ll add a class to our Test Project that will handle testing all things “Customers” related. We’ll need to decorate the class with the “TestClass” attribute, and each method with the “TestMethod” attribute. Our “customers test class” should look like this:

Now that we have a stub for our tests, we need to do a *little* bit of implementing our code in our CustomersController class in our ASP.NET MVC app. All we are going to do is create the method stub that is responsible for creating new customers. Once we do that, we can come back and finish our test method.

I mentioned earlier in the article that using a ModelBinder will make writing tests easier, and that may seem confusing at first. ModelBinders are run by the ASP.NET MVC framework, and will not be used by our Test Project, so how can they help in writing unit tests?

The answer is simple: Object Oriented Programming. Basically, because ModelBinders allow me to write my ASP.NET MVC Action Methods with complex objects as parameters, I can test against them in a much more OO fashion. Example:

So now we are ready to write our tests, but first we should mention a little “gotcha” that needs to be addressed. Because I only want to test my business rules, and not the code that ultimately writes the customer record to the database, I need to prevent my code from actually running the “store in database” part of my code. This is known as “mocking”.

Testing One Step at a Time

There are three pieces to our business rule that we are going to test individually: Required first name, last name and zip. To do this, we’re going to create an instance of our CustomersController, and call Create method. We’re going to pass in a customer object that *should fail validation*, and then we’ll check to make sure that, in fact, the Create method did fail.

This may seem odd (to hope for failure), but again remember that we want to test to make sure that validation is working, so we have to pass in bad data and look for the validation to come back.

Here’s our code that we’ll put inside of our “EnsureRequiredFields” method mentioned earlier in the article:

Now, when we run our tests in Visual Studio we will fail until we code the appropriate validation in our Create method. Here’s what that will look like:

Now you keep coding your app until you pass that test (which in this case should be pretty easy). So, once we add this code to our Create method, we’ll be good to go:

Conclusion

Hopefully this article has been able to demonstrate how easy it is to start down the path of TDD with the ASP.NET MVC framework. The demo project for this article can be downloaded here: MvcDemo_Testing_CreateCustomer.zip.

Source:singingeels.com

To begin with, we need to define the list of items that we are going to resolve in this article, as well as the list of rules/methods we are going to use to determine the worth and quality of these items. By the end of this article we will resolve:

1. Does the use of ModelBinders hinder the URL in anyway? Can we still achieve “RESTful” URLs if we use ModelBinders?
2. In what ways do ASP.NET MVC ModelBinders compare to the ViewState feature of ASP.NET WebForms?
3. We have demonstrated that we *can* use ModelBinders to recreate stateful objects from a database, but *should* we ever do that? Are there any benefits? Are we violating cosmic laws?

Examining the Issues

The first item may seem odd as ModelBinders have nothing to do with your URL, but for some reason multiple comments were made (on a previous article) expressing concerns for such. The second question is good to examine because MVC doesn’t have the ability to use the ViewState, so we’ll see how to cover some web-development-challenges with ModelBinders that we might have solved with the ViewState in the past. The final topic to cover is probably the most important, and is definitely the most controversial. As such, we will use the following rules to determine a good solution:

1. Does the solution fit one or both of the main pillars of the MVC design pattern – Testability and Separating Concerns?
2. Does the solution provide practical benefits to the developer?
3. And finally, since the responsibility of communicating with the “Model” falls to the “Controller”, are we violating MVC by using ModelBinders in the process of retrieving objects from the database?

ModelBinders and RESTful URLs

Because ModelBinders are not used by either the Routing Engine or ASP.NET MVC when creating links, they really play no part in the making or breaking RESTful URLs. This misconception may have arisen because the previous article showed a query string variable (“?targetCustomer=blah”) being passed to the ModelBinder. This may have made it seem that the URL was dependant on the ModelBinder, or that the ModelBinder was relying on the URL. This is not the case at all. ASP.NET MVC was passing the “targetCustomer” property to the ModelBinder only because there was a matching entry in the “RouteData” collection (which in this case happened to come from the URL).

The URL “/Home/Details?targetCustomer=12345″ could have been expressed as “/Customers/Details/12345″ just by changing how we setup our routes. So to clarify the point again: ModelBinders do not have anything to do with the forming of URLs in an MVC application. To achieve RESTful URLs in an ASP.NET application, you would use the ASP.NET Routing Engine.

MVC ModelBinders Compared to WebForms ViewState

Since web applications are built on a disconnected framework, web developers who want to simulate a stateful web application have to overcome the challenge of rebuilding the ‘state’ of the application upon the next post to the server. In ASP.NET WebForms, the ViewState handled this responsibility. One common scenario that was handled with the ViewState is that of building a dynamic amount of input fields back into “objects” (TextBoxes, DropDownLists, etc) on the server.

How would ModelBinders handle that scenario? The answer to that is fairly simple, and we still achieve the desired result of transforming the HTTP post into objects on the server. Let’s assume that we have a form that allows users to enter multiple addresses to associate with their account. The form is dynamic and allows the user to keep adding, or deleting addresses in JavaScript, but ultimately we need to post this variable amount of input fields to the server and rebuild them as objects. Here is what we could do with ModelBinders:

Then, to register our ModelBinder so that all “Address[]” parameters for my ActionMethods will know how to build themselves, we’ll simply add this line to our Global.asax file:

The end result will look like this:

As is simply demonstrated, ModelBinders can be used to solve many of the same challenges that the ViewState has solved for traditional ASP.NET. Does this mean that ModelBinders and the ViewState are synonymous? By no means! The technologies are different, their design and purpose are different. The similarities are in their ability to bring a more object-oriented way of programming to stateless web applications.

Restoring Stateful Objects with ModelBinders

The final section of this article will deal with the controversial topic of rebuilding an object that lives in a database with a ModelBinder. It seems that rebuilding an object from anywhere else is “fine”, but the moment we introduce a stateful object, people tend to get very nervous. Are we violating cosmic laws? Let’s see.

In the Model-View-Controller (MVC) design pattern, the responsibility of communicating with the Model (the database) falls to the Controller. ModelBinders have nothing to do with the MVC design pattern, but rather they are simply a ‘helper feature’ of “ASP.NET MVC” to provide a more object-oriented (and therefore more testable) approach to coding your ActionMethods.

In the previous article we inherited from the DefaultModelBinder class, and implemented our functionality that way. In this next example we are going to add the IModelBinder attribute to our Controller itself. This way, we can still feel good about “the Controller accesses the Model” when it comes to rebuilding stateful objects, but we still get the concrete benefits that ModelBinders provide. Here’s our code (abbreviated here, full code in downloadable solution at the end):

Now that this simple “middle-man” instance has been built, our Controller can retrieve the object from the database (as it normally would have anyway). So, you may be wondering: “why the song and dance?” (Meaning, why did we do all this work… what benefits do we get?)

Here are the direct benefits that we achieve from the above methodology:

1. Since we can now code our ActionMethods to take concrete objects (instead of parsing the HttpRequest for them), we are able to write unit tests *much* easier. Take for example the simple unit test that says “if a customer was not found, redirect to the customer search page.” If you didn’t use a ModelBinder, you would have to “mock” up your database calls, and fake it so that passing in one ID will return a customer, then fake it so that passing in a different ID will return null, *then* you can finally test your logic. However, using a ModelBinder as demonstrated in this article, you can test the logic with absolutely zero mocking, just by calling “Display(new Customer())” and “Display(null)” – amazing!
2. We are holding true to the Single Responsibility Principal and the Separating Concerns patterns much stronger. If you think about it, the method “DisplayCustomer(int customerID)” has the responsibility to do two things: 1) get the customer, then 2) display it. Whereas using ModelBinders lets us make the method “DisplayCustomer(Customer c)” – now we only have one task: display it – beautiful!
3. Even developers who do not use TDD or Separating Concerns will benefit in this way: Because you can have dozens of methods that require restoring your “Customer” object (or any other object) from the database, you would have to code this logic in a single place and call it in every one of those methods. Using ModelBinders lets you skip one of those steps. You still have to code the logic, but ASP.NET MVC will automatically call it for you because you registered the type “Customer” with your ModelBinder one time – awesome!

In Conclusion

The purpose of this article was to show that even though ASP.NET MVC is realtively young, it has some powerful and compelling features. Just this one topic alone of ModelBinders has contributed much buzz, including two articles here on SingingEels which doesn’t happen often for one feature.

In a talk that I recently watched online, Ken Robinson said that “if you’re not prepared to be wrong, you’ll never come up with anything original.” If nothing else, I hope that my risky usage of new technologies encourages you to experiment with code some more yourself.

Here is the full solution (Visual Studio 2008 SP1, MVC Preview 5). Enjoy: SingingEels_MVC_ModelBindersPart2.zip

Source:singingeels.com

This article will demonstrate some basic AJAX functionality that comes with the ASP.NET MVC framework. We’ll also see how simple it is to get the same usefulness of our web application even if we disable JavaScript capabilities in our browser.

Our demo site will have a “news” section where users can view the latest news, and subscribe to our newsletter. This functionality will be provided through AJAX calls. Our goal is to achieve this same functionality for non-ajax-enabled browsers without duplicating a lot of work.

AJAX Extensions in ASP.NET MVC

If you’ve been playing around in ASP.NET MVC even a little, you likely have noticed how simple it is to use AJAX in your web app. Take for example creating a link to our “News List” page (which is actually in our demo app). To make a standard link that goes to the “News” controller and executes the “List” action would look something like this:

But what would we do if we wanted that link to use AJAX to pull the latest news and update a simple <div> on our page? All we would have to do is use the “Ajax.ActionLink” method, and supply an extra parameter that has the ‘AJAX options’ in there. Here’s what that would look like:

That code will build an HTML link that also has some JavaScript in the onclick event for handling the AJAX stuff. It’s important to know that since this is a regular old HTML link, if the JavaScript part fails (either due to a bug, or if scripts are disabled), then the browser will navigate to the URL as if there was no JavaScript at all. And that brings us to the next point!

Coding Your ActionMethod to Detect AJAX Requests

Because one of our main goals is not to have to duplicate a lot of work, we want the same code to run for the user if he’s using AJAX or not. The only part that has to change really is the “View” that gets sent back to the client. In order to accomplish this, we’re going to use the “IsMvcAjaxRequest” method that comes in the System.Web.Mvc.Ajax namespace (in the AjaxExtensions class).

And then to use it in our ActionMethod, here’s what we would do:

Notice that we don’t have to duplicate any logic for getting the latest news. The only bit of custom logic that is needed is to determine which view to send. This can be done for form posts too (as you can see in the screen shots below or by downloading the project at the end of the article). Here’s what the results of the above will look like for an AJAX enabled, and a non-AJAX enabled browser:

After clicking on the “view news” link with AJAX enabled:

After clicking “view news” with JavaScript (and therefore AJAX) disabled:

If you notice the URLs in the second and third screen shots, you’ll see that with AJAX disabled the browser simply navigated to where the link was pointing. Thus, a graceful degradation was achieved.

Conclusion

With little effort, we achieved an AJAX enabled ASP.NET MVC site, and cleanly/gracefully allowed non-AJAX users to enjoy the same benefits of our demo app. The project was written in Visual Studio 2008 SP1 with the ASP.NET MVC Beta 1 bits installed. Because the DLL’s are bin-deployed, you should be able to download and run the project even if you don’t have the MVC beta install. Check it out for yourself: SingingEels_MvcAjaxMashup.zip

Source:singingeels.com

It’s true that much of the ASP.NET framework has been pluggable for a while (example: Membership and Profiles). Also, we have always had a choice of server-side language from the start (example: C# or VB). But only recently with the birth of ASP.NET MVC do we have a clean and straight forward solution to swap out the “ASP” language for our own.

By the end of this article, we will have made our own language (called “HoTMeaT”), we will have registered our custom ViewEngine and we will notice just how easy it is to swap out this seemingly ‘fixed’ area of ASP.NET. At the end of the article, you can download the entire demo project – including the source code for the language.

A Sneak Peek Into the Language

Before we get into a “step-by-step” of how to write our own ViewEngine, I want to show you how amazing this new “HoTMeaT” language is going to look. Since I’m currently on a WPF kick, I’m going to copy some of that great functionality by taking “binding” to the next level.

Here’s the code for the Customers/List page. We won’t need to do anything different in our code, because really, the “Controller” doesn’t care about how “View” will look. It’s only responsible for getting the data.

Now, how would you display a list of those people in your own custom HTML template? Well, if you were using WebForms (traditional ASP.NET), you would probably use a Repeater and then do data binding in the code behind. If you are using ASP.NET MVC, you would probably just write a for-loop with sloppy inline ASP. But, with HoTMeaT…

And here’s the HTML that it generates:

Now that’s pretty cool. But before we go on, there is a myth that needs to be dispelled. I’ve heard multiple people say that if you use / build a custom ViewEngine that you’ll suffer some great performance hit. That is completely not true. The HoTMeaT view engine (which parses the HTML for custom tags, and performs data binding at runtime for each request) runs at 0.00015 seconds. That means that it can handle hundreds of requests per second from my laptop. So no, there are no performance concerns (unless of course you’re a bad programmer).

Creating and Registering your Custom ViewEngine

ASP.NET MVC was built to allow developers to change certain parts of the pipe-line in a similar way. For example, creating and registering a ViewEngine is much like creating your own custom model binder and then registering it at runtime. We’ll create a class that inherits from “IViewEngine”. Then (just like with registering a ModelBinder) we’ll register our custom ViewEngine in the Global.asax file. Here’s the code:

Inside of our ViewEngine class we only have to provide the functionality for two methods – CreateView and CreatePartialView. Those methods will return an instance of a class that implements “IView”. The View class has one method in it – Render.

Here’s the code for our ViewEngine:

How Do I Build my View?

So now that we’ve created our ViewEngine and registered it in the Global.asax, we have to actually do something in our View class. As was mentioned above, the only method that we have to implement is “Render”, which passes in the viewContext (which gives us the Controller, ViewData, RouteData, etc) and a TextWriter for us to render to. So, if you wanted to make a *very* basic view engine that simply shells out a static file, you could do this:

And that’s really it! We’ve just made our own ViewEngine which creates a simple View that writes out the contents of a file. Now, you may be wondering what happened to my great new “HoTMeaT” language where we could do all that great data-binding right in our HTML. If you want to see all that code, then you can download the source project and take a look at the code yourself. That code is intentionally left that so as not to detract from the main point of the article. So here’s the full demo project with all of the code including the “HotMeatViewEngine”: SingingEels_CustomMvcViewEngine.zip

So What Is “HoT MeaT”?

Back in college I had a very “build it yourself to learn it” mentality (and really I still do today). So, I wanted to understand Sockets and client/server programming, so I made my own “web server”. All it did was shell out static HTML files. Then for some reason, my friend and I decided that we would make our own language: HTMT (“Hyper Text Meta Transformation” – aka “HoT MeaT”). I think we were bored in C++ 101, and bordom leads to invention! We got to the point of displaying the time on the server and basically stopped there. So that’s the story behind the name.

Source:singingeels.com