Another Entity Framework 4 Repository & Unit of Work Solution–Intro and Part 4: ASP.NET MVC 3 Project

This is Part 4 in a series of posts that walk through the process of implementing a solution that separates concerns into specific behaviors using the Entity Framework 4 and the Repository and Unit of Work Patterns.

Below is the series outline; again, this is Part 4.

• Part 1: Setup
  
  • This post involves downloading and creating the SQL Server database, setting up the Visual Studio solution and project structure, and generating the out-of-the-box Entity Framework (EF/EF4) data model from the newly created database.
• Part 2: Creating the Repositories and Unit of Work (UoW)
  
  • This is the meat of the series.  This post includes downloading some T4 templates, settings a few parameters, and generating the Repositories and Unit of Work (UoW) using the T4 templates and EF4 data model.
• Part 3: Review Some of The Generated Code
  
  • This post will review a few of the generated class/interfaces that the T4 code generation created.
• Part 4: Using EF, Repository & UoW in an ASP.NET MVC 3 Project
  
  • This post includes wiring up the EF4 data model, repositories, and UoW to StructureMap dependency injection container and use of these products in an ASP.NET MVC 3 Web application project.

Now on to Part 4… Open up the Chinook solution in Visual Studio. Let’s do a little solution organization.  Create the following three solution folders by right-clicking the solution file, selecting ‘Add,’ and then selecting ‘New Solution Folder.’

• Core
  
• Infrastructure
  
• Web

Place the Chinook.Core project into the Core Solution Folder and place the other two projects (Chinook.Data.EF and Chinook.Infrastructure) into the Infrastructure Solution Folder.  The Web Solution Folder will contain our MVC Web application project.  Let’s do that now… Right-click the Web Solution Folder.  Click 'Add’ –> ‘New Project…’ Next, create an ASP.NET MVC 3 Web Application and name is ‘Chinook.Web’ and click ‘OK.’ On the next screen, select ‘Internet Application,’ the ‘Razor’ View engine, and click ‘OK’ Right-click the new ‘Chinook.Web’ Application Project and select ‘Set As Startup Project.’  The solution structure should now look similar to the following: Add the following References to the ‘Chinook.Web’ Project and then build the solution. In the description of this post, it states that we are going to use StructureMpa as our DI container.  We are going to get StructureMap via NuGet.  Assuming you have NuGet installed, select the Chinook.Web project, open the ‘Package Manager Console,’ and type the following command:

PM> Install-Package StructureMap

This will install StructureMap and register any assemblies with the Chinook.Web project.  Once the NuGet command is executed, the NuGet Package Manager Console should echo the following: Go ahead and build the solution. Next, add the the new StructureMap reference to both the Chinook.Data.EF and Chinook.Infrastructure projects and rebuild the solution. Again, this series assumes that you have all the necessary tools (NuGet, POCO templates, etc…) installed with Visual Studio and that you are somewhat familiar with StructureMap. Now, remember the two files (EFRepositoryRegistry.cs.txt and ServicesRegistry.cs.txt) that the T4 templates generated for us in the previous post?  We are going to use those files to create our StructureMap registries.  The best way to do this is to create two new cs files in the respective projects, copy the code from the generated file, and paste it into these new code files.  I understand this is not idea (copy, paste, etc…); however, I didn’t want to limit our solution to StructureMap only, so we’ll just have to deal with the awkwardness for now.  So, create the following files and replace all the code in the new code file with the code in the associated generated file.

• EFRepositoryRegistry.cs – in the Chinook.Data.EF project
  
  • EFRepositoryRegistry.cs.txt – generated file
• ServicesRegistry.cs – in the Services directory within the Chinook.Implementation project
  
  • ServicesRegistry.cs.txt – generated file

Go ahead and build the solution again. Next, we are going to register our repositories, unit of work, and other dependencies (created earlier in a previous post) with StructureMap in our Chinook.Web project.  To do this, we are going to use ASP.NET MVC 3 IDependencyResolver – you can read about IDependencyResolver here and read the API docs here. Create a ‘Bootstrap’ directory in the Chinook.Web project and create the following two empty code/class files:

