There are many techniques for doing this but they all fell short for us in way or another as we wanted to meet all the following requirements:
- It should be strongly-typed (no using of viewbag/viewdata, thanks - in our opinion it makes it too difficult to refactor views later).
- The views should be bound to the necessary models to enable intellisense.
- It should support ctor dependency injection.
- The common data should be available to controllers and views. This is especially useful when your application supports authentication and you need to show a property of the user in the view and need to use a property of the user in your controller action.
- You should be able to opt-out if necessary.
- Controller actions shouldn't need to change in any way - e.g. no calling of functions to populate the models.
The first step is to define a class that will represent this shared context. There isn't anything special about this class - it's a regular poco.
Here is an example that will store the current user and the number of unread messages in their inbox.
namespace Web.Models
{
public class SharedContext
{
public User CurrentUser { get; set; }
public int UnreadMessageCount { get;set; }
}
}
Once you have created your shared context class you need to create a base view model. Again, it's just a poco but what is important is that it is able to hold an instance of the shared context which will be explained in more detail further below. Here is an example:
namespace Web.Models
{
public class LayoutModel
{
public SharedContext Context { get; set; }
}
}
This is the model you will bind to your _Layout file which takes care of the intellisense and "no loosely-typed view data" requirements. In your _Layout, if you would like to show the user's name, for example, you could access the property with @Model.Context.CurrentUser.Name (assuming you had a User class with a Name property, obviously).
The next step is to wire up these classes so they are populated automatically. We start by creating the interface for what I have called the view model factory.
An example of such an interface is as follows:
namespace Web.Mvc
{
public interface IViewModelFactory
{
T Create<T>() where T : SharedContext, new();
void Set<T>(T model) where T : SharedContext, new();
}
}
The generic constraint ensures that we can access the context properties in the method implementations. Here is an example implementation of this interface:
namespace Web.Mvc
{
public class ViewModelFactory : IViewModelFactory
{
private readonly IUserMessageService _userMessageService;
private readonly IUserService _userService;
public ViewModelFactory(IUserMessageService userMessageService,
IUserService userService)
{
_userMessageService = userMessageService;
_userService = userService;
}
public T Create<T>() where T : SharedContext, new()
{
var model = new T();
Set(model);
return model;
}
public void Set<T>(T model) where T : SharedContext, new()
{
var user = _userService.GetCurrent();
model.User = user;
model.UnreadMessageCount = _userMessageService.GetUnreadCount(user.Id);
}
}
}
Hopefully it's pretty straightforward. It's an implementation of the view model factory that is injected with several fictitious dependencies and generates a shared context. You will need to use your imagination here a bit.
At this point, you are going to want to register the view model factory in whatever DI container (I hope) you're using. In Unity, you might do something like:
container.RegisterType<IViewModelFactory, ViewModelFactory>(new PerCallContextLifeTimeManager());
Although usually not a fan of inheritance it works well for this scenario. You need a base class from which all your controllers will inherit (instead of from "Controller"). You might have done this already for various other reasons. Here is an example:
namespace Web.Mvc
{
public class BaseController : Controller
{
public SharedContext Context { get; set; }
}
}
In one of your action methods, you could access the current user via Context.CurrentUser.
We want our view model factory to be called automatically so our model is populated correctly. Here is the code for that attribute - you should be able to use this class as-is unless you've renamed the view model factory or shared context.
namespace Web.Mvc
{
public class LayoutModelAttribute : ActionFilterAttribute
{
private readonly IViewModelFactory _viewModelFactory;
public LayoutModelAttribute(IViewModelFactory viewModelFactory)
{
_viewModelFactory = viewModelFactory;
}
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
var controller = filterContext.Controller as BaseController;
if (controller != null)
{
(controller).Context = _viewModelFactory.Create<SharedContext>();
}
base.OnActionExecuting(filterContext);
}
public override void OnResultExecuting(ResultExecutingContext filterContext)
{
viewModel = filterContext.Controller.ViewData.Model;
var controller = filterContext.Controller as BaseController;
var model = viewModel as LayoutModel;
if (model != null)
{
(model).Context = controller != null && controller.Context != null
? controller.Context
: _viewModelFactory.Create<SharedContext>();
}
base.OnResultExecuting(filterContext);
}
}
}
Taking a quick step back, this is what the attribute is doing:
We override OnActionExecuting and OnResultExecuting as these execute at different places within the asp.net mvc pipeline. To accomplish the requirement of being able to access the share context in a controller, the attribute needs to execute before the controller action; hence OnActionExecuting.
To intercept the model returned from the action and populate the required properties, we override OnResultExecuting which executes after the action has complete but before the view is rendered.
There are two different base-class checks here that allow us to opt-out of the shared context population. If the base class of your controller does not inherit from your new BaseController class, the view model factory will not be invoked before the action executes.
The other check is to ensure that the view model you are returning inherits from the new LayoutModel class. If not, the view model factory is bypassed. This means you can also use the shared context in your non-layout views which can be useful.
The next step is to register this attribute so it executes for every controller. There are different ways to do this, but I generally use the following as part of my site's bootstrapper (where container is our DI container):
GlobalFilters.Filters.Add(container.Resolve<LayoutModelAttribute>(), 1);
The last parameter (1 in this case) is there because I have an authentication filter higher up that should be checked before the new attribute is executed. You are likely to have different requirements in your own application.
Now that the infrastructure is complete, we can get on with building the application. Here is a sample view model that you might use on the homepage of your site:
namespace Web.Models
{
public class HomeModel : LayoutModel
{
public string Content { get;set; }
}
}
And here is the controller you might use:
namespace Web.Mvc
{
public class HomeController : BaseController
{
public ActionResult Index()
{
return View(new HomeModel { Content = "Hello View Model Factory!" });
}
}
}
It might seem a bit complicated at first, but after several large applications this appears to provide the most maintainable and robust solution to this particular problem.
