Getting back on the saddle...my own MVVM framework

Let's face it. I've been lazy. It's been nearly two years since I posted any technical wonders (yes, that is tongue-in-cheek) I've stumbled across, which is a shame because there have been many.

 Since my last post, I had moved on to Silverlight 3 (at the time) and worked to about 80% completion on an online radiological image viewer. If completed, it would have been the first in the world (as far as I could tell) to enable a physician to view radiology-grade (meaning uncompressed with no degradation) images in a web browser.

Alas, I found a new job before I could finish it, and have since moved on to pure WPF using MVVM, Prism, and the Cinch framwork with MEF, with some unfortunate Winform upkeep and 3rd party integration (in C/C++).

So, why post now after so long?  Well, the reason is in part because of the continuing responses to a couple of my posts, mainly the altered Levenshtein algorithm post.  I enjoy helping when I can.

Another reason is that new jobs can be game changers, as any software professional knows. The right environment, the right tools, the right management, skillsets, etc. all can mesh together in a wonderfully new and invigorating manner so that you find yourself quite naturally growing and learning, restoring your once stifled passion for the purest software architecture and the highest standards of design and implementation.

Such has been the fortune I have found at my new company.

With my new job, I have gone from a sharp but incredibly fun learning phase into more of an implementation phase. The 'Ha' if you will of the 'Shu Ha Ri'. (I presented with Mike at this last code camp here in Utah - awesome presentation(s)).

Just today, I did an intro presentation at our Utah Code Camp on MVVM. Two things surprised me:

1. The concept of MVVM has been around for about 7 years (as of this post).
2. Most of the people attending my talk appeared to be in the middle to back-end (pun intended) of their careers and for the most part, had not ever touched MVVM. A good many of them looked to be about 10 years from retirement, if I can be trusted to judge a person's age correctly.

I prepared the talk with the idea that no one would understand MVVM completely by the end, because...how could you? It was not hands on (which I will change if I do it again) and unless you are writing the code and using the pattern, you really have no chance of truly understanding it. Most learn by doing and not reading.  But I did prepare slides that could be referenced and fully working code with a tailor made MVVM framework...which I considered to be a very good primer to MVVM.  Was it truly a good primer?  Let me know.

I wanted to leave ample time for questions and concerns from my talk, so I went over MVVM, then stepped through my code, which left 15 mins for...whatever. To my surprise (again), there were hardly any questions at all and most people had a very surprised look, like I had just wrecked their car or presented some radical new belief system that directly challenged their own.

This immediately led me to question how I could better present MVVM to developers who had been doing things a certain way for a long time but at least wanted to want to learn how to change it. This comes down, really, to how to motivate people to change bad habits, to which I really have no educated nor un-hypocritical answer (since I have so many myself).  I am a firm believer that everyone is responsible for who they are and all that they do and don't do.  But...that doesn't mean that just the right kind of nudge wouldn't help to inspire them to take ownership of their habits and proactively change them...right?  Right??

So, if for no other reason than to alleviate my own dissatisfaction, I shall attempt to present in a blog series how to create your own MVVM framework from scratch, focusing on practicing MVVM as a necessary step to understand, then to master it.

 I firmly believe that if someone is new to XAML (WPF/Sivlerlight), then they should learn XAML first, by itself. Then, learn MVVM by itself. Then and only then should you really feel free to utilize existing frameworks because you will understand how they work, what they are trying to do, their shortcomings, and their benefits.  This ideal learning path can obviously be preempted by work demands and constraints (where your team is already using a framework, for example), but in that case, you should do the best you can to still stick to the path.  Take the red pill.

So, by showing people how to create their own MVVM framework (as others have done - I just hope that I am encouraging MVVM adoption like them) I hope to inspire a true understanding of the pattern, on its own merit and not intermingling it with other techs and frameworks like Prism, MEFedMVVM, Catel, Cinch, MVVM Lite, etc. which can really make it more difficult to 'get' MVVM than to help, at first.

I would also like to present my own framework, which will be tailored to a specific application, as a part of the 'Shu' process, meant to inspire like-minded repetition and practice. What I will present can be applied again and again, whether you are one MVVM programmer amongst other code-behind developers, or you are on a team of MVVM-oriented engineers, or perhaps somewhere in-between.

The framework will certainly be no better than any other one out there, nor is that its intent. It will be presented merely as a vehicle to encourage adoption of the MVVM pattern through practice, practice, and more practice. I will try to keep it simple, but flexible, and ideally grow it to work and exist in a complex application that is at least somewhat close to what professionals experience in the 'real' world.

It has taken me a while to arrive at this determination, but the fire is lit, and I will do my part to spread the good word.

Any ideas on WPF applications...submit them now.  No guarantees and all the code will be, of course, publicly available...somewhere (git maybe?).

Comments

Popular posts from this blog

35x Improved T-SQL LevenShtein Distance Algorithm...at a cost

The hidden workings of __doPostBack - Full or Partial Postback?

Facing Death...dum de dum dum