• StructureMapContainerSetup.cs – make this class static
  
• StructureMapDependencyResolver.cs

Now we are going to register the Registries created earlier in these ‘bootstrap’ files.  Since this series of posts is walk through on the process of setting up a solution for separation of concerns and not on the theory of such topics, the exercise of explaining the StructureMap registration is beyond the scope of this series.  Populate these newly created code files with the following content:

StructureMapDependencyResolver

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web.Mvc;
using StructureMap;

namespace Chinook.Web.Bootstrap
{
    public class StructureMapDependencyResolver : IDependencyResolver
    {
        private readonly IContainer _container;

        public StructureMapDependencyResolver(IContainer container)
        {
            _container = container;
        }

        #region Implementation of IDependencyResolver

        /// <summary>
        /// Resolves singly registered services that support arbitrary object creation.
        /// </summary>
        /// <returns>
        /// The requested service or object.
        /// </returns>
        /// <param name="serviceType">The type of the requested service or object.</param>
        public object GetService(Type serviceType)
        {
            var instance = _container.TryGetInstance(serviceType);

            if ((instance == null) && !serviceType.IsAbstract)
            {
                _container.Configure(c => c.AddType(serviceType, serviceType));
                instance = _container.TryGetInstance(serviceType);
            }
            return instance;
        }

        /// <summary>
        /// Resolves multiply registered services.
        /// </summary>
        /// <returns>
        /// The requested services.
        /// </returns>
        /// <param name="serviceType">The type of the requested services.</param>
        public IEnumerable<object> GetServices(Type serviceType)
        {
            return _container.GetAllInstances(serviceType).Cast<object>();
        }

        #endregion
    }
}

StructureMapContainerSetup

using System.Web.Mvc;
using Chinook.Data.EF;
using Chinook.Infrastructure.Services;
using StructureMap;

namespace Chinook.Web.Bootstrap
{
    public static class StructureMapContainerSetup
    {
        public static void Setup()
        {
            IContainer container = new Container(
                x =>
                    {
                        x.AddRegistry(new EFRepositoryRegistry());
                        x.AddRegistry(new ServicesRegistry());
                    }
                );

            DependencyResolver.SetResolver(new StructureMapDependencyResolver(container));
        }
    }
}

Now we are going to invoke the StructureMap registration bootstrapping code from the Application_Start method of the Global.asax.cs file.  Here’s the snippet:

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

    StructureMapContainerSetup.Setup();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

Go ahead and build the solution again… We are now going to create a quick controller, view, and some supporting View Models that will give a simple example how to use all the code created in this series of posts.  For this part, go ahead and download the final solution.  Logically representing the code here will be difficult and would provide little value without context; therefore, download the final solution and review the code in the Chinook.Web project.  Here’s a quick list of the steps involved to generated the code samples:

1. Create a ViewModel - AlbumGridItemViewModel.
   
2. Create a IViewModelBuilder/ViewModelBuilder – IAlbumGridItemViewModelBuilder/AlbumGridItemViewModelBuilder.
   
3. Create a new Controller - AlbumController.
   
4. Use constructor injection to inject the ViewModelBuilder into the Controller -  IAlbumGridItemViewModelBuilder into the AlbumController.
   
5. Create a View to represent a list of ViewModel items – Index – this is only a list of items; however, the process remains the same for all types of views.
   
6. Register the IViewModelBuilder/ViewModelBuilder with StructureMap – using a similar pattern as the other DI registrations – a StructureMap Registry.

The resulting list generated in the sample code is not designed for performance (e.g. no paging, sorting, etc..).  In production, this type of code can and should be refactored.  That said, the key points throughout this series are the patterns used to create a solution based on separation of concerns – including the Repository and Unit of Work patterns and using StructureMap as a Dependency Injection container.

Thanks for reading…