Eric Duncan : Asp.Net Mvc, Geek Stuff

Managed Extensibility Framework (MEF) - Microsoft's Official Inversion of Control Container

Eric A. Duncan — Tue, 16 Feb 2010 00:50:00 GMT

This new Microsoft feature in .NET Framework 4 is a programming model for reusing components, very similar to those Inversion of Control container frameworks out there that we all know and love (Castle Windsor, Structured Map, their own Unity from the Patterns and Practices team and etc). Now, they have built their own to address the pain points of these frameworks called the Managed Extensibility Framework, or MEF for short.

I was pleasantly surprised this weekend when reading the February 02010's issue of MSDN Magazine. Getting up-to-speed on some new features in .NET Framework 4, I saw the headline "Building Composable Apps in .NET 4 with the Managed Extensibility Framework" by Glenn Block. Yeah, it just rolls off your tongue eh? So I decided I had a few minutes while waiting for the water to boil and scanned the article. I am glad I did.

In this post, I will try to give a very brief overview on how to use MEF coming from a background of using other Inversion of Control (IoC) containers, including some of the gotchas that you must be aware of during the switch. Yeah, you will want to make the switch - the switch away from those other bulky frameworks. I, for one, am officially announcing my abandonment of Castle and Unity for all future projects. Because once you add-in .NET 4's new data annotations for seriously improved validation, mixed with MEF, the only other 3rd party component I am left with is Castle's Logger abstraction - which I am hoping I can find a replacement for with .NET 4's new features.

MEF Terminology

First and fore-most for those of you already using an IoC container, it's time for a quick review on what MEF calls a few things and concepts. Below is a table I whipped up to help compare the two terminologies (the MEF portions largely taken from Glenn's excellent article).

Below is an image from Glenn's article that helps visualize the concepts above of MEF.

You can see that the overall concept is called Composition. A 'part' is the type or service you want to export. The part (or parts) is marked for Export via Contracts (which are automatic). And other parts that want to ask for another part can do so by Importing.

Managed Extensibility Framework - Why they built it

Glenn mentions in the article that they needed a way to compose of reusable types or components in the up coming Visual Studio 2010, Oslo, Acropolis and I am sure many more. What is important to note is why they created one themselves, instead of using Unity or alike. Glenn mentions some key points:

Third-party Extensibility (allowing vendors to generate plug-ins for Visual Studio, or your own application, with minimal work on your part now)
Other frameworks were too heavyweight for a simple programming model.
Or other frameworks required too much effort on the part of either the host or the extension developer.

Those last two is what struck a cord with me, and got my attention. Try to sit back and think about how you would allow your applications to be extended with Castle, StructureMap or even Unity. That's a lot of work, a lot of 3rd party assemblies to wire up and configure properly. Especially if you want runtime changes, which MEF supports out of the box with no configuration.

That last point is particularly interesting. All too often I see a released developer framework or contrib project by a group of inspired individuals. This is great and all, but those projects quickly grow to be a large project requiring documentation, support, and even refactorings for performance.

It got me thinking a lot about what I see wrong with Castle - only two things, it's learning curve and size. While Unity was very well documented, it comes with some significant bloat and only what I can refer to as hoop-jumping. The earlier versions of Unity violated Dependency Injection pricipals and concepts (no ctor injection!). Perfect example of refactoring.

MEF really strives to resolve all of these issues, with some extremely simple programming models that I will show you below.

MEF Programming Models - Straight Attributed Declarations

Another rip from Glenn's article. But he did it so well.

Developers consume MEF through a programming model. A programming model provides a means to declare components as MEF parts. Out of the box, MEF provides an attributed programming model, which will be the main focus of this article. That model is just one of many possible programming models that MEF enables. MEF's core API is completely agnostic to attributes.

Yep, you heard that right. MEF supports Attributes - for out-of-the-box functionality. No configuration, no setup, nothing. This is so much easier than you are even thinking. So much so, I feel guilty by writing all of this text. Let's just show you how it's done now.

The Blog "Hello World" Snippets

