Thursday, October 21, 2010

Why Use the MVVM Pattern with Silverlight Applications?

The probability of hearing or reading about the title question of this article if you are either a Silverlight or WPF developer is substantial. However, there are significant problems when searching for a proper answer to this question.

To begin with, there are numerous and varied ways in implementing methodologies like MVVM, most of which are used based on personal preference. To a novice trying to educate themselves, this leads to disparity in information. Complicating this factor is that many of the articles or videos that attempt to describe the MVVM pattern also include components of other architectural patterns. This adds unnecessary complexity to understanding the MVVM pattern because of the inconsistencies in the pattern being described. In this article, I will elucidate only the MVVM pattern - nothing more, nothing less.

First of all, let me answer the title question succinctly. Silverlight (XAML) and the Model-View-ViewModel (MVVM) architecture evolved together, thereby affecting each other. In effect, this means that inherent in Silverlight's framework elements and CLR objects are the mechanisms to implement MVVM's loose coupling and separation of concerns. I will go into greater detail on the specific classes and objects in .NET that are primarily involved in hooking everything up further on in this article.

The loose coupling and separation of concerns translates to the ability of large developer teams to work independently on different parts, bringing the pieces together at runtime utilizing classes or object interfaces (as opposed to user interfaces). Another enormous benefit of this is that not only can multiple developers work on different parts of the application simultaneously, designers - for the first time in the history of .NET development - and developers can work on the same code at the same time. Having designers "speaking the same language" as developers solves the longstanding dilemma of a developer taking what the designer gives them and having to rewrite everything to work with the applications. Furthermore, designers - for the first time also - can see what they are doing with data driven controls in the design view in Expression Blend. It's evident that the workflow between professional graphic designers and application developers has been monumentally improved.

Let me back up a bit and give an overview of what MVVM is and does for those of you who aren't familiar with it. MVVM, as architecture, is the mature, successful version of what n-tier attempted to accomplish: quarantine the user interface from the program logic and data. Where Model-View-Controller (MVC) may sufficiently accomplish this goal for ASP.NET applications, MVVM is a refined evolution custom-fit for Silverlight.

There have been intermediate patterns between n-tier and MVVM, all with the same goal, but none of them truly accomplishing the objective until the advent of MVVM and XAML. XAML, being an extension of XML, is inherently tool-able, resulting in the ease of building visual and other editors for those who use it.

If a new Silverlight developer were to dive into a new project without knowing better, they might attempt to put all logic into the codebehind of the MainPage.xaml.cs, as typically has been done in ASP.NET pages. Not only would this lead to difficult testing scenarios, but this methodology doesn't lend itself to long-term maintainability or extensibility. Testing code built like this needs a user interface (UI) to run and a human to debug, which adds to the complexity of finding errors. On the other hand, by using the MVVM architecture, only the "ViewModel" (which will be explained in the next couple of paragraphs) need be tested and verified before ever being bound to the UI.

Properly using MVVM, there is much less codebehind in MainPage.xaml. This is simply pure UI. Each entity in MVVM has its unique tasks, and they do them extremely well with complete separation. MVVM is an acronym for Model-View-ViewModel; let's elaborate on the functionalities of each entity.

At the uppermost level we have the "View". Ideally, the view consists only of the XAML UI and related UI logic. These are the Silverlight screens that are presented to the user. The View's responsibilities are to present data to end users and collect data from end users, period.
At the lowest level we have the "Model". This represents the entities that live on the server as well as the objects that are responsible for interacting with the data stores the application uses along with data persistence. Data interaction in Silverlight can be anything from RIA Services to web services or raw XML. Any CLR-object can be the binding source.

In between these two entities is the "ViewModel". This entity's responsibilities are numerous, but can be summarized as aggregating data that will be bound to the View, retrieved from the Model. This includes methods and states. Since Silverlight doesn't databind to methods, just properties and dependency properties, most of our data logic needs to be in property setters and getters in this ViewModel.

As previously promised, now I'll explain the specific objects in the .NET Framework that are involved in making MVVM and Silverlight work together. The binding mechanism in Silverlight links the View and ViewModel through primarily dependency properties and data context. Each framework element in the View (controls, UI elements, etc.) has a dependency property. These properties can be bound to instances of exposed public properties in the ViewModel. The ViewModel can update the View via the INotifyPropertyChanged interface in the ViewModel base, which is used to discover if the value of the properties have changed by raising the OnPropertyChanged event. This is a two-way conversation that extracts all of the data and logic from the View, but doesn't alter the UI's normal functionalities.

