routes.Add(new Route("{controller}/{action}/{id}", new MvcRouteHandler()) {
	Defaults = new RouteValueDictionary(new { action = "Index", id = (string)null })
});

…and you have a controller like this:

public class HomeController : Controller {
	public ActionResult Show(int id) {
		// do stuff
		return View();
	}
}

…then visiting a url like mysite.com/Home/Show/5 will automatically popuate the id parameter of the Show action with the value 5.

I thought it would be fun to see if I could get something similar working using WebForms. It actually turned out to be quite straightforward.

First, you’ll need to set up ASP.NET Routing to work with WebForms. I’m using Phil Haack’s WebFormRouting library which can be found here.

I’ve added an extension method to RouteCollection that allows me to declare routes like this:

RouteTable.Routes.MapWithAutoBinding("Customer/{CustomerId}").To("~/Customer.aspx");

In the code behind file for my customer.aspx page I can now declare a property like this:

public partial class Customer : Page {
	protected void Page_Load(object sender, EventArgs e) {
		customerNameLabel.Text = CustomerId;
	}

	[DataBind]
	public string CustomerId { get; set; }
}

So when I visit MySite.com/Customer/Jeremy the “CustomerId” property on the Customer.aspx page will automatically be set to “Jeremy”.

How does it work?

Calling RouteTable.MapWithAutoBinding will create a route using the AutoBoundWebFormRouteHandler which inherits from Phil Haack’s WebFormRouteHandler. After GetHttpHandler is called, reflection is used to find any properties on the page that have a DataBindAttribute.

The RequestContext is then passed to the PerformBinding method on the DataBindAttribute, which will find the appropriate value from the RouteData and invoke the property’s setter.

Taking it a stage further: using Linq to Sql

Just for fun, I thought I’d see if it was possible to automatically fetch an entity from the database based on the value in the RouteData in a similar way to Monorail’s ARDataBind attribute. I thought I’d try and use Linq to SQL as I haven’t used this in a project before.

The first stage was to inherit from the DataBindAttribute class and override the PerformBinding method. Now, instead of just passing the value from the RouteData to the property, we have to run a linq query using the value from the route data as the primary key. This is very easy to do thanks to the Dynamic Linq provider that Microsoft ship in the Visual Studio 2008 samples folder.

So, now the property on the Customer.aspx page can look like this:

[LinqBind("CustomerId")]
public Customer Cust { get; set; }

The “CustomerId” being passed into the LinqBind attribute tells the binder the name of the RouteData value it should use as the primary key for the Customer entity. Currently, this only works with single primary keys, although it should be possible to get it work with composite keys too.

Visiting mysite.com/customer/ALFKI will now run a linq query to load a customer from the Customers table using the customer id of “ALFKI” and then set the “Cust” property to be a reference to this entity.

It is also necessary to tell the LinqBindAttribute which DataContext should be used to do the fetching. This can be set in the Global.asax’s Application_Start method using a delegate:

LinqBindAttribute.DataContextFactory = () => new MyDataContext();

I’ve uploaded the code here if anyone wants to play with it.

Disclaimer: The zip file contains Phil Haack’s WebFormRouting.dll and Microsoft’s Dynamic Linq provider from the Visual Studio 2008 samples.

The main addition to V2.6 is support for a full Linq provider, so writing queries in LLBLGen just became a lot easier. V2.6 also includes a new Prefetching API which I wrote during the 2.6 beta period, which Frans then included in the product.

For example, to eagerly load a Customer -> Orders relationship prior to v2.6, you’d have to do something like this:

EntityCollection<CustomerEntity> customers = new EntityCollection<CustomerEntity>(new CustomerEntityFactory());

PrefetchPath2 prefetcher = new PrefetchPath2(EntityType.Customer);
prefetcher.Add(CustomerEntity.PrefetchPathOrders);

using(DataAccessAdapter adapter = new DataAccessAdapter()) {
	adapter.FetchEntityCollection(customers, null, prefetcher);
}

Now, with the lambda prefetching API you can do this:

using(var adapter = new DataAccessAdapter()) {
	var linq = new LinqMetaData(adapter);

	var customers = (from c in linq.Customers select c)
				.WithPath(path => path.Prefetch(c => c.Orders));

}

Likewise, if you wanted to filter the prefetched orders (eg, only return orders costing more than £10) and prefetch each order’s OrderDetail, you’d need to do something like this:

