Text transcript of show #241. November 18, The MVVM Pattern with Laurent Bugnion

Transcription

1 Hanselminutes is a weekly audio talk show with noted web developer and technologist Scott Hanselman and hosted by Carl Franklin. Scott discusses utilities and tools, gives practical how-to advice, and discusses ASP.NET or Windows issues and workarounds. Text transcript of show #241 The MVVM Pattern with Laurent Bugnion Scott talks to Laurent Bugnion about the often misunderstood Model-View-ViewModel (MVVM) pattern. What's the different between this pattern and MVC? Can I use this pattern for Silverlight, WPF and Windows Phone 7, and what Open Source projects can support this pattern? (Transcription services provided by PWOP Productions) Our Sponsors Copyright PWOP Productions Inc. Page 1 of 6

2 Lawrence Ryan: From hanselminutes.com, it's Hanselminutes, a weekly discussion with web developer and technologist, Scott Hanselman. This is Lawrence Ryan, announcing show #241, recorded live Thursday,. Support for Hanselminutes is provided by Telerik RadControls, the most comprehensive suite of components for Windows Forms and ASP.NET web applications, online at In this episode, Scott talks with Laurent Bugnion about the Model-View- ViewModel pattern. Scott Hanselman: Hi. This is Scott Hanselman and this is another episode of Hanselminutes. On today's show, we're going to learn about Model-View- ViewModel and we've got an MVVM expert, Laurent Bugnion calling in. Where are you now? Are you traveling? Laurent Bugnion: No, I'm actually back home. I was in Berlin last week for TechEd Europe, and I came back last weekend and I'm home now for a moment. Scott Hanselman: Fantastic. Well, thanks so much for pausing your travels for a moment and chatting with us. I appreciate it. Laurent Bugnion: Yeah, me too actually. Scott Hanselman: So I'm trying to get my head around MVVM and folks know that I'm a web person and I've done a lot of MVC. MVVM, for some people who don't do WPF or Silverlight on a regular basis, is yet another acronym that sounds confusing. It's another architectural pattern, it's another thing to learn and also I hear a lot that the Microsoft tools don't necessarily give me real strong scaffolding, a strong framework for which to put my MVVM model on top of. So I need you to start at the beginning. Help me understand what MVVM is, what Model-View- ViewModel is, how it relates to MVC, what's missing, what's not and what I can do to take a look at this. Laurent Bugnion: Sure. So MVVM is very similar to MVC in the sense that it's also a separation pattern. So it's a pattern which is use to separate components in your application. Like the name shows, the M and the V, the Model and the View are actually the same as in MVC. The big difference is really at the controller level. In MVVM, what we do is that instead of having one controller to the application which is now driving the Views, we actually have, for each View we have an object called a ViewModel or sometimes also called the Presentation Model and that's the major difference. These patterns have quite a few advantages in Silverlight and WPF over MVC. You know, it doesn't mean that you cannot use MVC in Silverlight and WPF, but it's just a pattern which is a little bit more natural when you do Silverlight and WPF in fact. Scott Hanselman: When I'm doing MVC, Model View Controller, the controller is what we call a front controller in that it's on the frontline and it's the first thing that gets called when someone clicks a button or does something. Where's the controller in MVVM? Laurent Bugnion: Well, in MVVM, things are a little bit different in the sense that we rely very much on something which is very powerful in Silverlight and WPF which is called Data Binding. What you do when, you know, every time the user is actuating something on the View, there is actually -- this action is post directly to the ViewModel in fact. Now, there are cases where it's a little bit different because you have also in the Views, like in ASP.NET, you also have some code-behind behind your Views which can be executed. We try to reduce the amount of codebehind because code-behind is a little bit more difficult to test automatically with unit test. So what we try to do is to have a communication which is as direct as possible between the View which is actuated by the user and the ViewModel which is going to react to this actuation by executing methods, etc. We have a few tools at our disposal to do that. So data binding which I've mentioned which is really linking or binding the View to the ViewModel and also things called Command for example which are really ways from the View to actuate something on the ViewModel directly. So in this sense, the controller is kind of -- how should I say -- it's kind of dispatched between multiple objects. In fact, we don't just have one controller or one ViewModel but in fact we have for every View in the application we have an object which is fulfilling that role. Scott Hanselman: Hmm. Okay. Well, let me try to put it into the context of the kinds of demos that I usually see when someone is learning Silverlight or WPF. Let's say that I have a book object that's in the database and I make a data access layer and I go and I get a list of books. So I'm in some code somewhere and I have a list of book. In demos, someone might just data bind that list of book directly from the database or Entity Framework and put it into a datagrid or list and it 'll say "Hey look, great job. Data binding is wonderful." What's bad about me doing that, just taking a list of book from a database and putting it on the screen? Laurent Bugnion: Well, the biggest problem that you will get in that particular example is that if you suddenly decide to move to a different database system, or you decide to move to a different ORM, or you decide to separate your application in a client server app and to have the client running on the client computer, for example in the web browser or with Silverlight and you want to have your database on another computer, what it means is that you're going to have to modify quite a lot of things in your application while when you use a separation pattern like MVVM, what you will need to change in that particular case, you know you will have the Page 2 of 6