As what seems to be an invasion, the common Hello World for websites these days are blogs. So without further delay, here's some code snippets.

The post object


public partial class Post
{
	public Int32 PostId { get; set; }
	public String Title { get; set; }
	public String Description { get; set; }
	public String Body { get; set; }
	public Guid AuthorId { get; set; }
}

And the PostService that will service the post.


[Export(typeof(IPostService))]
public class PostService : IPostService
{
	[Import]
	public IPostRepository PostRepository { get; set; }

	public Post FetchById(Int32 postId)
	{
		return
			(from p in PostRepository.GetAll()
			 where p.PostId == postId
			 select p as Post).FirstOrDefault();
	}
}

Please note that the above code is not production-code. You should always provide proper cache, concurrency and disposable patterns. This code has been cleaned up for easier reading.

Notice that the PostService has been marked to be exportable, using a specific contract type for IPostService. Now, you do not have to specify the contract type or name. You can simply use [Export]. But remember, we do want to allow for simply extensibility in the future by plugging in different components to be served during composition. How to do that? Easy, just specify the interface type as the contract. Now how easy was that?

Also, notice that we have a dependency on IPostRepository. This is marked with the simple [Import] attribute. It does exactly as you think. MEF composes the first part that matches the contract for IPostRepository and supplies it

Now, some will cry fowl here since I am not directly injecting IPostRepository, or not demanding it in the constructor. Yes, MEF fully supports constructor injection. But, there is a few gotchas you have to be aware of with MEF and constructor composition that I get into a little further down. There's also a new pattern I am designing, when mixed with .NET 4 and some nifty T4 templates I'm tinkering with. That's another article I'll write though. Check the comments, or leave a comment for more information on, "Managing BDD Contexts and Mocks Automatically with .NET 4, MEF, and T4 Templates." Nice. I just named my next blog post.

Constructor Dependency Injection - MEF Gotcha

As mentioned above, constructor injection is a bit tricky with MEF. There are some rules to follow:

MEF assumes all parameters are imports, making the import attribute unnecessary. I leave it up to the reader to figure out how to get around this.
Recomposition is not supported on constructor parameters.

That last one is almost a deal breaker for me. Recomposition is a feature of MEF that allows parts to automatically have their imports updated as new matching exports appear in the system. Given, this isn't the case with most websites out there. It's an issue for websites and applications that want to support dynamic (e.g. downloadable) plugins. The plugins would overwrite, at runtime, certain contracts and therefore allow the parts to automatically be updated with the new plugin versions - all without an application restart!

So with that said (and you will never be developing plugins right?), you can use constructor injection with MEF as follows.


[Export(typeof(IPostService))]
public class PostService : IPostService
{
	private IPostRepository _postRepo;
	private IUserRepository _userRepo

	[ImportingConstructor]
	public PostService(IPostRepository postRepo, IUserRepository userRepo)
	{
		_postRepo = postRepo;
		_userRepo = userRepo;
	}

	public Post FetchById(Int32 postId)
	{
		return
			(from p in _postRepo.GetAll()
			 where p.PostId == postId
			 select p as Post).FirstOrDefault();
	}
}

Don't fret too much though about the all-or-nothing constructor. You have a Factory option later on in this post.

Bootstrapping MEF for Application Startup

Glenn nailed it right on the head when he called this procedure "bootstrapping." I've always struggled with the proper terminology for this composition process with other Inversion of Control containers. Bootstrapping. Yep, just like my hacked MP3 players have.

To get things up and running, you will need to to insert some bootstrapping code for your application. This code is required with any type of IoC container, and with MEF as well.

Below is a small code snippet from a typical ASP.NET MVC 2 global.asax file. Notice I added the two using blocks at the end of the Application_Start(). This process would be the same for any type of application you have.


using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;

