:: { DeVigner } ::

This post is a follow-up to my previous post “Silverlight MVVM Purist Style…” where I posed the question regarding MVVM and Silverlight:

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

• 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.
• 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.
• 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.
• Shawn Wildermuth 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.
• 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?
• 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.
• 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…
• 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.
• 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.
• 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”.
• 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. I may be off base but that’s where I am at today. My opinions may change as I gain more experience in this adventure, and when that happens I’ll’ definitelty report here.

It’s still a discussion but I am banging the gavel… order order!

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.

Story by Nasir Aziz

Tags: .NET, MVVM, Silverlight