3 connection to see objects which is going to be done in the ViewModel but your View will mainly remain unchanged actually. So you try to have as loose as coupling as possible between your View on one end and the database at the other end or whatever data position system you have, and by adding some layers in between your resource fills that. So that's one advantage of using MVVM over others, but this one makes the application really more maintainable and easier to extend. So that's probably one of the main advantages. Scott Hanselman: Where would I start an example like that? Is this in a small example? Is this simply a matter of just making a books' ViewModel class which is effectively a copy of a book and then shuffling data back and forth between the two? Laurent Bugnion: Not quite. So a ViewModel is really bound to the View. So for example, in your particular example you would have maybe a View which is called a Shelf, for example a BookShelf, and you have all your books' object which appear on that shelf. So what you would have in that case, you would have really a BookShelf ViewModel which is driving the whole data, getting the data and preparing them in collections. So that's the first ViewModel that you get in your application. This is a ViewModel which is driving the View. Then after that, your book object, as there on are multiple cases, in one case let's say you get your book object directly from Entity Framework through WCF for example, in that particular case you can actually be able to represent your book object directly in the View because WCF has that property of wrapping an object and it creates a proxy object. It will actually make it so that you can data bind two properties on that object and the secret behind that magic is called INotifyPropertyChanged. So the very important thing to say is that we havein Silverlight, WPF, in fact in whole of.net, which data binding rely on. So in the particular case of the BookShelf, you actually don't really have to wrap your book objects in a ViewModel, but you will have to wrap them in a ViewModel if you want to add properties and those properties are typically things which are very much View oriented like for example let's imagine that you want to modify the title of the book and then save that book back to the database, what you can do is have a property which is called IsDirty for example and this property is set to true when the title has been modified by the user but the book has not been saved yet to the database. These kinds of properties are not things that you want persist in the database. What you do is that you create the wrapper around your data object or on your book object and that's also what we called ViewModel. There is a slight confusion because of we use the same name, so the view model which is driving a view and also the ViewModel which is a wrapper around the data object but in a sense it's all the same. It's there to host properties that you can data bind to actually. Scott Hanselman: Well, that brings up an interesting question because when someone is doing XAML, there is this thing called a Value Converter and people will say this is the moment when you change the data to look more like View. But it sounds like what you're describing is that I'm going to do more of that work in the code-behind and basically get the ViewModel as close as possible to being a model of the View as possible and the data binding in the XAML would do less work. Laurent Bugnion: Yeah, that's absolutely correct. So value converters are great and there are definitely places where you absolutely need them. On the other hand, value converters are a little bit costly in terms of performance and especially when you use them on the Windows phone which you know it's a computer but it's smaller and a less powerful computer. So that can actually cost you quite a lot of salt. What we do instead is since we have the ViewModel which is preparing which is kind of massaging the data so you will write and preparing them in the sense that you can rebind to them very easily, it's actually easier to not use value converters and instead to just have a property which is of the right type. This leads quite a few people to say that when you use MVVM you just don't need value converters anymore. In fact, I think it's actually a little bit more subtle than that. There are cases where value converters will actually make your life easier so why not use them. But it's true that in many cases you can actually rely on simply having additional property on your ViewModel and prepare the data in that way and that will definitely enhance your performance. In Silverlight and WPF on the desktop you might not even notice that, but on the phone it's actually not disabled so you need to be careful about that. Scott Hanselman: Could you go in an example, using our book example say something about a value converter is and what kind of typical example? I think not everyone who is listening would know what a value converter is. If I was doing it like the regular way and I had a property on my book and I use a value converter, what would that provide me? What's an example? Laurent Bugnion: Sure. Well, you know you could imagine that for example your book has a promotion. So let's say, okay, this week 20% less on that book, and this information is actually stored in the database. So when you get the object, you will have maybe a Boolean flag for example which I locate and now I have 20% discount or you could even have a double value which says that the percentage that it discounted is like 20% less. Now with this value it's actually a little bit hard to start something at the level of View because I might want to show a visual indication that there is a promotion on that book like maybe show a flag or show anything. I cannot really do that directly because all I have for me is a Boolean Page 3 of 6

