:: { DeVigner } ::

I posed this question to Silverlight Forum to see what kind of response I get from the MVVM gurus. I plan on tracking this discussion and eventually add my thoughts and discuss my projects that transpire based on what I learn from the members. I have been researching a lot about Silverlight implementation of MVVM pattern and how purists and not so purists creating solutions to stick the “ideaology”. Anyway, more on that later, here is the reproduction of my question here:

I am to the point where I think MVVM and Silverlight are still not very happy together. There are way too many theories and opinions on its implementation but I haven’t yet seen any concrete examples that cover not just DataBindings related issues but also complex UI interactions. And yes I have read blogs after blogs and concpets but now its a make or break moment for me. For a full fledged graphically complex SL application that depends on lots of data; how does this whole thing glue together (or not)?

In purist sense here is what I understand so far with random thoughts and in no particular order:

• MVVM should satisfy realistic seperation-of-concerns end-to-end. This means the whole application should be able to run with only Model and ViewModel; no View required. Data validations and testability satisfied.
• Model defines the data structure and data calls ONLY. VM acts as an intermediary bewteen Model and View with validations logic etc. So the Async calls will have to occur on the Model and VM needs to be notified when completed.
• The moment you inject View-centric logic into ViewModel (VM), it can be considered anti-pattern, for example any DP through VM to make a control change its color or effects some visual properties. (maybe a bad example but you get the idea I hope)
• No marriage between View and VM, they should live in complete de-coupled fashion without being aware of each other. Which means no View-First or ViewModel-First discussion. In theory Dependency Injection/IoC should achieve the lose coupling, thats where Unity/Prism comes into play – or does it?
• Eventing and Commanding through Prism V2
• Does Reactive Framework (LINQ to Events) fit somewhere in this model to address some of the async pattern issues? VM listening in on Model through this (push vs. pull)?
• Creating dynamic controls programmatically and injecting them into XAML through ContentPresenter Binding for example = Anti-Pattern. Since designer never got involved in creating and designing the control – hence we can’t just sneak it in there without his/her knowldge, or can we? Going with purist mindset we shouldn’t or can’t do that.
• Designer should not have to write any code at all (except behaviors/triggers/actions maybe(?)) and developer shouldn’t worry about how View is laid out or designed including interactions etc. Now with that theory who is really responsible for behaviors and other interactivity libraries as it involves a fair amount of code which I do not expect the designer to write and test. Does the designer tell the dev that this is what they want as a behavior so go cook it…? Are we stepping in on each other already?
• Are we missing another layer that controls complex UI interactions programmatically on the View? if yes then where should this layer live? For example I want to hover my mouse over on the List control items and some things pop up or are highlighted on a Map control all on the same View. Do we address this via behaviors/triggers or code behind? Got any concrete example(s)? Since the code behind for the view is purely UI centric, is it acceptable and/or testable? Can I expect that MVVM cops are not going to arrest me for this crime? Purists would probably throw a fit but won’t give you a solution – so what gives?

I’d like opinions and hopefully some concrete solutions to the above random points if possible. You may pick and chose any or all of the bullets if you feel like answering or commenting. My goal is to write a SL MVVM application with a purist mindset and be successful at that. I have developed MVVM phobia at this point cuz everytime I sit down to test out use-cases, in the most simplistic ones I win but when I jump into more realistic and complex application design, things start going downhill from there and MVVM cops start dancing infront of me…

I’d like to eventually put this case to rest and blog about it based on my findings from fine people like yourselves and ofcourse with due credit and references. Once all is said and done I’ll probably decide for myself whether MVVM will be able to satisy all of my application’s complex needs under purist terms or not. If not then oh well…, I guess I will have to break some rules. And far and foremost is SL really ready to adapt this pattern even with the help of Prism or similar libraries?

source: http://forums.silverlight.net/forums/t/133053.aspx

Story by Nasir Aziz

Tags: .NET, Featured, MVVM, Silverlight, WPF