protected void Application_Start()
{
	AreaRegistration.RegisterAllAreas();

	RegisterRoutes(RouteTable.Routes);

	using (var catalog = new DirectoryCatalog(@".\"))
	{
		using (var container = new CompositionContainer(catalog))
		{
			container.ComposeParts(this);
		}
	}
}

Now, this code is running from with the website assembly. If you, like me, create a seperate assembly to hold your Domain and Repository models, then you simply reference the assembly by replacing the 'this' keyword with Assembly.GetAssembly(typeof(MyProject.Domain)). And yes, you can reference multiple catalogs and assemblies and build up your list as well.

Note that I included the namespaces here. This is important as normally this bootstrapping code is in the Hosting namespace. What they don't tell you is there is an extension in the namespace one higher for CompositionContainer, that enables the ComposeParts() extension method in the System.ComponentModel.Composition namespace.

There are tons of options here with the composition containers. Please refer to the .NET 4 documentation on MEF, as well as Glenn's article for a few more tips. You can specify an assembly to reference for the catalog. You can have aggregated catalogs for grouping/namespacing purposes. And yet, you can still have that aged-old configuration file if you really really really want to manually register (export) each type.

All Parts are Singletons, out of the box

Yep. All of your part's instances are composed and referenced throughout all of your code as singletons (or "statics"). This is a great solution for that stubborn developer you may have working in your group that just won't let go of static managers. Make it instance based, and slap an [Export] on it. Done, now use [Import] wherever you like.

This is important to note because Castle and StructuredMap both default to transient composition (Unity uses whatever you configured the container to use as default). So, make sure you are coding to be thread-safe if you are making the switch over to MEF.

But do not fret, it's easy to specify the lifestyle within the contract definitions. There are three possible configurations you can set with the [PartCreationPolicy()] attribute:

CreationPolicy.Shared (singleton, default)
CreationPolicy.NonShared (transient)
CreationPolicy.Any

The "Any" option is interesting as it leaves it up to the context configuration of the host and/or the configuration of the [Import] contract to specify. You can use RequiredCreationPolicy on the [Import] contract definition to specify the preference.


[PartCreationPolicy(CreationPolicy.Any)]
[Export(typeof(IUserAccountService))]
public class UserAccountService : IUserAccountService
{
	...
}

public class Post
{
	public Int32 PostId { get; set; }
	public String Title { get; set; }
	...

	[Import(RequiredCreationPolicy=CreationPolicy.NonShared]
	public IUserService UserService { get; set; }
}

There is a problem with this concept though. With a current project we are working on at the moment, we identified the need to have a security context around our services to ensure the current WebRequest has the correct security credentials. With this, we elected to use Castle's WebRequest lifestyle feature. Sadly, this is not possible (yet) with the PartCreationPolicy. So it is left up to the implementer to handle custom composition on their own with a Factory pattern (see below).

Lazy Loading within Entities

Those of you that are wanting Lazy Loading within your entities, but are struggling with a solution that is compatible with Inversion of Control, fear not! The answer is now possible with MEF.


public partial class Post
{
	[Range(0, Int32.MaxValue)]
	public Int32 PostId { get; set; }
	
	[Required, StringLength(64, MinimumLength = 5)]
	public String Title { get; set; }

	[Required, StringLength(1024, MinimumLength = 5)]
	public String Description { get; set; }

	[Required, StringLength(Int32.MaxValue, MinimumLength = 5)]
	public String Body { get; set; }

	[Required]
	public Guid AuthorId { get; set; }

	[Import]
	public IUserService UserService { get; set; }

	private User _user;
	public User Author
	{
		get
		{
			if (_user == null)
				_user = UserService.FetchById(this.AuthorId);
			return _user;
		}
	}
}

With our updated Post entity, notice we now have a dependency on IUserService marked with the [Import] attribute. Yep, MEF composes that for you, and you have the UserService to access your lazy objects as needed.

Using MEF as a Static Wrapper

Time and time again I find myself writing wrapper classes around static members of a 3rd party component, just so I can unit test my code without having to rely on that static class. Using MEF, if you haven't guesses already, is just as easy as you might think.


public class Loggerpart
{
	[Export]
	public ILogger Logger
	{
		get
		{
			return LogManager.GetLogger("LoggerInstance", "config");
		}
	}
}

This pattern allows you to make a wrapper around any 3rd party or legacy code.

MEF Composition with a Factory Pattern

Here's another one not in Glenn's article. How to use MEF with a factory pattern to initiate a complex type.


public class UserService : IUserService
{
	public UserService(ISecurityContext securityContext)
	{
		...
	}
}

public class UserServiceFactory
{
	[Export(typeof(IUserService))]
	[PartCreationPolicy(CreationPolicy.Shared)]
	public IUserService Instance
	{
		get
		{
			var context = HttpContext.Current;
			var securityContext = 
				SecurityContextProvider.Setup(context)
			return new UserService(securityContext);
		}
	}
}

Notice how the UserService is not exported? Instead, we designate a property member of UserServiceFactory called Instance as the Export composition location.

Remember, you are only Exporting for Composition at runtime. Nothing gets composed during your unit tests, as you are mocking them. So anywhere you use [Import] will be still be mockable for any of your unit tests with this pattern.

Exporting with Multiple Contracts

Here's a nice trick, you can specify multiple Export contracts for multiple types. Why would you do this? If you are a big DDD follower, you may be using IUserService and IAccountService combined to give you an UserAccountService part.


[Export(typeof(IUserService))]
[Export(typeof(IAccountService))]
public class UserAccountService : IUserService, IAccountService
{
	...
}

MEF Does Not Blow Up on Rejection

This one is going to take some getting used to. As Glenn mentions, MEF does not throw exceptions if a part cannot be satisfied. It simply will not exist in the object graph for MEF to return - you'll get a null, and will most likely see a NullReferenceException in your containing code that is trying to use the part you wanted to import.

MEF will simply reject the request for the Import of a part for a number of reasons. For example, if there is no part defined as the correct Export contract type. Say you wanted to import IUserService, but only exported UserService with [Export] and no contract type of IUserService was defined. That was the typical one I found myself forgetting to do. As recommended above, always include the Contract Type when designated a part as Export with [Export(typeof(IUserService))].

I agree that MEF's Rejection policy is a power feature because it stabilizes the code and allows debugging. Glenn links to a good article on why to ensure application stability: http://blogs.msdn.com/gblock/archive/2009/08/02/stable-composition-in-mef-preview-6.aspx

But in short, if you get Rejection happening quite often, check your Export contract definition on your part.

In Summary

As you can see, it is dead simple to use MEF. The Export functionality is what was missing with Unity, and completely with all other IoC containers. And, it's what gives MEF such great, simplistic power. I highly recommend reading through Glenn's complete article, as he covers a few other concepts such as using the new Lazy<T> for importing lazy exports and metadata.

Some additional things Glenn covers is the very strong support for debugging and tracing, things you want to be aware of if you use MEF even moderately. He also hints at the up-n-coming support for MEF with IronRuby. He also covers some external links, which I will list here (for my own archiving purposes):

Customizing Container Behavior Part 2 of N - Defaults for Facilities
MEF Analysis Tool (mefx) for .NET 4.0 for debugging those contracts in large projects
A Crash Course on the MEF Primitives for the underlying "quantum universe of MEF, its über extensibility points" as Glenn says

Once concept I am tinkering with is utilizing the [Import] attribute in the attributed programming model of MEF to define the complete contexts of my BDD tests for me with all dependencies already mocked up and ready, with T4 templates largely driving that effort.

MEF wacked me upside the head. It does everything right, and even allowed me to step back and realized, "Dang. I was bloating my code." Yes, they have done it right. So right that the next project I am starting this week will be on Visual Studio 2010 RC - not even released yet.

Html.RenderAction for ASP.NET MVC 1.0

Eric A. Duncan — Thu, 24 Sep 2009 16:04:00 GMT

The ASP.NET MVC 1.0 Futures assembly (that is not included with ASP.NET MVC 1.0) has a powerful HtmlHelper extension method called RenderAction(). It sounds similar to the Html extension method called RenderPartial() for a good reason. RenderAction() executes an action on a controller, allowing you to move your logic out of the views.

The problem with Html.RenderPartial()

There is no direct problem with this. It is just that developers are left with only the ability to render a Partial View. What if you want that partial view to act on model properties you pass into that partial view? What if you need to access the ambient values in the Routes collection to render some specifics? Unfortunately, developers are only left with RenderPartial() which only gives you access to a partial view. If you really need this logic, you have no choice but to put it into the partial view. Or, to put it into your controller’s action method that calls the view that calls the partialviews. Needless to say, that’s a bit hokey.

What Html.RenderAction<TController>() Resolves

It gives you the power of moving that complex View and Partial View logic to a Controller’s Action, where it belongs! Think of it as a “Render Partial Action” method of where you can call back into a controller to render some logic. This gives you the ability to clean up your partial views now by removing that logic and placing it on a controller’s action, that renders the partial view when done. The syntax looks like:

<% Html.RenderAction<ProductController>(c => c.RenderProductResults()); %>
<!-- Or... //-->
<%= Html.RenderAction("RenderPartialResults", "Product"); %>

Put simply, this renders an action on a controller directly in your view. You may be thinking “big deal”, but I assure you this is a big deal in large complex MVC sites. Having the power to abstract or breakup your controller’s actions into multiple partial-actions and multiple views is very powerful. Instead of relying on the 1 controller' action to wire up all of the data for all of the views, partial views, and logic for the views. Now, you can just focus on that one section - and abstract the rest into reusable parts.

You may be wondering where this extension method is with your ASP.NET MVC project. As mentioned above, it is part of the Futures extension of the ASP.NET MVC project at codeplex.

ASP.NET MVC Sidebar Widget Example

The current pattern suggests you use Html.RenderPartial to render those partial views as your sidebar widgets. What if you want those widgets to be more complex? What if you want those widgets to act on the the current Route? Well, you are left with little options with RenderPartial. Instead, you want to use RenderAction to call an action on a controller to handle that logic.

Assume we are viewing a blog post entry and on the right, we want a sidebar widget for related posts. To do this, first create an action on a controller called RelatedPosts().

public ActionResult RelatedPosts(Int32 postID)
{       
  // some complex logic, or simple logic, can go here now…
  //
  
  if (postID < 1)
    return PartialView(“NoRelatedPosts”);
  var relatedPosts =
    _postService.FetchRelatedPosts(postID);
  
  if (relatedPosts.Count > 0)
   return PartialView("RelatedPosts", relatedPosts);
  else
    return PartialView(“NoRelatedPosts”);
}

Notice how the logic here accounts for empty or no results, and returns an a different partial view? Using RenderPartial(), this is logic could only be reflected with inline IF ELSE brackets within your PartialView - and ugly spaghetti mess. Also, how would you even retrieve the related posts collection? You have no choice but to obtain that collection back on the post entry view action - which should not be concerned about our little sidebar widget. All it should do is wire up the post. But, that is not the case with RenderPartial() - you have to wire up all of your data ahead of time in one large ViewModel with multiple entities dangling off of it.

No no. Let’s do it with RenderAction() and instead put this logic into the Controller (where it belongs, so we can test for it); and then, we can call it with the RenderAction() extension. We can do this now with a simple call within our larger post view like so:

<% Html.RenderAction<PostController>(c => c.RelatedPosts(Model.PostID)); %>

We instead kind of render a partial action by calling an action on a controller that handles the logic that we would otherwise have to put in the view. Now, our main post view action doesn’t have to be concerned about wiring up our sidebar partial view. We can just call RenderAction() in the view.

ASP.NET MVC AJAX Example using RenderAction

Taking an example from the book Profressional ASP.NET MVC 1.0, we’ll use the submitting a Form Using Ajax example to replace the limited RenderPartial() function with a richer RenderAction() from a Controller’s action to process the results more finely.

In the ProductController, you would add a new method with the signature RenderProductResults(IList<Product> products):

public ActionResult RenderProductResults(IList<Product> products)
{
    // insert some custom logic here, maybe even switch partial views, etc
    //
    if (products.Count > 0)
        return PartialView("ProductSearchResults", products);
    else
        return EmptyResult();
}

Now, you can update their ajax example to render this new action instead of the RenderPartial() from their example:

<h1>Product Search - jQuery</h1>
<form action="<%= Url.Action("ProductSearch") %>" method="post" id="jform">

  <%= Html.TextBox("query", null, new { size=40 }) %>
  <input type="submit" id="jsubmit" value="go" /> 

</form>

<div id="results2">
  <% Html.RenderAction<ProductController>(c => c.RenderProductResults(Model.Results)); %>
</div>

<script src="http://eduncan911.com/Scripts/jquery-1.3.2.js" type="text/javascript"> </script>
<script src="http://eduncan911.com/Scripts/jquery-form.js" type="text/javascript"> </script>
<script> 
  $(function() { 
    $('#jform').submit(function(){ 
      $('#jform').ajaxSubmit({ target: '#results2' }); 
      return false; 
    }); 
  });
</script>

Look for the Html.RenderAction line above. What this does is instead of rendering a partial view in the id=”results2” location, you can now render a “partial Action” with the Html.RenderAction() call. Notice that how we are also passing strongly typed parameters directly into the method? Yep, fully supported.

By using the RenderAction instead of RenderPartial, you have much more control over what happens with that rendering of the partial (now, rendering of the action). This gives you an excellent opportunity to remove that complex view logic you may have, and place it in an Action where it belongs!

Custom ViewEngines and Extensions

Now, you can also resolve this logic issue by creating custom ViewEngines, or extensions that expand upon the ViewEngine, HtmlHelper, or UrlHelper. But, I see those methods as more application-wide common logic (like pagers and server controls for display name). I do not see that as a solution for your one-off partial view for the ajax response to something. Think of how bloated your ViewEngine would get, or how many different ViewEngines you’d have to choose from. No, ViewEngine extensions have a place which I will post about as well.

Summary

When your views start getting complex and messy, it may be time to switch to a RenderAction to handle that logic. I know I have cleaned up quite a lot using it. Also, custom view engines have a place in their own right to abstract more global/common logic across the entire site.

Type Safety with ASP.NET MVC Futures

Eric A. Duncan — Tue, 22 Sep 2009 17:02:29 GMT

In this post, I will show you how to strongly type some parts of MVC to get rid of those “magic strings.” I will also publish a few extension methods that expand upon this concept later on. So, this is a continuation of my Mvc series that you can subscribe to.

ASP.NET MVC 1.0 Futures

You can download ASP.NET MVC 1.0 RTM from codeplex. You can even download the source code and step through what the framework is doing. What a lot of people overlook is an additional assembly available for download at these locations called ASP.NET MVC 1.0 Futures. You can download it from Codeplex from below:

Download ASP.NET MVC 1.0 Futures from CodePlex

This is a darling of an assembly using the namespace Microsoft.Web.Mvc. Usually these Microsoft “Futures” releases are developer code that did not get approved for RTM release. This assembly is no exception and includes a plethora of strongly typed extensions. The reason some of this code did not get approved was because some of it did not conform to Medium Trust requirements for the 1.0 release. So if you have a strict medium trust application, you may not be able to use the some of the code contained within the assembly.

I am not going to cover all of the extensions within this assembly. You can do that on your own with .NET Reflector. Instead, I am going to cover just a couple that you will be using on a daily basis.

To get started, go ahead and added a reference to the Microsoft.Web.Mvc assembly to your project. In addition, to make things a lot easier, go ahead and add a few namespaces to your web.config.

<namespaces>
  <add namespace="System.Web.Mvc"/>  
  <add namespace="System.Web.Mvc.Ajax"/>
  <add namespace="System.Web.Mvc.Html"/>
  <add namespace="System.Web.Routing"/>
  <add namespace="System.Linq"/>
  <add namespace="System.Collections.Generic"/> 

  <add namespace="AspNetMvcTypeSafety.Controllers"/>
  <add namespace="AspNetMvcTypeSafety.Models"/>
  <add namespace="Microsoft.Web.Mvc"/> <!-- Add this assembly -->  
</namespaces>

Hit CTRL-SHIFT-B to do a quick compile of your code (so the assembly is copied to your /bin). ASP.NET MVC 1.0 Futures is now available for your project. You’ll also note that I add my controllers and models’ namespaces. This is because you want them available from your views and controllers.

Strong Typed Html ActionLink<TController>

If you are already coding in ASP.NET MVC, you are using strings to reference controllers, actions, and views. An example to access to the MostRecent() action on a PostController would be something like:

<%-- // Old way--%> 
<%= Html.ActionLink(Model.DisplayName, "MostRecent", new { Controller="Post" }) %>

You have to create an anonymous type and reference a controller with “Post”, for the action method “MostRecent”. Using the Futures assembly, you’ll see a few new extension overloads for Html.ActionLink:

Html.ActionLink<TController>(
    Expression<Action<TController>> action, String linkText)
Html.ActionLink<TController>(
    Expression<Action<TController>> action, String linkText, object attributes)

So, now you can re-write the first example to get the MostRecent() action like so:

<%-- // New way --%>
<%= Html.ActionLink<PostController>(c => c.MostRecent(), Model.DisplayName)%>

Isn’t that much tidier? To break it down, TController is the controller you want to access an action method for. With it assigned as the generic type, now you have intellisense for your controller as the image below demonstrates.

This pattern even supports the parameters on your controller’s actions! For example, say you want to pass in a username property for a PostController action with the signature of MyPosts(String username). Using the old method, you have to pass it an anonymous type like so (again, using strings):

<%-- // Old way --%>
<%= Html.ActionLink(Model.DisplayName, "MyPosts", new { Controller="Post", id=Model.Username }) %>

With the Futures assembly, it’s a simple as this:

<%-- // New way --%>
<%= Html.ActionLink<PostController>(c => c.MyPosts(Model.Username), Model.DisplayName)%>

Notice that you pass the Model.Username parameter directly into the method c.MyPosts(), instead as an anonymous type like the old way. You even get the intellisense as well, as shown below:

Html RenderAction<TController>

This new function works exactly like the ActionLink<TController> above. No surprises.

<%-- // new way %>
<% Html.RenderAction<PostController>(c => c.MyPosts(Model.Username));%>

Strong Typed Html BeginForm<TController>

Again, using the ASP.NET MVC Futures assembly, this is already done for you. This one is a bit tricky though. You want to pass your values within the form’s scope, not the BeginForm method itself. But, if you leave the parameters blank for your method, the view will not render and you will be an exception. Intelliense actually gives you a hint by the red underline.

To get by this, you have to trick it and pass in some default values like so:

Yes, you can still pass a direct value into the method. And just like normal, if a route’s parameter does not match the name, it will be tacked on as a querystring.

Summary

That’s it for now. There are more to capitalize on within the Futures assembly such as the FileCollectionModelBinder for multiple files, the CookieTempDataProvider for setting a temp cookie only for the next request, or even the HtmlHelper extensions for Mailto() that wraps those ever daunting subject, body, multiple emails, etc all into a neat HtmlHelper.

For my next project, I will be developing heavy in Mvc across multiple sites. At that point, I am sure I will have more strongly typed extensions for things like RedirectToAction() at the controller level. I will post them as I run across them.

ASP.NET MVC

Eric A. Duncan — Tue, 22 Sep 2009 17:02:13 GMT

I am starting a new series that will be focusing on ASP.NET MVC design patterns. What I will be focusing on is enterprise-ready patterns and practices that scales across cloud computing, coding with type safety, and abstractions of WebForms-like server controls – using the MVC pattern. Steve Sanders and Phil Haack have about a year head start on everything-mvc, so I highly recommend reading up on their blogs for the basics and advanced solutions.

I will keep updating this post with each post for future references. So, bookmark it or you can subscribe to the series here.

You can also follow me on Twitter via eduncan911, if you can weed out my random thoughts from these postings.