4 or a double and what I really want to have is something which is for example a visibility. Visibility is a type, it's an enum actually. It can be visible or collapsed, and in Silverlight we use that to show or to hide visual elements. So what you can do is wrap your book into a Book ViewModel and add a property which is called the -- well, in that case, okay, you're with a value converter. So if I don't use a ViewModel, what I will do is that I will create a Boolean to Visibility Converter which actually is a converter that we'd probably use most in Silverlight and then you will say, okay, my visual element indicating the promotion is going to be data bound to that flag, to that Boolean flag, through the Boolean to Visibility Converter. So every time I have the value through, then the visibility of the video element will be visible and then the user will see that there is something. So that's an example of a Value Converter. Now if you don't want to use the Value Converter, what you can do is wrap your book data object in the Book ViewModel and expose a property which is of type visibility directly and what this property does is just fetch the flag and return visible or collapsed depending on the flag. Scott Hanselman: Hi, this is Scott coming to you from another place and time. Are you using Agile Practices to manage your software development? There are lots of tools in the market that manage the steps of a project but most of them focus on individual roles. Get ready for a solution that caters to the success of the whole team. The guys at Telerik introduced TeamPulse to the Agile Project Management Tool that will help you gather ideas, estimate, plan, and track progress in a common workspace. Finally, companies, regardless of their size, can use a lightweight and convenient tool that makes all the stakeholders work as a united team even if they're in different countries. By combining intuitive interface and the power of Silverlight, TeamPulse removes the road blocks that you typically face in applying Agile in an effective manner. No more lost data, no desperate systems, no lack of critical analytics regarding the health and velocity of your project. See for yourself, get a free copy for five users in one project at telerik.com/teampulse, and please do thank Telerik for supporting Hanselminutes on their Facebook fan page, facebook.com/telerik. We do appreciate it. There wouldn't be a Hanselminutes if there wasn't Telerik helping us. Okay, so let me paraphrase and see if I understand. Since making something visible or not visible in Silverlight and WPF is an enumeration, not just a simple Boolean and data binding is effectively a free for loop. When I data bind something I say "Hey that collection over there, I want you to apply it to this grid over here," and then the for loop as it were, is done for you. Someone spins through your list and applies it to a grid or list. With a Value Converter, that conversion is going to happen on each item every single time that binding happens. If you run your application for hours and you bind dozens and dozens of times, that Value Converter is running over and over and over, hundreds or thousands or millions of times. But if I simply say that the ViewModel is in fact a model for the View, I do that on the backend and then when I do my data binding I'm simply not sending a Boolean but rather the enumeration that the data binding wants which means data binding does less work. Is that correct? Laurent Bugnion: There is something which is not quite correct in what you said in that the data binding is actually not going to be executed like millions of times or anything. It's going to be executed only when the value changes which is not very often. So as a matter of fact, you know, it will be executed quite often when you do have things like UI virtualization which means that the template for the item is going to be rendered quite often. UI virtualization is a technique where all the items which are outside of the visible stream are actually garbage collected so you don't see them anymore which means that they are just gone from memory so you can improve those moments like that. This is a great technique, but every time that you bring those items back into views then the data template is recreated and then the binding is going to be evaluated and then you will get your value converters in the way. In that sense, having a property on the ViewModel is not going to solve that problem. It is just going to avoid having an additional level of indirection through the value converter. So again, on Silverlight on the desktop you will probably hardly notice it. We just notice that binding in general on the phone is a little bit slower and binding through converters on the phone is noticeably slower so we try to avoid that. Scott Hanselman: Okay. So we always want our phone, to use a Scott Gu term, we always want to scroll and to be battery smooth and if I have thousands of items but I have a View port that's showing 10 or 15 as I scroll in and out and scroll quickly is that when the value converter is going to be firing because that's when the data binding is firing. Laurent Bugnion: Yeah. That's exactly that. If you use UI virtualization which is what most applications actually do, your value converter is going to be fired every time. That's correct, yeah. Scott Hanselman: But if I had hundreds or thousands of items in a list except this time the list is a ViewModel, would I have not done the conversion of the Boolean to visibility for items that may never even be shown so I may have done the work ahead of time? Laurent Bugnion: Yes. So you can do things like that. There are multiple techniques to load data. So virtualization is definitely one technique. Another technique would be to preload the items and do not virtualize them. At the same time, the big issue here is that it's really more complicated to implement Page 4 of 6

