tags:

views:

46

answers:

1

After fighting for a while with maintaining model-viewmodel relationships (eg. creating vm instances for each instance of model) I've got some ideas that might be quite controversial, but I'm curious of opinions.

What if VM class was made to maintain a static list of containers for model instances. Those could(or even should) be weak references so whenever model class instance is out of scope its viewmodel is automatically disposed. Another option would be to reuse vm instances.

Another idea that would work well with the first one might be creating an implicit cast operator from model to viewmodel class. I would always get the same instance of vm whenever casting from model instance.

What do you think about it ? Is this a hard violation of rules and MVVM pattern?

//edit I should probably provide also what was the motive behind this: in my app I have multiple places where I use one of my model classes and need corresponding vm references. In every such place I need to observe a collection and react to changes -creating or removing vm instances. This is basically the same code that is repeated in many places => I thought of creating only one place to do that (implicit cast is just a candy it's not required to solve the real problem). Or maybe instead of static lists I should create a manager that would handle view model instance creation for all my classes?

A: 

First of all, I am not to sure whether your ideas violate the MVVM pattern. In my opinion it is not that important to fullfill patterns in every case. A pattern in my eyes suggests strategies to solve problems. In most cases it is not worth following a pattern 100% by all means. If there is a pragmatic solution you should rather use this one. Of course this should be solutions that lead you to your aims, e.g. unit testable, separation of UI and applicatiopn logic and so on.

Anyway, when I was reading your article the first time I thought implementing a cast operator is good idea. But if I am not wrong, you need to reference the view model in your model. I always try to avoid that to maximize re-use opportunities. But I think having such a reference does not violate the pattern. Maybe someone else can tell more about that.

For me your manager idea is the best way. I use a similar way to create view models. It depends on how many view model you need to create, but you should rather create new view models than re-using existing ones. Somewhere I read that view models should be some kind of state machine to the view. Following this idea, you never know in what state the view model is when you re-use it. So the preferred way is to create a new view model.

Just some thoughts! Maybe there are some other ideas...

Florian
Thank you for your answer:) To briefly comment on it : I wanted to hear opinions about possible disadvantages of such an approach and thus my question was maybe a little off the track. Another thing here is that I don't have model coupled to view model in any way. Implicit cast operator might be defined on both types that are part of the cast so in this case I'll define it in vm class.You're perfectly right about vm being a state machine for view, so reusable vm instances might not be a good solution.
kubal5003
What I really need is one vm instance per context in which it is used so this becomes quite tricky. Another approach might be defining different properties/events for different contexts, but that might lead to quite a mess provided that I need two very similar usages of my class. I'll have to think about it more.. ViewModel manager now seems to be a better option as it gives greater flexibility and abilities to use some more information(like context)
kubal5003