Everyone, and by that I mean anyone that has been coding for more than a year, talks about decoupling and layers. It’s all about building an n-tier architecture, and about decoupling the layer so that they can be changed later on.
And however much I understand this, and like it, and use it, I still argue that it is sometimes overkill. And even though I definitely can argue both sides of this topic, I am not even going to get started doing so. Maybe I will in a later post, when I feel like getting flamed… :)
This post is about how decoupling your view from your view logic using MVVM can really be helpful. And I am not going to talk about how unit testing will help or anything like that. I am going to explain why MVVM is more important than just testing by showing an example…
A couple of seconds ago, I mentioned that I didn’t think the DB layer would change very often in a company. What I do think will change quite frequently in some situations, is the view. Especially if we are talking about a public facing website for example. A public web should really go through a redesign every year or two…honestly… So it would make sense to make it possible to change the view easily, and that’s where MVVM shines.
I have spent the last couple of weeks working on a WPF kiosk application for a client. This is a short deadline project as usual, and the reason for the inactivity on my blog. The application in question was initially just supposed to be a rewrite of a WPF kiosk app from VB to C#. Then it turned into a move from being a local kiosk with a “regular” website, to being a WPF kiosk with an Azure based service. But the WPF kiosk app was to stay with its original design, but moved form a code behind programming model to MVVM.
Before the client even got the new piece of software deployed, they decided to change their image and thus make their kiosk and website design out of date. So they decided it needed to be updated.
I quickly threw together a design concept in half a day, and sent it over to the client who then took parts of my concept and mixed it with parts of their design ideas and created a set of JPG visuals.
As the application functionality didn’t change, all the VMs could be left alone, and I could focus on the UI/XAML. So as soon as the JPG’s were in my inbox, I got started. And about a day or a day and a half later, the UI was 95% done and ready to be tested. And testing should be fairly simple as the VMs are still the same. So testing means looking through each of the views, making sure they look as they should and that all data bindings work.
Having to do a redesign like this with a non MVVM based application would have taken a lot of time. And a lot of time is a lot of money in the real, boring world where clients live. But in this case, the client got a completely rebranded kiosk by paying for a developer for about 3 days (yes 3…the math here says a little less, but there are still some things to sort).
So however much I do believe that decoupling certain things in an application might be overkill, I do still believe that decoupling the view is well worth the small pains it sometimes causes. And that is without considering the fact that the code actually becomes a lot more structured and contain a lot less bugs than it used to do without MVVM for me.
Now I just wish the website would have been as easy to rework. Luckily it will be handled by a guy who is great with HTML and CSS, which is great as I apparently have forgotten how to write HTML. Something that became quite obvious during this project. Good thing I can live in “XAML land”.
I really hope that information like this makes it more interesting to adopt MVVM. Even though it sometimes can be a little tricky to get into…