EntityCollection<CustomerEntity> customers = new EntityCollection<CustomerEntity>(new CustomerEntityFactory());

PrefetchPath2 prefetcher = new PrefetchPath2(EntityType.Customer);
prefetcher.Add(CustomerEntity.PrefetchPathOrders, 0, new PredicateExpression(OrderFields.TotalCost > 10))
	.SubPath.Add(OrderEntity.PrefetchPathOrderDetail);

using(DataAccessAdapter adapter = new DataAccessAdapter()) {
	adapter.FetchEntityCollection(customers, null, prefetcher);
}

…while now you can do this:

using(var adapter = new DataAccessAdapter()) {
	var linq = new LinqMetaData(adapter);

	var customers = (from c in linq.Customers select c)
				.WithPath(path =>
					path.Prefetch<OrderEntity>(c => c.Orders)
						.FilterOn(o => o.TotalCost > 10)
						.SubPath(orderPath => orderPath.Prefetch(o => o.OrderDetail))
				);

}

Lambdas rock :)

Imagine you have the following routes defined:

routes.Add(new Route("Other/List",
	new RouteValueDictionary(new {
		controller = "Other",
		action = "List"
	}),
	new MvcRouteHandler())
);

routes.Add(new Route("{controller}/{action}/{id}",
	new RouteValueDictionary(new {
		action = "Index",
		id = (string)null
	}),
	new MvcRouteHandler())
);

..and you have a HomeController with two actions: Index and List

public class HomeController : Controller {
	public ActionResult Index() {
		return View();
	}

	public ActionResult List() {
		return View();
	}
}

And imagine the following code in the Index view:

<%= Url.Action("List") %>

This should generate MyApp/Home/List but instead it generates MyApp/Other/List.

To work around this, you can intercept the RouteValueDictionary before it is passed to your routes by adding a route ‘pre-parser’. In here, you can copy the controller name from the routedata into the RouteValuesDictionary.

public class RouteValuePreParser : RouteBase {
	public override RouteData GetRouteData(HttpContextBase httpContext) {
		return null;
	}

	public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values) {
		if(!values.ContainsKey("controller") && requestContext.RouteData.Values.ContainsKey("controller")) {
			values.Add("controller", requestContext.RouteData.Values["controller"]);
		}
		return null;
	}
}

You can then add this ‘fake’ route to your RouteTable, but it must be the first route:

RouteTable.Routes.Add(new RouteValuePreParser());

The source can be downloaded from http://mvccontrib.googlecode.com/svn/trunk/ using your favourite Subversion client.

I’ve recently been working on an equivalent of the ASP.NET GridView for use with ASP.NET MVC.

This is partially inspired by the SmartGrid component which is part of the Castle Contrib project, but uses lambdas in order to build up a set of columns that can be automatically turned into an HTML table. For example, I might have this in an ASP.NET MVC Controller:

public class HomeController {
	private UserRepository repository = new UserRepository();

	public ActionResult Index() {
		ViewData["users"] = repository.FindAll();
		return RenderView();
	}
}

Then in my View I could have this:

<%
Html.Grid<Person>(
	"people",
	column => {
		column.For(p => p.Id);
		column.For(p => p.Name);
		column.For(p => p.Gender);
		column.For(p => p.RoleId);
	}
);
%>

Which would create something like this:

Note how the column names are automatically generated from the lambda expressions. However, you can override a column heading:

column.For(p => p.Id, "ID Number");

You can also create custom columns using lambda statements…

column.For("Custom Column").Do(p => { %>
	<td>A custom column...</td>
<% });

…and columns can have formatting applied to them:

column.For(p => p.DateOfBirth).Formatted("{0:d}");

Pagination is also fully supported by using the AsPagination extension method which works on any IEnumerable<T> or IQueryable<T>

public ActionResult Index(int? page) {
	ViewData["users"] = repository.FindAll().AsPagination(page ?? 1);
	return RenderView();
}

Which would produce something like this:

The source code is available in the mvccontrib trunk.

After doing some investigation I realised what the problem was: System.Web.Mvc.Controller implements IDisposable and the Windsor IoC container will keep a reference to all transient objects that it creates if they implement IDisposable. So not only was every controller being kept alive, but also everything stored in the ViewData dictionary.

