Initialize hierarchical tree viewmodels with unity

Question

I'm investigating a change in our application to use Prism. At the moment I'm struggling with the initialization of hierarchical structures.

Basically I have a base class of which other classes inherit, simplified like this:

public class NodeViewModel : INodeViewModel
{
    Node Node { get; private set; }
    public ObservableCollection<INodeViewModel> ChildNodeViewModels { get; private set; }

    public NodeViewModel(IUnityContainer container, Node node)
    {
        Node = node;
        ChildNodeViewModels = new ObservableCollection<INodeViewModel>();

        foreach (Node childNode in Node.ChildNodes)
        {
            // Some initialization code
        }
    }
}

Up to now I didn't use the container so we only had the Node argument. Each inherited class had an attribute which we used for model to viewmodel mapping.

[ModelToViewModelMapping(typeof(InheritedNode ))]
public class InheritedViewModel: NodeViewModel
{
    public InheritedViewModel(InheritedNode inheritedNode)
        : base(inheritedNode)
    {
    }
}

I then had an initialization line like this:

ChildNodeViewModels.Add((INodeViewModel)System.Activator.CreateInstance(ModelToViewModelMappingDictionary.GetMappedViewModelType(childNode.GetType()), System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Instance, null, new object[] { childNode }, null));

My question is twofold.

I don't know if my old trick with the attribute is a common solution for the mapping. I suppose not but it keeps things together and manageable in an easy way. I'm not sure the viewmodellocator is a good solution and I'm completely new with it, I haven't tried.
How can the initialization be done. The Resolve method uses a type that I can resolve in one way or another (my attribute solution, viewmodellocator, ...) but Unity's ParameterOverride needs a string parameterName. As shown in the code above that fails because the parameterName is not constant, every inheritted class has its own parameterName.

Thanks in advance!

score 1 · Accepted Answer · answered Mar 22 '17 at 08:20

Ad 1:

I like your current option because you avoid creating a lot of factories this way.

Ad 2:

You have to provide the parameter name for unity, so you have to manually reflect the constructor and find the name of the parameter you want to override. Then you can resolve your view model through unity and pass in the model. But there's a catch! When resolving with a parameter override, you override any parameters that happen to match the parameter name in the override, anywhere in the hierarchy and no matter what type. In the best case, the types don't match and you get an exception, in the worst case, a wrong dependency is injected, silently. Have fun debugging that...

Recommendation:

Stick with your current way of producing the view models, and inject the dependencies when the objects are constructed. This has drawbacks, too, because you cannot use constructor injection and you need a reference to the container, but I'd prefer those to the rather unpredictable parameter override.

var viewModel = Activator.CreateInstance(...);
_container.BuildUp( viewModel );

with

internal class MyChildViewModel
{
    [Dependency]
    public ISomeService MyDependency { get; set; }
}

Thank you for your answer. I have been thinking about a similar approach as well but that in turn complicates other parts which are now in the constructor. After lots of further reading I think I'm misusing the container to create objects. What I'm going to try now is let the container inject an abstract factory. This would be a better approach anyway since a factory is what is really needed. The concrete factory can then request it's own dependencies through constructor injection. — Jef Patat, Mar 22 '17 at 12:35
Yes, that's always possible, and I'd generally recommend it, but it becomes annoying if you have to create tens or hundreds of factories, that basically all do the same thing (i.e. create view models for tree nodes). Therefore I like your attribute plus activator.createinstance approach... — Haukinger, Mar 22 '17 at 16:20

score 0 · Answer 2 · answered Mar 21 '17 at 06:39

0

Your trick is common. It is more common to see:

InheritedViewModel < InheritedNode >

Where also:

NodeViewModel < T >

And of course:

INodeViewModel < T >

Part of the power of Prism is getting the Instance you need from the Container like this:

Container(or how you'll call it).GetInstance(or whatever its called) < INodeViewModel < InheritedNode >>()

You need to register first in the container InheritedViewModel < T > with INodeViewModel < T > for that to work

answered Mar 21 '17 at 06:39

Mishka

508
3
5

I'm not fully understanding your answer, could you clarify a bit and map it to the code samples I provided in the question? – Jef Patat Mar 21 '17 at 08:19
In your Bootstrapper, you config your container. You register for an Interface, What class that inherits it, should be created. Later on, when you ask the container for something that implements it, you will get an instance of the type you registered. https://msdn.microsoft.com/en-us/library/ff660923(v=pandp.20).aspx – Mishka Mar 21 '17 at 08:51
Yes, I understand that. But I'm not getting how I can add the parameter to the constructor. Knowing that the parameter name can be different for every inherited NodeVM as I clarified in the question. – Jef Patat Mar 21 '17 at 09:38
When you call Container.Resolve>(params[] parmas). http://stackoverflow.com/questions/787001/can-i-pass-constructor-parameters-to-unitys-resolve-method – Mishka Mar 22 '17 at 10:36

Initialize hierarchical tree viewmodels with unity

2 Answers2

Linked