Derik Whittaker : Ninject

Convention Binding to Ninject 3 -- Resolving ‘Value Cannot be Null’ Exception

Derik Whittaker — Sun, 12 Aug 2012 12:26:00 GMT

Recently I was creating a new MVC4 application and of course I wanted to use Ninject as my IoC container. The first thing I did was to download and install the following NuGet packages:

After I got these setup I opened up the NinjectWebCommon.cs class and started to add code to the RegisterServices method. The first thing i did was to add the code below;

            kernel.Bind(scanner =>
            {
                try
                {
                    scanner.FromAssemblyContaining()
                    .SelectAllClasses()
                    .BindDefaultInterface();

                    scanner.FromAssemblyContaining()
                        .SelectAllClasses()
                        .BindDefaultInterface();

                    scanner.FromAssemblyContaining()
                        .SelectAllClasses()
                        .BindDefaultInterface();
                }
                catch (Exception e) // added to try to get the exception message
                {
                    Debug.WriteLine(e);
                    throw;
                }
            });

The above code would step over the first scanner call w/ no issues, in fact if that was the ONLY statement it all worked as expected, however when it stepped onto the second scanner. call I would get the following error.

System.ArgumentNullException: Value cannot be null. Parameter name: first

Because I knew everything worked fine with only one scanner. call i decided to give it a go w/ creating a unique kernal.Bind for each assembly i wanted scanned as below:

            kernel.Bind(scanner => scanner.FromAssemblyContaining()
                                       .SelectAllClasses()
                                       .BindDefaultInterface());

            kernel.Bind(scanner => scanner.FromAssemblyContaining()
                                       .SelectAllClasses()
                                       .BindDefaultInterface());

            kernel.Bind(scanner => scanner.FromAssemblyContaining()
                                       .SelectAllClasses()
                                       .BindDefaultInterface());

This did the trick, I could now setup the bindings for multiple assemblies with no issues. So it appears that with this version of the Extensions class for ninject you need to do each action as a unique .Bind method.

Till next time,

Convention Based View Model Location using Ninject in a MVVM/Silverlight Application

Derik Whittaker — Sat, 02 Jul 2011 11:23:53 GMT

***** UPDATE *****
If you would like to see a video on this topic check out Episode 194 @ Dimecasts.Net
*******************

When building out a Silverlight application (or WPF application for that matter) the MVVM pattern is the pattern of choice for most projects I am aware of. When using MVVM there is a sub pattern which is commonly used which is known as ViewModelLocator. The ViewModelLocator concept basically tries to handle the repetitive task of coupling the View with its ViewModel but doing so in a way which removes any manual coding and it just ‘happens’.

Now if you have done any research on the ViewModel Location I am sure you have run across countless other blog posts out there which explain how to implement in this code, and many of them are great. In fact here are a few which helped me down the path of creating the code I am going to talk about in this post

Simple ViewModel Locator for MVVM by John Papa (this is the post which really kick started this pattern)
Wiring up ViewModel Locator w/ Silverlight
MVVM and ViewModel Location
Another MVVM and ViewModel Location
Caliburn.Micro has an implementation
MVVMLight has an implementation

All of the above posts basically show how to implement this pattern in your application and from what I can tell all of them work and will do the job. However, none of those (minus the Caliburn.Micro) implementations fulfills the one requirement I want which is to totally remove the need to ‘wire’ the ViewModel up to your View if even via XAML. I want to remove this wiring from the XAML because in my mind this still leaves me hard wiring the relationship rather than using convention based wiring. One scenario in which the hard wiring could turn around and bite you is in the times where you rename the view and the view model. If you fail to update your wiring code in XAML you will receive runtime errors.

Here are a few examples:
John Papa’s Implementation

DataContext="{Binding Source={StaticResource VMLocator}, Converter={StaticResource VMIndexerConverter}, ConverterParameter=MainPageViewModel}"

ViewModelLocator’s Implementation

    <UserControl.Resources>
        <ViewModels:EditUsersViewModelLocator x:Key="viewModelLocator"  />
    </UserControl.Resources>
    <UserControl.DataContext>
        <Binding Source="{StaticResource viewModelLocator}" Path="ViewModel" />
    </UserControl.DataContext>

I wanted my implementation of toe ViewModelLocator pattern to NOT need to know anything about the actual View or the ViewModel either in the XAML or in the code behind. What I wanted as the following:

DataContext="{Binding Source={StaticResource VMLocator}, Converter={StaticResource VMIndexerConverter}}"

Now you may be looking at my XAML above and comparing it to the XAML from John Papa’s post and be thinking what is really different? The difference is in this segment of code ConverterParameter=MainPageViewModel In his example he ‘hard wires’ the ViewModel which is being used up to the page and I did not want to do that. I wanted to use a standard naming convention (right, convention over configuration) and allow my locator to determine the ViewModel based on the current View.

So how did I implement my ViewModelLocator pattern, well lets take a look.

Code for ViewModelLocator