Explicitly calling container.Release() inside the controller factory’s DisposeController method fixed the problem.

This makes it very easy to test the results of an action (for example, redirecting to another controller) which was a much more involved process in previous releases.

Imagine the following controller:

public class HomeController : Controller {
	public ActionResult Index() {
		return RedirectToAction(new { controller = "Home", action = "about" });
	}

	public ActionResult About() {
		return RenderView();
	}
}

While previously you’d have to mock the Response.Redirect method, now you can do this:

var controller = new HomeController();
ActionRedirectResult result = controller.Index() as ActionRedirectResult;

if(result == null) {
	Assert.Fail("Expected an ActionRedirectResult");
}
else {
	Assert.That(result.Values["controller"], Is.EqualTo("Home"));
	Assert.That(result.Values["action"], Is.EqualTo("about"));
}

While this is certainly easier, it is still a little cumbersome. To help with this, I’ve added some extension methods to MvcContrib’s ‘TestHelper’ project. So now I can write:

var controller = new HomeController();
controller.Index().AssertIsActionRedirect().ToController("Home").ToAction("about");

Much better!

LLBLGen’s querying API is very powerful, but also somewhat complex. For example, to retrieve a list of orders from all customers in the Northwind database for customers in the UK, you would write something like this:

EntityCollection<OrderEntity> orders = new EntityCollection<OrderEntity>(new OrderEntityFactory());
RelationPredicateBucket bucket = new RelationPredicateBucket(CustomerFields.Country == "UK")
bucket.Relations.Add(OrderEntity.Relations.CustomerEntityUsingCustomerId)
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
	adapter.FetchEntityCollection(orders, bucket)
}

Linq support maintains the type safety, whilst also allowing this query to be expressed in a more SQL-like fashion (which I personally find to be more intuitive):

using(DataAccessAdapter adapter = new DataAccessAdapter())
{
	var meta = new LinqMetaData(adapter);
	var query = from o in meta.Order
			where o.Customer.Country == "UK"
			select o;

	var results = query.ToList();
}

This got me thinking…now that there are several ORMs that have linq support, wouldn’t it be nice if there was a consistent method for performing linq-based queries, independent of the underlying ORM implementation. And thus the linq-repository was born.

The majority of the work is done by the BaseRepository class which acts as a wrapper around the underlying linq provider. There’s also an IRepository interface which the BaseRepository implements:

public interface IRepository<T> : IQueryable<T> where T : class
{
	void Save(T toSave);
	void Save(T toSave, bool isNew);
	void Delete(T toDelete);
}

public abstract class BaseRepository<T> : IRepository<T> where T : class
{
	private IQueryable<T> source;

	protected IQueryable<T> Source
	{
		get { return source; }
		set { source = value; }
	}

	protected BaseRepository(IQueryable<T> source)
	{
		this.source = source;
	}

	IEnumerator<T> IEnumerable<T>.GetEnumerator()
	{
		return source.GetEnumerator();
	}

	public IEnumerator GetEnumerator()
	{
		return source.GetEnumerator();
	}

	public Expression Expression
	{
		get { return source.Expression; }
	}

	public Type ElementType
	{
		get { return source.ElementType; }
	}

	public IQueryProvider Provider
	{
		get { return source.Provider; }
	}

	public abstract void Save(T toSave);
	public abstract void Delete(T toDelete);
	public abstract void Save(T toSave, bool isNew);

Note that the constructor for BaseRepository takes an IQueryable representing the underlying linq provider. Now, the LLBLGen-specific subclass:

public class LLBLGenRepository<T> : BaseRepository<T> where T : EntityBase2, IEntity2, new()
{
	public IDataAccessAdapter Adapter { get; private set; }

	public LLBLGenRepository(IDataAccessAdapter adapter, IElementCreator2 elementCreator)
			: base(CreateQuery(adapter, elementCreator))
	{
		this.Adapter = adapter;
	}

	private static IQueryable CreateQuery(IDataAccessAdapter adapter, IElementCreator2 elementCreator)
	{
		return new DataSource2(adapter, elementCreator, functionMappings, null);
	}

	public override void Save(T toSave)
	{
		if (toSave == null)
			throw new ArgumentNullException("toSave");

		Adapter.SaveEntity(toSave);
	}

