Silverlight MVVM Purist Style - are we ready yet?

Silverlight MVVM Purist Style - are we ready yet?

10-04-2009 10:02 AM |

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:

1. 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.
2. 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.
3. 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)
4. 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?
5. Eventing and Commanding through Prism V2
6. 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)?
7. 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.
8. 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?
9. 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?

Re: Silverlight MVVM Purist Style - are we ready yet?

10-05-2009 4:18 AM |

As an author of some of those blogs/articles, I'll say that if you're worrying about a purist view, you're being dogmatic. The reality is a pattern is there to serve you. 

 I can't answer all the questions, but for #4, I think that the marriage idea I propose in my Prism MSDN article does what you want. I use a marriage to mix them.

Re: Silverlight MVVM Purist Style - are we ready yet?

10-06-2009 1:46 PM |

Thanks Shawn. And yes I have read your articles too, great stuff and good pointers. I guess the question is where do you draw the line and how do you determine at what point you have broken the rules. Just like FxCop, there should be a MVVM Cop tool also ;)

It took a little time to get my head around MVVM for Silverlight, but having said that there are many approaches and methodologies available through SL Toolbox which can be used to satisfy the pattern, just like what you said "the pattern is there to serve you" and then you have to find the right tools to make it happen.

I am taking your advise and will try not to be dogmatic about it. If there is something I don't know today, I am sure I'll learn it in the future or can always refactor it to get closer and closer to the purist version but without intent.

Cheers!

Re: Silverlight MVVM Purist Style - are we ready yet?

10-06-2009 10:13 PM |

This may not be of any help but when my team and I sat down and researched everything about MVVM in Silverlight, Prism, and MFC we started our application knowing exactly how everything worked together. There was no question in our minds where each bit of code would live and function and how perfect of a framework we would create. It would be perfect and pure. It would be so clean and easy.

It was a pretty cuddly dream and then the reality of the gray areas jumped out and scratched our eyes out. Simply put if the pattern is not understood, followed, and embraced by your team then it is an anti-pattern. So once we were in the face of reality writing a large complex LOB application with all these pretty patterns being evangelized all around us we sat down and decided what was real, usable, and applicable for us.

I am not a purist anymore so I wont express my opinions further as you want Purist Style.

I can hardly wait till I get a chance to back Shawn into a corner next month ;) jk

Re: Silverlight MVVM Purist Style - are we ready yet?

10-07-2009 2:41 AM |

@isheeple: Thanks for your comments, the more I am reading and researching the more I see the same issues that you have shared, which doesn't surprise me. I'd like to hear your honest opinions though, because that's the whole point of my question. I want to go purist but then again it may not be possible...

After extensive googling/binging/researching, following are my views at the moment, as in work-in-progress views:

1. MVVM looks good in theory and for short half-assed ideal situation demos but due to lack of proper guidance and concrete examples it is more trouble than its worth, ie; if you are going for the purist style.
2. MVVM hinders speedy development initially. Devil is in the details. We end up fighting to implement the pattern and lose focus from the actual excersize which is developing software and solving some problem.
3. MVVM doesn't have clear guidance on UI intensive type applications. Has anyone done a Silverlight game purely based on MVVM yet? I haven't seen any atleast.
4. Shawn coined the term "Prism is a Buffet", I think I am going to say "MVVM is a Buffet" also! I'll pick and chose what works and throw the rest of the theories out the window.
5. The reason I chose Silverlight/WPF is because of its graphics capabilities. MVVM is forcing me to think Windows Forms and is trying to make it too easy for the testers. Why do we pay them anyways?
6. If I want to make sexy LoB apps or the sorts with cool effects and what not, MVVM gets in the way. Limits your creativity and adds more work, hence dev time. Almost sounds like its a conspiracy to hinder your creativity power.
7. In its defense (somewhat), custom behaviors/triggers etc. can solve some graphics/UI interactivity issues under MVVM but not all of them. There are limitations still - thats where your code gets murky, some behaviors, some triggers, some code behind, and some VM. Oh my readabilty and maintenance just got better! Sure...
8. MVVM is based on plethra of opinions. There is no standard yet that I can put a finger on. Plus the more I read and view it the more it looks like MVP.
9. If we like the long acronyms, I'd propse new terminology that actually makes sense: Call it V-VM-M (In View-first situation) and VM-V-M (In VM-First situation) just to be fair and to further identify the implementation. If you have gone hybrid then it means you have committed a sin.
10. NO code-behind is not a rule. I am sure we will come up with another layer for code behind essentially mimicking it. Why not just use it as it is. Avoid it and move code to VM as much as you can, and anything that justifiably can't be moved to VM (trust me there are a lot of cases) then go for it. Make sure comment your code in code-behind starting with "Intended Anarchy".
11. Never put your code out for MVVM review. No one will agree and it will become a fist fight session. Just make sure you follow best-practises in your code and general architecture otherwise.

CONCLUSION: Keep your data/calls/bindings related items in M and VM layers. Triggers/Behaviors/etc in XAML (VIEW) layer plus any additional programmatic UI/graphics/interactive can go in code-behind. Make good use of commanding and eventing as much as possible through Prism. These are my rules now and I am sticking to it and documenting it here.

Its still a discussion but I am banging the gavel... order order!

Since these forums are meant for problem solving, I am taking this discussion to my blog now in order to avoid pollution. See you there if interested...

NOTE: If you happen to be a developer and a designer at the same time, I recommend you get your head completely shaved before you go dive into this mess. This will help you from unintended baldness, serious scalp injuries, lost relationships, and what not. You get the idea.

Re: Silverlight MVVM Purist Style - are we ready yet?

10-12-2009 8:51 PM |

Found another interesting "feature" in Blend3. I posted it HERE

Blendability – A whole new meaning… Tell me if you experienced the same?