Archives

Building HelloMEF - Part V - Refactoring to ViewModel

2010-03-08 00:07
In the last post we migrated over to the new DeploymentCatalog. In this post we rsquo;ll look at refactoring the code to incorporate the MVVM pattern. Code from the last post is available here Why ViewModel There rsquo;s a ton of content out there in the blogosphere that discuss the virtues of separated presentation patterns including MVVM. I am not going to reiterate those here, but I will point you at Josh Smith rsquo;s excellent MVVM article here. I rsquo;ll also shamelessly plug my own post where I shared my own view on the essence of MVVM (which is based on views of others i respect). In short it rsquo;s about decoupling UI logic for better maintainability which includes making it easier for a graphic designer to style the UI. So where are the maintainability issues in the current ldquo;app rdquo; Currently the main place is within MainPage.xaml.cs where you see the following code: public void OnImportsSatisfied() TopWidgets.Items.Clear(); BottomWidgets.Items.Clear(); foreach (var widget in Widgets) if (widget.Metadata.Location == WidgetLocation.Top) TopWidgets.Items.Add(widget.Value); else if (widget.Metadata.Location == WidgetLocation.Bottom) BottomWidgets.Items.Add(widget.Value); The logic is simple yes, but it still has issues. The main issue is that it is mixing UI business logic with the rendering. The logic which determines which item goes to Top to Bottom is a completely separate concern from how those items actually get displayed. Having the logic mixed in means nbsp; the code is very brittle where any slight change to the way the UI is rendered can break it. It also makes it difficult for a graphic designer from being able to change the look and feel of how the widgets are rendered. The second issue is that I am imperatively adding elements to the UI rather than letting the rich DataBinding engine do the work it was designed for. This makes it difficult to re-skin the UI. Third, in it rsquo;s current form, the logic is difficult to test, meaning if the logic breaks I am relying on QA / manual testing to pick it up. So ViewModel will fix all of this I say with confidence Yes! Using ViewModel will allow us to refactor the logic into a nice reusable and testable place. It will also gives us the decoupling we need to leverage the Silverlight rendering engine to it rsquo;s fullest. Along the way you will also see how MEF can help us with regards to implementing MVVM within our applications. We rsquo;ll introduce 2 view models to help us get there. When we rsquo;re done, our application will look like this. nbsp; Pre-requisites. nbsp; As with the last post, you rsquo;ll need our MEF codeplex bits for following along. If you start where we left off in the last post you rsquo;ll be fine. You rsquo;ll also need a copy of Laurent Bugnion rsquo;s awesome ldquo;Glenn Bock approved rdquo; MVVM Light, which you can get here and which we rsquo;ll be using for it rsquo;s ICommand default implementation. Let the refactoring begin! First we rsquo...
Read More...