Lastly, I'd like to describe one last tremendous benefit of utilizing this pattern. Because all the logic is in the ViewModel, this entity can be copied from a Silverlight application and inserted into a WPF or Surface application, for instance. This cross-platform extensibility greatly increases return on investment (ROI) for companies that target multiple platforms.

- By Kim Schmidt, Guest Author from the Silverlight Group

Thursday, October 7, 2010

LayoutTransform RenderTransform Size Resize Sizing Xaml Hack and black magic...

ok, so this is just really making me tired all over. about every size months or so I run into this problem but really after solving it I nicely forget until it hits me in the face again. So amoung the zillion projects I'm working on I volunteered to help on any projects that have something for me. Fabio and Curtis are working on this cool project I can't talk about as such but here is this layout thing that came up in working on this control that needed fixed.

The issue is basically this. You have a control that is a set size and it has some element that is or needs to be layed out outside that control box's size. since its a custom control and its top element is a grid any thing laying out can only be the width of the grid. Event when rendered outside the control box using a translate transform etc. the last time this issue came up I remember there was also a rotate transform taht took me probably a day to figure out what was even going on but between Fabio, Curtis and I there wasn't to much wasted cycles on it but after going back and forth I did a number of tests to just to see what actually worked.

keep in mind that the control is a set size and the root element is a grid.

That being the case, here are the methods I tried to get something larger then the control box size layed out outside the box.

method 1: putting element in popup (wpf only trick, well sort of, you can do something like this in sl but its an even more aweful hack) works but lots of control issues... with behavior not the least of which is the element might still be there if the view is switched... this is a bad plan...

method 2: just trying to use a translatetransform to put it outside the box... no soup for you as your element is croped to the size of the control box (root element grid)... another bad plan...

method 3: chuncking the element into parts and transform it all into place... this works but is a silly hack... due to how messy the xaml gets... to me this is really a bad plan too unless something else didn't work.

method 4: put the element into a canvas and then transform it out... really? this works... feels like a hack but the xaml is very clean... #tiredallover

method 5: use negative margins... this really is against my inner designer or rather the xaml mess I've seen it cause is mind numbing. But alas used spairing this this is a clean xaml solution. Just bad on principal because it leads to abstract layouts that are difficult to visually decompose and mape to the xaml.

method 6: use a layout transform and then a render transform to size it down to smaller then the control box and then the layout transform to get it back to size and outside the control box...

this works... I don't even wnat to know why... I actually do know but really this is just well it makes me cringe but the xaml is fairly clean but its totally a hack... don't do this just for sanities sack but really it works... f... here is an example:

<ScaleTransform ScaleX="2.88" ScaleY="2.88"/>
<TranslateTransform X="210"/>
<ScaleTransform ScaleX=".5" ScaleY=".5"/>

I went with the canvas trick as the xaml is the most clean.

Friday, October 1, 2010

9 Speaking Engagements in the space of 5 weeks... about Silverlight

I think my head will explode or I'll get pretty good at it :) but here is my speaking engagements over the next four weeks oh and this is getting off from presenting at the big IxDA/Interact event 2 weeks ago...

* Windows Phone 7 Unleashed in Bellevue on Oct 07th on Phone 7 User Experience

* Windows Phone 7 Unleashed in Redmond on Oct 14th on Phone 7 User Experience

* Windows Phone 7 Unleashed in Boise on Oct 25th session 4 on Phone 7 User Experience and Session 2

* SilverlightConnections/DevConnections - Going from Silverlight to Phone 7

* SilverlightConnections/DevConnections - Multi Dos and Don’t touches

* SilverlightConnection/DevConnections - Breaking Down Walls

* Mediations on Xaml Zen - Corporate Xaml Workshop for Wirestone
(private workshop by invitation Only in Boise Oct 26th)

* SilverlightConnection/DevConnections - Metro for Developers on Windows Phone 7

* SilverlightConnection/DevConnections - Windows Phone 7 Application Performance Optimization

I'm wondering if this means I'm a professional yet? :)