I apologize for
the long question, it reads a bit as a rant, but I promise it's not! I've summarized my question(s) below
In
the MVC
world, things are straightforward.
The Model has state,
the View shows
the Model, and
the Controller does stuff to/with
the Model (basically), a controller has no state. To do stuff
the Controller has some dependencies on web services, repository,
the lot. When you instantiate a controller you care about supplying those dependencies, nothing else. When you execute an action (method on Controller), you use those dependencies to retrieve or update
the Model or calling some other domain service. If there's any context, say like some user wants to see
the details of a particular item, you pass
the Id of that item as parameter to
the Action. Nowhere in
the Controller is there any reference to any state. So far so good.
Enter MVVM. I love WPF, I love data binding. I love frameworks that make data binding to ViewModels even easier (using Caliburn Micro a.t.m.). I feel things are less straightforward in this
world though. Let's do
the exercise again:
the Model has state,
the View shows
the ViewModel, and
the ViewModel does stuff to/with
the Model (basically), a ViewModel does have state! (to clarify; maybe it delegates all
the properties to one or more Models, but that means it must have a reference to
the model one way or another, which is state in itself) To do stuff
the ViewModel has some dependencies on web services, repository,
the lot. When you instantiate a ViewModel you care about supplying those dependencies, but also
the state. And this, ladies and gentlemen, annoys me to no end.
Whenever you need to instantiate a ProductDetailsViewModel from
the ProductSearchViewModel (from which you called
the ProductSearchWebService which in turn returned IEnumerable<ProductDTO>, everybody still with me?), you can do one of these things:
call new ProductDetailsViewModel(productDTO, _shoppingCartWebService /* dependcy */);, this is bad, imagine 3 more dependencies, this means
the ProductSearchViewModel needs to take on those dependencies as well. Also changing
the constructor is painfull.
call _myInjectedProductDetailsViewModelFactory.Create().Initialize(productDTO);,
the factory is just a Func, they are easily generated by most IoC frameworks. I think this is bad because Init methods are a leaky abstraction. You also can't use
the readonly keyword for fields that are set in
the Init method. I'm sure there are a few more reasons.
call _myInjectedProductDetailsViewModelAbstractFactory.Create(productDTO); So... this is
the pattern (abstract factory) that is usually recommended for this type of problem. I though it was genious since it satisfies my craving for static typing, until I actually started using it.
The amount of boilerplate code is I think too much (you know, apart from
the ridiculous variable names I get use). For each ViewModel that needs runtime parameters you'll get two extra files (factory interface and implementation), and you need to type
the non-runtime dependencies like 4 extra times. And each time
the dependencies change, you get to change it in
the factory as well. It feels like I don't even use an DI container anymore. (I think Castle Windsor has some kind of solution for this [with it's own drawbacks, correct me if I'm wrong]).
do something with anonymous types or dictionary. I like my static typing.
So, yeah. Mixing state and behavior in this way creates a problem which don't exist at all in MVC. And I feel like there currently isn't a really adequate solution for this problem. Now I'd like to observe some things:
People actually use MVVM. So they either don't care about all of
the above, or they have some brilliant other solution.
I haven't found an indepth example of MVVM with WPF. For example,
the NDDD-sample project immensely helped me understand some DDD concepts. I'd really like it if someone could point me in
the direction of something similar for MVVM/WPF.
Maybe I'm doing MVVM all wrong and I should turn my design upside down. Maybe I shouldn't have this problem at all. Well I know other people have asked
the same question so I think I'm not
the only one.
To summarize
Am I correct to conclude that having
the ViewModel being an integration point for both state and behavior is
the reason for some difficulties with
the MVVM pattern as a whole?
Is using
the abstract factory pattern
the only/best way to instantiate a ViewModel in a statically typed way?
Is there something like an in depth reference implementation available?
Is having a lot of ViewModels with both state/behavior a design smell?
