Wpf usercontrol with parameterised constructor

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"

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,
    PropertyChangedCallback = (obj, e) =>
    {
      var container = e.NewValue as IUnityContainer;
      if(container!=null)
      {
        var element = obj as FrameworkElement;
        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.

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.

It works, but performance are quite bad when you use grids or complex WPF screens. Inherits = true implies that all the GUI elements created will have the PropertyChangedCallback of the attached property called just after constructor, even if that specific GUI element doesn't need Unity at all. And when you have grids, everytime a new row appears all the GUI elements are created on the fly, with that callback called. this was killing performance of our grid, so we have had to remove UnityInjection done this way.

But nevertheless there are places where we need UnityInjection in codebehind, and we have not found a nice solution for this problem, even if we are using MVVM. Some complex user control is designed using MVVM, where the ViewModel of the control is created by the codebehind of the control itself, that is created by the XAML that is using the control. In this specific case the ViewModel of the control doesn't know anything (yet) about Unity, but we DO need unity Injection in it, for accessing external resources there registered.