	public override void Save(T toSave, bool isNew)
	{
		if (toSave == null)
			throw new ArgumentNullException("toSave");

		if (isNew) toSave.IsNew = true;

		Adapter.SaveEntity(toSave);
	}

	public override void Delete(T toDelete)
	{
		Adapter.DeleteEntity(entity);
	}

Note that the constructor for the LLBLGenRepository takes instances of an IDataAccessAdapter and an IElementCreator (the two objects necessary for running linq-queries against LLBLGen) and creates a DataSource2 object (the LLBLGen query provider) which is then passed to the BaseRepository’s constructor.

So, I can now write code like this:

IRepository<OrderEntity> orders = new LLBLGenRepository<OrderEntity>(new DataAccessAdapter(), new ElementCreator());

var query = from o in orders
		where o.Customer.Country == "UK"
		select o;

To remove the calls to new DataAccessAdapter() and new ElementCreator(), I moved the responsibility for instantiating the repository over to an IoC container:

//in my application startup routine:
IoC.Initialise(new WindsorContainer());
IoC.Container.AddComponent<IDataAccessAdapter, DataAccessAdapter>();
IoC.Container.AddComponent<IElementCreator2, ElementCreator>();
IoC.Container.AddComponent("Repository", typeof(IRepository<>), typeof(LLBLGenRepository<>));

The IoC static class is simply a wrapper for the Windsor container.

Now I can instantiate repositories like this:

IRepository<OrderEntity> orders = IoC.Resolve<IRepository<OrderEntity>>();

I don’t really like this, so I wrap it in a static gateway:

public static class Repository
{
	public static IRepository<T&t; For<T>() where T : class, new()
	{
		return IoC.Resolve<IRepository<T>>();
	}
}

…and now I can write queries like this:

var query = from o in Repository.For<OrderEntity>
		where o.Customer.Country == "UK"
		select o;

Alternatively, now that the repository is registered with Windsor, I can inject the repository directly into my ASPNET MVC Controllers:

public class OrdersController : ConventionController
{
	private IRepository<OrderEntity> ordersRepository;

	public OrdersController(IRepository<OrderEntity> repository)
	{
		this.ordersRepository = repository;
	}

	public void OrdersFromCustomersInTheUk()
	{
		ViewData["orders"] = from o in ordersRepository
						where o.Customer.Country == "UK"
						select o;
	}
}

There’s a discussion going on at the MvcContrib site about including UI Helpers in the MvcContrib project. The discussion seems to be centralising around the issue of whether helpers should be implemented through extension methods (the approach the MVCToolkit takes), regular static methods or instance methods.

My preference is for instance methods on dedicated helper classes. This approach is the most flexible as it allows you to:

• Replace an entire helper with a custom implementation
• Easily share services between all helpers

I decided to put together a sample application that uses an IoC container (Windsor) for creating helpers. The sample project includes:

• FormHelper and UrlHelper implementations that are created using the MvcContrib DependencyResolver.
• Services for generating URLs (IUrlBuilder) and for automatic data binding (IDataBinder)
• Delegate-based rendering (see this post on Adam Tybor’s blog for more info).
• Using IDictionaries for specifying HTML attributes
• Methods for generating text fields, text areas, hidden fields, forms and hyperlinks

Some sample code:

<% Form.For("person", new Hash(action => "Save"), form => { %>
	Surname: <%= form.TextField("Surname", new Hash(style => "width: 200px")) %>
	<br />
	Forename: <%= form.TextField("Forename", new Hash(style => "width: 200px"))%>
	<br /><br />
	<%= form.HiddenField("id") %>
	<%= form.Submit() %>
<% }); %>

Which generates…

<form method="post" action="/Home/Save">
	Surname: <input type="text" id="person_Surname" name="person.Surname" value="Smith" style="width: 200px" />
	<br />
	Forename: <input type="text" id="person_Forename" name="person.Forename" value="Jane" style="width: 200px" />
	<br /><br />
	<input type="hidden" id="person_id" name="person.id" value="2" />
	<input type="submit" value="Submit" />
</form>

Note: To run the sample you will need the .NET 3.5 Extensions CTP installed.

Disclaimers:

• The DefaultDataBinder implementation uses code from Castle’s MonoRail
• The DefaultUrlBuilder uses code from Rob Conery’s MvcToolkit
• The Hash class is inspired by this post on Bill Pierce’s blog.

The download can be found here.