public class ViewModelLocator
{   
    private static readonly IDictionary<type, type> s_viewModelCache = new Dictionary<type, type>();
        
    public Type GetViewModelTypeForView( Type viewType )
    {
        var viewModelName = ResolveViewModelName(viewType.Name).ToLower();

        // We are try to cache the types in order to remove the assembly scan hit, this is optional of course and 
	// you may not want or need this
	// One thing to point out here is that this code ASSUMES that your view and viewmodel classes are in the 
	//  same assembly.  if this is not true for your project this code will not work as expected.  We made this
	//  assumption because it is true in our project
        var foundViewModelType = GetExistingTypeFromCache(viewType) ?? (from type in viewType.Assembly.GetExportedTypes()
                                                                        where viewModelName.Equals(type.Name.ToLower())
                                                                        select type).FirstOrDefault();
    
        // this will throw a custom exception type, you can use your own if you want
        if (foundViewModelType == null) { throw new ViewModelTypeNotResolvedException(viewModelName, viewType); }

        // Add the found view and viewModel to the cache
        AddToCache(viewType, foundViewModelType);

        return foundViewModelType;
    }

    private void AddToCache(Type viewType, Type foundViewModelType)
    {
        if (!s_viewModelCache.ContainsKey(viewType))
        {
            s_viewModelCache.Add(viewType, foundViewModelType);
        }
    }

    private Type GetExistingTypeFromCache( Type viewType )
    {
        if (s_viewModelCache.ContainsKey(viewType))
        {
            return s_viewModelCache[viewType];
        }

        return null;
    }

    private string ResolveViewModelName(string viewTypeName)
    {
        var asLowerViewTypeName = viewTypeName.ToLower();

	// ***** Below is OUR product's current naming conventions, replace with your own if you want *****
        // check to see if the view ends w/ "View"
        if (asLowerViewTypeName.EndsWith("view"))
        {
            return asLowerViewTypeName.Replace("view", "ViewModel");
        }

        if (asLowerViewTypeName.EndsWith("usercontrol"))
        {
            return asLowerViewTypeName.Replace("usercontrol", "ViewModel");
        }

        if (asLowerViewTypeName.EndsWith("childwindow"))
        {
            return asLowerViewTypeName.Replace("childwindow", "ViewModel");
        }

        return string.Concat(viewTypeName, "ViewModel");
    }

    public static IDictionary<type, type> ViewModelCache { get { return s_viewModelCache; } }
}

Code for IndexConverter

public class IndexerConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture) 
    {
        Contract.Requires<ArgumentNullException>(value != null);

        var locator = value as ViewModelLocator;

        Contract.Assume(locator != null,
                        string.Format(
                            "The provided converter value was expected to be of type {0} but was provided as type {1} which is not acceptable for this converter",
                            typeof(ViewModelLocator).Name,
                            value.GetType().Name));

        var viewType = GetViewType();

        var viewModelType = locator.GetViewModelTypeForView(viewType);

	// We are using the ServiceLocator pattern which is wrapping Ninject
        var viewModelInstance = ServiceLocator.Current.GetInstance(viewModelType);

        return viewModelInstance;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
        
    // This does incur a perf hit by looking at the stack trace, but in 
    //  my opinion this hit is worth it compared to having to manually wire items up
    private Type GetViewType()
    {
        var stack = new StackTrace();

        return stack.GetFrames()
            .Select(f => f.GetMethod())
            .Where(m => m.Name == "InitializeComponent")
            .Select(m => m.DeclaringType)
            .FirstOrDefault();
    }

}

Code needed in your App.Xaml

<MVVMLib:ViewModelLocator x:Key="VMLocator" />
<MVVMLib:IndexerConverter x:Key="VMIndexerConverter" />

Code for the custom Exception ViewModelTypeNotResolvedException

public class ViewModelTypeNotResolvedException : Exception
{
    public string ViewModelName { get; set; }
    public Type ViewName { get; set; }

    // Commented this out because i do not want to be able to create this without the VMName or the VName
    //public ViewModelTypeNotResolvedException() {}

    /// 
    /// Will build an instance of the exception and push in a default message based on the viewModelname and view properties.
    /// *** This is the lazy way to create the message ***
    /// 
    /// The name of the viewModel which was not able to be created or found
    /// The type for the view we were trying to bind the VM to
    public ViewModelTypeNotResolvedException(string viewModelName, Type view)
        : base(string.Format("When trying to resolve the view model {0} it was not found in the same assembly as the view {1}", viewModelName, view.Name))
    {
        ViewModelName = viewModelName;
        ViewName = view;            
    }

    /// 
    /// Will build an instance of the exception
    /// 
    /// The name of the viewModel which was not able to be created or found
    /// The type for the view we were trying to bind the VM to
    /// 
    public ViewModelTypeNotResolvedException(string viewModelName, Type view, string message) : base(message)
    {
        ViewModelName = viewModelName;
        ViewName = view;
    }

