Gil Fink's Blog : Unity Application Block

Revisiting XML Configurations In Unity

Gil Fink — Thu, 06 Jan 2011 16:29:48 GMT

Revisiting XML Configurations In Unity

In the past I wrote a few tutorials about Unity application block. One of the things I wrote about was how to configure a Unity container using design time configuration. In this post I’m going to revisit that post and show you how the configurations changed (for the better) and are much more easier to work with in the current version of Unity (version 2).

The Unity Configuration Section

As in my previous post we will first start with a small example of Unity configuration section in order to understand it. Later I’m going to discuss the elements and how to configure them. So here is the configuration file:

       <?xml version="1.0" encoding="utf-8"?>

      <configuration>

        <configSections>

          <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>

        </configSections>

        <connectionStrings>

          <add name="ConnectionString" connectionString="something" providerName="System.Data.SqlClient" />

        </connectionStrings>

        <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">

          <!-- An interface for logger implementation -->

          <alias alias="ILogger" type="UnityExamples.Common.ILogger, UnityExamples.Common" />

          <!-- An abstarct class for database classes -->

          <alias alias="Database" type="UnityExamples.Common.Database, UnityExamples.Common" />

          <container name="MyContainer">

            <register type="ILogger" mapTo="UnityExamples.Common.FileLogger, UnityExamples.Common" />

            <register type="Database" mapTo="UnityExamples.Common.CustomDatabase, UnityExamples.Common">       

              <constructor>

                <param name="connString" type="System.String">

                  <value value="connection value..."/>

                </param>

                <param name="logger" type="ILogger">

                  <dependency/>

                </param>

              </constructor>

            </register>

          </container>

        </unity>

      </configuration>

