Wpf usercontrol with parameterised constructor

Question

Hi,

We are using Microsoft Unity and dependency injection and so we have parametrised constructor for the usercontrol. How to inject this dependency into usercontrol using XAML?

I have added the usercontrol in XAML as below.

xmlns:usrRefundArrivalProcessor="Ttl.Refunds.Wpf.Dashboad.Application.Usercontrols;assembly=Ttl.Refunds.Wpf.Dashboad.Application"

Answer 1

Seems rather easy. Why don't you simply add "a public parameterless constructor" to your UserControl? You may choose not to use it in your code directly but that is what the Designer is looking for. If you want to make sure it is never called in code, put a check for presence of Designer and throw an exception if Designer is not detected.

Answer 2

Dependency injection does not imply parameterized constructors. In fact, if you look at the samples that come with Unity, most of the dependency injection is done by properties with the [Dependency] attribute.

Unity works very well with XAML, but only if you don't use parameterized constructors. Convert your UserControl to take its dependencies using properties with the [Dependency] attribute, and you can easily use XAML.

public class MyUserControl : UserControl
{
  [Dependency]
  public ISomething Something { get; set; }

  [Dependency]
  public IWhatever Whatever { get { return (IWhatever)GetValue(WhateverProperty); } set { SetValue(WhateverProperty, value); }
  public readonly DependencyProperty WhateverProperty = DependencyProperty.Register("Whatever", typeof(IWhatever), typeof(MyUserControl));

  ...
}

Note that a [Dependency] property can be declared either as a DependencyProperty or as a plain CLR property, as shown above. This sounds like confusing nomenclature but in practice it is very simple.

To specify the UnityContainer in XAML and get automatic configuration, just create an inherited attached property "UnityHelper.Container" whose PropertyChangedCallback simply calls BuildUp on the specified container and passes in the object's type and the object:

public class UnityHelper
{
  public static IUnityContainer GetContainer(DependencyObject obj) { return (IUnityContainer)obj.GetValue(ContainerProperty); }
  public static void SetContainer(DependencyObject obj, IUnityContainer value) { obj.SetValue(ContainerProperty, value); }
  public static readonly DependencyProperty ContainerProperty = DependencyProperty.RegisterAttached("Container", typeof(IUnityContainer), typeof(UnityHelper), new FrameworkPropertyMetadata
  {
    Inherits = true,
    PropertyChagnedCallback = (obj, e) =>
    {
      var element = obj as FrameworkElement;
      var container = e.NewValue as IUnityContainer;
      if(container!=null)
        container.BuildUp(obj.GetType(), obj, element==null ? null : element.Name);
    }
  });
}

Now you can assign a UnityContainer to your root window and your entire application will use it, for example you could do it in your window's constructor as follows:

UnityHelper.SetContainer(this, new UnityContainer() ...);

Or you can assign the unity container using XAML at any desired level of the tree:

<UserControl ...
  my:UnityHelper.Container="{DynamicResource MainUnityContainer}" />

Having said all that, I think you'll will find that WPF's advanced data binding features and resource dictionaries together eliminate 98% of the reasons why a person might want to use Unity in the first place. You may find it better in the long run to move away from Unity and go with simple MVVM. At the very least I would try pure MVVM on a test application to see how it works before developing much code relying on Unity for dependency injection.