    /// 
    /// Will build an instance of the exception
    /// 
    /// The name of the viewModel which was not able to be created or found
    /// The type for the view we were trying to bind the VM to
    /// 
    /// 
    public ViewModelTypeNotResolvedException(string viewModelName, Type view, string message, Exception innerException)
        : base(message, innerException)
    {
        ViewModelName = viewModelName;
        ViewName = view;
    }
}

As you can see the code needed for this is not that complicated or difficult to implement.

One thing to understand with this post, I am NOT saying that the other implementations are bad or they do not work. In fact I am saying the exact opposite, they all are great and they all work and I used all their implementations as baseline for my implementation. What I am saying as the other examples did not meet my EXACT needs.

Please take a look at the code and let me know where I went wrong or what your thoughts are.

Till next time,

Ninject and binding to an existing Method (or Property)

Derik Whittaker — Thu, 30 Jun 2011 12:57:05 GMT

Ok, this is just a cool little feature I found in Ninject today and I am 100% sure I may be the last person on the planet to find this but who cares.

today as I was trying to get IoC implemented in our application at work I ran across the need to bind a type to an existing singleton in our application. The reason for this need is 2 fold:

I am not willing to take on the risk at this point of changing the ENTIRE application to utilize IoC
This is our RIA services domain context and I do not have enough knowledge in RIA services to know a better way to do this

So how do you bind a type to an existing method (or property)?

Make sure that you have the general convention based bindings setup correctly within Ninject.
Rebind your time and point it to the method you want to use

To Rebind you simply should do

ninjectKernel.Rebind<DomainContext>().ToMethod(x => MyClass.DomainContext);

In the above code what we are doing is Rebinding the DomainContext type to the Method on the MyClass instance. This will notify Ninject to not try to create a new instance of DomainContext but rather it will invoke the method, or in my case property, on my class.

I just thought this was kinda cool and wanted to share.

Till next time,

Ninject and Convention Based Assembly Bindings

Derik Whittaker — Thu, 30 Jun 2011 11:17:00 GMT

***** NOTE: This post was created because other posts on the net are outdated and the ninject libraries have changed. *****

When using any type of IoC container one of your goals needs to be to remove as much friction and ceremony as possible. One way to do this with an IoC container is to use convention based binding based on assembly scanning.

When using Ninject you can setup the container to bind via assembly scanning by using the Ninject.Extensions.Conventions extension and a few lines of code. Lets get rolling and learn how to do this

Getting the software:

Get Ninject – Download your correct platform version here
Get the Convention Extension – Download the binary or source here

Creating the Code to do assembly scanning:

Setup your Using Statements

using Ninject;
using Ninject.Extensions.Conventions;

Setup The Service location

private void StupServiceLocation()
{
    IKernel ninjectKernel = new Ninject.StandardKernel();
    
    // The AssemblyScanner is in the Ninject.Extensions.Conventions library
    var ninjectAssemblyScanner = new AssemblyScanner();

    // Here I am setting up the scanning in the assembly which contains the given interface
    ninjectAssemblyScanner.FromAssemblyContaining<IMessageboxService>();

    // This is important, without the call to using default conventions Ninject will not know how to 
    //  bind an IFoo to the Foo instance
    ninjectAssemblyScanner.BindWithDefaultConventions();
            
    // Tell the ninject kernel to do its job
    ninjectKernel.Scan( ninjectAssemblyScanner );

    // Reach into the container and grab the instance you are looking for.
    var messageBoxService = ninjectKernel.Get<IMessageboxService>();
}

OR use Lambda syntax

private void StupServiceLocation()
{
    IKernel ninjectKernel = new Ninject.StandardKernel();

    // If you would rather use the lamba syntax you can use the following
    ninjectKernel.Scan( kernel =>
	{
    	kernel.FromAssemblyContaining<IMessageboxService>();
    	kernel.BindWithDefaultConventions();
	});

    // Reach into the container and grab the instance you are looking for.
    var messageBoxService = ninjectKernel.Get<IMessageboxService>();
}

As you can see setting up Ninject to setup it’s bindings based on assembly scanning is very easy and requires pretty much NO code.

Till next time,

Ninject.Extensions.Conventions ported to work w/ WP7

Derik Whittaker — Sat, 04 Sep 2010 14:37:55 GMT

I have been using Ninject on WP7 now for a few months and I am just now getting around to porting the conventions library (this allows you to NOT have to manually bind all your classes but rather use a convention based approach). The port of this was pretty simple and can allow you to remove many, many lines of PITA code.

**** Please note, i have NOT put this through ALL of the paces so it is possible only the simple paths work now ****

To use the convention based approach all you need to do is use the code below

IKernel kernel = new StandardKernel();
kernel.Scan(
    x =>
        {
            x.From( new List {Assembly.GetCallingAssembly(), Assembly.GetExecutingAssembly()} );                    
            x.BindWithDefaultConventions();                    
    } );

To get this to work in your project you will need to reference the Ninject.Extensions.Conventions.WP7 assembly. I have posted the assemblies here and the code here (for now, will push to github this week)

Hope this helps other WP7’ers

Till next time,