5 because virtualization is given by the control, by the listbox control which is built in Silverlight so you don't have to worry about that. If you start doing preloading items and caching them and searching them in an event and executing the conversion, this is called actually to write so it's more complex. It's doable but it's more complex. Scott Hanselman: One of the things that Microsoft has been criticized on specifically around MVVM is that there wasn't, or maybe now you can tell me, standardization for Microsoft is not like I say file a new project and I'm all set for a formal MVVM and this has caused a dozen or more Model-View-ViewModel toolkits to pop up which I think is confusing for new people who are about to start out. Laurent Bugnion: Yeah. That has been an issue especially I would say last year and in the beginning of this year. We start seeing things coming out of Microsoft like for example there is, if you install the Blend SDKs, there is actually a data application there which is built according to MVVM. If you install Prism especially in the new version, in version 4.0, they do actually have guidance and compliments which helps you to build MVVM applications. So the good news is that Microsoft has been listening to the community and checking what maybe are the best practices out there and using that. At the same time I think that MVVM has really started to emerge in the community. I mean, even though Silverlight and WPF are built according to MVVM, so this pattern is there from the start, but I think we're really starting to use it a lot in the community especially like in my case I started using it a lot because I wanted to work with designers in Expression Blend and that has made my life so much easier. So all the people that I know have started using it because they absolutely wanted to unit test large parts of their applications including the ViewModels, it's absolutely made sense to have this separation in place. So different reasons. We saw really in the community a large movement in favor of MVVM if you want. As with all things, when you see people starting to use a pattern, you start to repeat the whole consequence over and over again and that's when you start creating toolkits and frameworks basically. So there are quite a few frameworks around. I think that in time especially this year, we saw a few frameworks which emerged as being probably most used, and especially now with Windows Phone 7.0, we saw that there are actually a couple of frameworks which are used which are really from the community. At the same time we see some guidance coming out of Microsoft and I know that I've been talking with quite a few people at Microsoft about that in the Prism team and outside. I think there is kind of a guidance coming out but yes, there was definitely some confusion around that in the beginning for sure. Scott Hanselman: Is there an official MVVM guidance from Microsoft? I see that on the WPF CodePlex site, there's a toolkit from 2009 and you mention Prism. What's the official MVVM toolkit from Microsoft and then what are some open source ones that you would recommend? Laurent Bugnion: In terms of toolkit at Microsoft, I don't really know one. I think the closest that they have is really in the Prism guidance. They have really parts which are really talking about MVVM and explaining how to take advantage of that pattern and how to implement it. In the Prism libraries, you also have compliments that you can actually use to build applications according to the MVVM pattern. So that's really where I would look now. The WPF toolkits that you've mentioned, as far as I know was something like an experiment and I don't think it was actually ever maintained so there's the 0.1 or whatever it was. So I think that's probably not the best direction to look into. So yeah, I would definitely look into Prism. In terms of open source, there are quite a few like you've mentioned. I think that we see a few toolkits emerging and have been quite popular. So one is definitely Caliburn. Caliburn is a toolkit which is made by Rob Eisenberg. He's an MVP and his toolkit is very, very impressive in terms of what it can do in terms of features and functionality. It's a toolkit that relies on convention over configuration which is also quite popular nowadays and I see it's definitely worth looking into that. The other toolkit that I have to mention obviously is the one that I'm doing myself so it's called the MVVM Light Toolkit. It's also open source. It's on CodePlex. This toolkit took a different approach than Caliburn. It's a lot less powerful. It's a lot lighter so you can basically use whatever components you want and leave the rest. But if you want to use the whole thing, you can go into Visual Studio and do file a new project, a new MVVM light application and have everything which is prewired. There are some others coming up. One is called Jones for Silverlight and Windows Phone 7.0. There are a few others as well, you know, probably too many to mention. But Caliburn and MVM Light are the tools that I see being quite popular nowadays. Scott Hanselman: Now speaking kind of generally, when I install a framework like this, what am I getting? If this is a simple model, then why do I need to framework in? When I install something like this, how is it constraining me and hopefully helping me? Laurent Bugnion: Yeah, that's a great question because as I often say there is a lot of confusion around MVVM itself. I mean is that a pattern, is that a toolkit, is that the helper, is that the DLL or whatever. MVVM is really just a pattern so you can implement patterns in multiple ways which kind of explains why there are so many toolkits, it's because they are just helpers that help you implement MVVM in different ways. In the case of MVVM Light, what you get when you install it is a set of DLLs. So there are two DLLs plus the System.Windows.Interactivity.dll which from Page 5 of 6