As opposed to the configurations we mad ein Unity’s first version this is much shorter. One thing to notice is the use of Xml namespace (http://schemas.microsoft.com/practices/2010/unity) which you will need to use in the Unity configuration section in order to get Intellisense.

Unity Elements Changes

Lets check what was changed.
Aliases – the first thing to notice is the absence of the typeAliases container element. Instead of it you can register your aliases one after another. Also, the element name typeAlias was changed to alias. This is no big deal but it is making the aliases registration a little more shorter.
Containers – like the aliases, the containers element was disposed. You will create a container element for each container with a relevant name. In every container you will register types and instances to be resolved. Instead of the Types element and the Type element you will use the register or instance elements. Inside these elements you will configure things like the constructor injection that I used in the example.

Building the Runtime Example

I’m using the same example which I used in the previous post. Here are the classes:

      public interface ILogger

      {

          #region Methods

          void Log(string message);

          #endregion

      }

      public class FileLogger : ILogger

      {

          #region ILogger Members

          public void Log(string message)

          {

          }

          #endregion

      }

      public abstract class Database

      {

      }

      public class CustomDatabase : Database

      {

          #region Members

          private ILogger _logger;

          private string _strConnString;

          #endregion

          #region Ctor

          /// <summary>

          /// Construct a new CustomDatabase object

          /// </summary>

          public CustomDatabase(string connString, ILogger logger)

          {

              _logger = logger;

              _strConnString = connString;

          }

          #endregion

      }

When you want to use the Xml configurations Unity exposes a container method which is called LoadConfiguration which will load the configurations for you. Here is an example of how to use it:

      IUnityContainer container = new UnityContainer();

      container.LoadConfiguration("MyContainer");

      var database = container.Resolve<Database>();

      var logger = container.Resolve<ILogger>();

First you create the Unity container. Then you use the container's LoadConfiguration method in order to load the configurations you made into the container. In the example I use the container name (MyContainer) from the configuration file. Then you can use Unity resolve method to get the relevant runtime implementation. Easy as that.

Summary

Even though I prefer to use runtime configuration in order to configure my Unity container, there are times that the specifications don’t change and a design time configuration can be used. In this post I showed you how to use Unity’s current version Xml configuration. If your are using the previous version of Unity you can find details about its configurations in my old post.

Using the ControllerActivator in MVC 3

Gil Fink — Sun, 17 Oct 2010 15:57:59 GMT

Using the ControllerActivator in MVC 3

In the previous post I showed how to use the DependencyResolver in order to bring Dependency Injection behavior to a MVC 3 application. In this post I’ll show you how you can use the ControllerActivator in order to activate controllers using your own behavior.

The IControllerActivator

In MVC 3 beta a new interface was introduced – the IControllerActivator. This interface is an injection point in order to create our own behavior in order to activate controllers. That interface is discoverable using the dependency resolver. If you don’t implement the interface and register it in the dependency resolver a default behavior which is to use the Activator.CreateInstance will activate controllers.
The interface includes only one method which is the Create method. This method has the same signature like the DefaultControllerFactory’s GetControllerInstance method.
Here is a simple way to implement the IControllerActivator using the previous post’s DependencyResolver:

     public class UnityControllerActivator : IControllerActivator

    {

      #region IControllerActivator Members

      public IController Create(RequestContext requestContext, Type controllerType)

      {

        return DependencyResolver.Current.GetService(controllerType) as IController;      

      }

      #endregion

    }

As you can see I use the current DependencyResolver to get the Unity behavior. Of course you can use other behaviors to implement the controller activation. Here is how the InitContainer method from the previous post will look like now:

    private static IUnityContainer InitContainer()    

    {                   

      var container = new UnityContainer();        

      // Register the relevant types for the         

      // container here through classes or configuration 

      container.RegisterType<IControllerActivator, UnityControllerActivator>();                

      container.RegisterType<IMessageService, MessageService>();

      return container;

    }

I just added the registration of the IControllerActivator to the container. Now if you will debug the application and set a breakpoint in the Create method you will see that all controller activations will pass through the IControllerActivator. When running the application you will get the same result as in the previous post:

Summary

In this post I showed how to hook up your own controller activation behavior in MVC 3. This can be achieved by using the new IControllerActivator interface. The example I showed is using the Unity IoC and could be implemented in other ways as well.

Dependency Injection in MVC 3 Was Made Easier

Gil Fink — Sun, 17 Oct 2010 15:26:44 GMT

Dependency Injection in MVC 3 Was Made Easier

In the past I wrote a post that showed how to implement Dependency Injection using Unity in ASP.NET MVC framework. This post revisits that post and shows how you can do the same thing easily in MVC 3. Pay attention that the supplied code is based on MVC 3 beta and may change in the future.

The IDependencyResolver and DependencyResolver

MVC 3 introduces a new interface – the IDependencyResolver. This interface enables service location by providing two methods:

GetService(Type serviceType) – this method gets a service type and returns an object if the resolver succeeded in resolving the type. If the resolver couldn’t resolve the type you must return null in order to activate the default MVC behavior.
GetServices(Type serviceType) – this method gets a service type and returns an IEnumerable<object> of all the resolved objects. If the resolver couldn’t resolve the type you must return an empty collection to activate the default MVC behavior.

The DependencyResolver is a static class that you can use to register your custom IDependencyResolver. After you implement the IDependencyResolver, you set it in the DependencyResolver using one of the SetResolver overloaded methods. Then you will be able to use the Current property to get the current DependencyResolver in order to resolve types. If you don’t like to use the DependencyResolver ability you need to implement nothing there is default resolving behavior that is built inside the MVC implementation.

Building and Using a UnityDependencyResolver

Here is a simple implementation of a UnityDependencyResolver:

     public class UnityDependencyResolver : IDependencyResolver

    {

        #region Members

        private IUnityContainer _container;    

        #endregion

        #region Ctor

        public UnityDependencyResolver(IUnityContainer container)

        {

          _container = container;

        }

        #endregion

        #region IDependencyResolver Members

        public object GetService(Type serviceType)

        {

          try

          {

            return _container.Resolve(serviceType);

          }

          catch (Exception ex)

          {

            return null;

          }

        }

        public IEnumerable<object> GetServices(Type serviceType)

        {

          try

          {

            return _container.ResolveAll(serviceType);

          }

          catch (Exception ex)

          {

            return new List<object>();

          }

        }

        #endregion

    }

In order to use this resolver the appropriate place to build the container is the Global.asax file. Here is the implementation:

    public class MvcApplication : System.Web.HttpApplication

    {

        public static void RegisterGlobalFilters(GlobalFilterCollection filters)

        {

          filters.Add(new HandleErrorAttribute());

        }

        public static void RegisterRoutes(RouteCollection routes)

        {

          routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

          routes.MapRoute(

              "Default", // Route name

              "{controller}/{action}/{id}", // URL with parameters

              new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults

          );

        }

        protected void Application_Start()

        {

          AreaRegistration.RegisterAllAreas();

          RegisterGlobalFilters(GlobalFilters.Filters);

          RegisterRoutes(RouteTable.Routes);

          var container = InitContainer();

          DependencyResolver.SetResolver(new UnityDependencyResolver(container));       

        }

        private static IUnityContainer InitContainer()    

        {                   

          var container = new UnityContainer();        

          // Register the relevant types for the         

          // container here through classes or configuration                      

          container.RegisterType<IMessageService, MessageService>();

          return container;

        }

    }

As you can see I added the initialization of the container and also I set the DependencyResolver to the Unity implementation. The Message service and the controller are the same classes that I showed in my previous post:

    public interface IMessageService 

    { 

      string GetMessage();

    }

    public class MessageService : IMessageService

    {

      #region IMessageService Members

      public string GetMessage()

      {

        return "Hello Controller!";

      }

      #endregion

    }

and

    public class HomeController : Controller

    {

      #region Members     

      [Dependency]    

      public IMessageService MessageService { get; set; }

      #endregion

      #region Actions    

      public ActionResult Index()

      {

        ViewModel.Message = MessageService.GetMessage();

        return View();

      }

      public ActionResult About()

      {

        return View();

      }

      #endregion

    }

After running this example we will get the following expected result:

Summary

Let sum up, in MVC 3 beta there is a new way to use DI and IoC containers by implementing the IDependencyResolver interface and registering it in the DependencyResolver static class. There are other injection points that you can use like the IControllerActivator which I’ll write about in a following post.

Hands-on Labs for Microsoft Enterprise Library 5.0 and Unity 2.0

Gil Fink — Fri, 28 May 2010 19:34:26 GMT

Hands-on Labs for Microsoft Enterprise Library 5.0 and Unity 2.0

Enterprise Library 5.0
is out there for over
a month. With
every release of
Enterprise Library,
The Patterns &
Practices team is always
launching a set of hands-on labs which can help you to
get started with Enterprise Library and to understand how
you can work with it in order to implement cross cutting
concerns in your applications. You can download the labs
from here.
Enjoy!

Index Pages on My Blog

Gil Fink — Fri, 10 Apr 2009 20:23:00 GMT

Index Pages on My Blog

Lately, I received an e-mail from a reader of my blog which included
an advice to make an index for my post series. I took his advice and
made 3 index pages for the following subjects:

These index pages will be updated frequently whenever a new tutorial
post will be added. Also, I’m going to add more index pages in the
future for more post series.
Thanks Marcellus.
Enjoy!

How To Use Unity Container In ASP.NET MVC Framework

Gil Fink — Sun, 08 Feb 2009 20:15:00 GMT

How To Use Unity Container In ASP.NET MVC Framework

In the past I wrote the
post How To Use Unity
Container In ASP.NET.
In this post I’m going to
explain how we can
use Unity IoC container
in ASP.NET MVC Framework.

Building The Container

As in the previous post the first thing to do is to build the
container itself. I’ll use the same method I used in the previous post
in order to persist the Unity container’s state during the application
execution. The right place to put the Unity container is as part of the
Global.asax file as a property of the current running application.
I’m going to use the same interface as before:

public interface IContainerAccessor{    IUnityContainer Container { get; }}

After the building of the interface implement it in the Global
class in the Global.asax file:

public class MvcApplication : HttpApplication, IContainerAccessor{    #region Members     private static IUnityContainer _container;     #endregion     #region Properties     /// <summary>    /// The Unity container for the current application    /// </summary>    public static IUnityContainer Container    {        get        {            return _container;        }    }     #endregion     #region IContainerAccessor Members     /// <summary>    /// Returns the Unity container of the application     /// </summary>    IUnityContainer IContainerAccessor.Container    {        get { return Container; }    }     #endregion     #region Application Events     protected void Application_Start()    {        RegisterRoutes(RouteTable.Routes);        InitContainer();        ControllerBuilder.Current.SetControllerFactory(typeof(UnityControllerFactory));    }     protected void Application_End(object sender, EventArgs e)    {        CleanUp();    }     #endregion     #region Methods     public static void RegisterRoutes(RouteCollection routes)    {        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");         routes.MapRoute(            "Default",                                              // Route name            "{controller}/{action}/{id}",                           // URL with parameters            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults        );     }     private static void InitContainer()    {        if (_container == null)        {            _container = new UnityContainer();        }         // Register the relevant types for the         // container here through classes or configuration        _container.RegisterType<IMessageService, MessageService>();    }     private static void CleanUp()    {        if (Container != null)        {            Container.Dispose();        }    }     #endregion }

The Unity Controller Factory

The real and important change with this new implementation of
Global.asax is the setting of the controller factory which I wrote.
The code for the UnityControllerFactory:

public class UnityControllerFactory : IControllerFactory{    #region IControllerFactory Members     public IController CreateController(RequestContext requestContext, string controllerName)    {        IContainerAccessor containerAccessor =            requestContext.HttpContext.ApplicationInstance as IContainerAccessor;         Assembly currentAssembly = Assembly.GetExecutingAssembly();        var controllerTypes = from t in currentAssembly.GetTypes()                              where t.Name.Contains(controllerName + "Controller")                              select t;         if (controllerTypes.Count() > 0)        {            return containerAccessor.Container.Resolve(controllerTypes.First()) as IController;        }        else        {            return null;        }    }     public void ReleaseController(IController controller)    {        controller = null;    }     #endregion}

The main thing to do is to implement the CreateController method of
the IControllerFactory interface. I use the request context parameter to
retrieve the current application instance and from it I get the Unity container
through the interface of IContainerAccessor. I also need to instantiate the
relevant controller class which is being done by the Unity container for me.
The container will inject the dependencies in the controller by the Resolve
method and we will get the dependency injection functionality that we
wanted.

The Class to be Injected

I also wrote a MessageService which is a simple class that returns a
message and inherit from the IMessageService which declare the
GetMessage method:

public interface IMessageService{    string GetMessage();} public class MessageService : IMessageService{    #region IMessageService Members     public string GetMessage()    {        return "Hello Controller!";    }     #endregion}

The Controller

The last piece of this puzzle is the controller class.
I implemented the HomeCotroller class with the following code:

[HandleError]public class HomeController : Controller{    #region Members     [Dependency]    public IMessageService MessageService { get; set; }             #endregion     #region Actions     public ActionResult Index()    {        ViewData["Message"] = MessageService.GetMessage();        return View();    }     public ActionResult About()    {        return View();    }     #endregion}

The UnityControllerFactory will inject the dependency of the MessageService
property with the relevant class and that’s it simple as that.

Summary

Lets sum up, I showed an example of how to use Unity container in ASP.NET
MVC Framework application. This is a very simple example that will help you
to get started with Unity in your MVC web applications

Dependency Injection From Theory to Practice With Unity Article

Gil Fink — Wed, 19 Nov 2008 16:07:39 GMT

Dependency Injection From Theory to Practice With Unity Article

Today my article, Dependency
Injection From Theory to Practice With Unity,
was published on the Hebrew MSDN site.
The article describe what is dependency injection
and then introduce the Unity application block.
You can read the article here.
You can read more Hebrew MSDN articles here.

Enjoy.

Common Service Locator Library

Gil Fink — Fri, 03 Oct 2008 20:05:00 GMT

Common Service Locator Library

introduction

Yesterday Glenn Block introduced
a Common Service Locator library
which is described as “a shared
interface that applications and
frameworks can reference in
order to leverage
IoC containers / service location
mechanisms without taking
hard dependencies”.
The idea for the library is based
on a post that Jeremy Miller
wrote of having a shared interface
across several IoC implementation.
The benefit of such an interface is
obvious - no dependency on a
particular IoC implementation.
The result was the birth of a new library – the common service locator library.

The Common Service Locator Library

The library currently holds the IServiceLocator interface which describe the
following contract:

   public interface IServiceLocator : IServiceProvider
   {
      IEnumerable<TService> GetAllInstances<TService>();
      IEnumerable<object> GetAllInstances(Type serviceType);
      TService GetInstance<TService>();
      TService GetInstance<TService>(string key);
      object GetInstance(Type serviceType);
      object GetInstance(Type serviceType, string key);
   }

That contract was agreed by the following IoC containers frameworks creators:
Unity, Spring.Net, Castle Windsor, Structure Map and Ninject.
Other parts of the library include a static ServiceLocator class which
exposes the current container, a ServiceLocatorImplBase which is an abstract class
for building your own service locator and a ServiceLocatorProvider which is the
method to get the current container by the ServiceLocator static class.

Conclusion

The new library suppose to solve the problem of hard dependencies on
IoC containers / service location mechanisms. The library’s birth can demonstrate
the power of the community which see the need and create a library that is agreed
upon. I join the hope of Glenn Block that the new library will encourage products
and frameworks to start leveraging IoC / Service location frameworks.
Download the Common Service Locator library here.
I downloaded it yesterday…

Using Unity Injection API

Gil Fink — Fri, 01 Aug 2008 21:15:00 GMT

The post show some aspects of Unity application block injection API....(read more)

Using Unity Container Hierarchies

Gil Fink — Sat, 26 Jul 2008 17:30:00 GMT

The post explain the use of Unity container hierarchies in to aspects - why and how to use them...(read more)

Working With Generic Types In Unity Configuration Section

Gil Fink — Fri, 25 Jul 2008 04:00:00 GMT

The post shows how to register generic types in the Unity configuration section and how to use them in code....(read more)

Working With Configuration Files In Unity

Gil Fink — Thu, 24 Jul 2008 17:50:00 GMT

The post describe how to work with configuration files with the Unity application block...(read more)

How To Use Unity Container In ASP.NET

Gil Fink — Wed, 02 Jul 2008 00:20:00 GMT

In the post I show how to integrate Unity in ASP.NET web applications....(read more)

Unity Application Block Basics

Gil Fink — Sat, 28 Jun 2008 21:00:00 GMT

The post shows how to get started with the Unity application block by showing the basic Unity operations....(read more)

Unity Application Block

Gil Fink — Sat, 07 Jun 2008 22:00:00 GMT

In the post I describe what is the Unity application block, why to use it and when to use it....(read more)