6 Blend SDK and those DLL have components that help you to build applications according to MVVM. One component is a class called really Command which is, you know, it's like a point of entry for a method that you place on your ViewModel and what you can do is that every time your user is activating the control on the View, the Command is going to be invoked directly on the ViewModel without having to write an Event Handler. So this is a loose way if you want to build an event, to react to an event and one reason why we use commands in MVVM is that we want to separate the View from the ViewModel as much as we can. We don't want to handle Event Handlers because those are very, very tightly coupled elements. By using commands, what we do is that we basically tell the designer you can use any control you like. As long as this control is going to invoke Command, I'm fine. And what we tell to the developer is you don't know how the command is going to be invoked. It could be a click on a button, but it could also be a mouse left button down on the rectangle for example. You don't know that. It doesn't matter what I want, it's that you just invoke the command and execute a method. So commands are very important. So you have that. Another thing that you have is something that I called a Messenger. In Prism they call that the Event Aggregator. In fact, this is an object which allows you to send messages from one object to another but in a very decoupled manner. So typically if you have multiple ViewModels, like in WPF you could have multiple windows open at the same time or maybe in the Windows Phone 7.0 you could have settings, ViewModel and then the main ViewModel, you can basically pass messages from one to the other but in a very decoupled manner. So that's another class. So there are also classes into that but in a sense if you want those classes are not really forcing you, you know, nobody is forcing you to use them but if you do implement the MVVM pattern you're going to be faced with some issues that those classes help you to solve. So that's what they do. Another thing that's in MVVM Light Installs, like I've mentioned, are project templates that you can just do a file new project and then start with an application which is already considered according to the MVVM pattern. Scott Hanselman: When I buy into the whole MVVM thing, how much other things do I have to buy into? Do I have to start thinking about Dependency Injection, and unit testing, and IoC? Is this a framework that brings other frameworks along with it that I may or may not be familiar with, or is this something that I can get started with in a fairly vanilla kind of a way? anything. You don't really need to unit test. I mean, obviously we recommend that you unit test but if you don't want to that's okay. Your application will work. So I would say that you can really do that in a very progressive manner. So if you decide to go with MVVM, I would start with a small example where you don't use any Dependency Injection and then start building on that, and then after awhile that's always the same story with Dependency Injection. When your application grows, then you start seeing the advantages of using Dependency Injection to create your objects like one thing that we do a lot in the MVVM is that we decouple actually a little more than what I explained. We use services to talk to the model and services to talk to the View as well. So one example could be, okay, if I want to show a dialog to the user, I'm going to have something which is a dialog service and this dialog service can be invoke in a decoupled manner. Like this ViewModel doesn't have to worry about showing a dialog. It's just, hey, show me a dialog and give me back the result and that's it. These kinds of services as well as services -- I talked to some models, to some services like okay, get books or save a new book or things like that. Those can very well be injected inside of ViewModel which, if you want using an IoC container for that, you know, it's going to help you. But if you don't want, you can definitely go ahead and create those services by moving in the code and injecting them directly into ViewModel. That works too. So it's just a matter of scaling I would say. Scott Hanselman: All right. I'm going to put links to all of the different frameworks that we've talked about and a few others, as well as links to videos of talks that you've done and other resources for folks who are listening to get involve and can start learning about MVVM themselves. Laurent Bugnion: Very cool. Scott Hanselman: Thank you so much for taking the time to chat with us today on Hanselminutes. I really appreciate it. Laurent Bugnion: My pleasure. Scott Hanselman: This has been another episode and I'll see you again next week. Laurent Bugnion: Yeah. So it depends on the implementation that you choose obviously, but for example in my case I really don't want to force anything on anybody. So you can implement MVVM application without needing IoC if you don't want, without needing a Dependency Injection framework or Page 6 of 6