Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

MVVM Best Practices

43 minutes, 32 seconds


Right click “Save as…”

In this episode, recorded at TechEd in Houston, Robert is joined by Brian Lagunas of Infragistics, who shares with us best practices for building applications using MVVM. Brian starts off by reviewing what MVVM is and what it isn't. He then demonstrates several things you should not do and why you should not do them. In addition to the demos, Brian gives his advice on how he approaches some common scenarios.


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • This video really shows how simple the MVVM pattern is. I'm definitely guilty of confusing ViewModel and Façade in past projects.

  • Awesome show thank you.

    Can't wait to see what Show #100 brings :D

  • Does Prism not count as a framework?

  • @DSaylor - Actually, Prism is not an MVVM framework, and before the release of Prism 5.0, had no built-in MVVM classes (though DelegateCommand can be argued).  Only recently, did the Prism team ship the new ViewModelLocator support, which still doesn't constitute an MVVM framework per se.  At it's heart Prism is guidance for creating composite/modular WPF applications.  So Prism sits at a higher level than just MVVM.  It is more about the architecture of your entire application rather than just your View development patterns.  You can use any pattern you like with Prism; MVC, MVP, code-behind, and it is not dependent on MVVM.

    Also, with the new 5.0 release of Prism, the various functions have been separated into separate libraries that can work independently of each other, and are not required to be used as a whole.  So if one app needs modularity, and nothing else, then it will use the Prism.Composition.  If your apps just needs event aggregation, then use Prism.PubSubEvents.  If you only want ViewModelLocator and DelegateCommand use Prism.MVVM.

    I will have to admit, the new Prism.MVVM NuGet package can be argued as a framework, but it is not required for use when writing a Prism application.  I still don't use ViewModelLocator in my applications.  Although, it is starting to grow on me a little bit.  So as far as my statement "I don't use MVVM frameworks", that still holds true.

    I hope this helps answer you question.

  • @Brian Lagunas: I see.  That does help.  Thanks!

  • Bent Rasmussenexoteric stuck in a loop, for a while

    Nice and useful tips. Robert interrupts a little too often but otherwise great.

  • TedMTedM

    Zero code behind - once is broken this pattern - never is fixed nor corrected – use Behavior<T>, learn more XAML – it is not a matter of quick and dirty, fast implementation because build is in an hour – it is principle – like gravity – you cannot pretend it is a negotiable existence.

  • @TedM:  Sorry, but I completely disagree with you.  It has nothing to do with "quick and dirty".  There is absolutely nothing wrong with having code-behind in a predominately MVVM application.  It's not about learning more XAML, it's about solving problems and being pragmatic when necessary.  One issue is when people try to delegate a View responsibility to a ViewModel, where it doesn't belong.  Sometimes it is necessary to place code in the code-behind.  What is your technical argument for not placing code in the code-behind?  Testability? Maintainability? Extensibility?  Sorry, you can still place code in the code-behind and accomplish all of those elements of development.  Just don't reference any concrete implementations.  For example, if you needed to call a method in your ViewModel from code-behind, do it through an interface.

    (DataContext as IViewModel).DoSomething();

    This code still delegates the action to the ViewModel without referencing it, it is still maintainable, and it is still testable.  A pattern is just a name we give something we do often to solve a problem.  MVVM is not law.  It's a pattern.  Principles are great to have in life, but principles can become very limiting, and costly, in software development.

  • @Brian Lagunas:

    I don't suppose you have the time to write a book on MVVM best practices (preferably directed towards WPF).  I've read quite a few of the books on MVVM out there and have found them lacking.

  • @BigCountry: A while back, I started writing a book. I got 55 pages in and decided books aren't for me.  I don't have the time or patience to write a book.  Now videos, that's a different story :0)

  • While I enjoyed the show and both guests, I have to disagree with Brian.  He keeps hitting on the flexibility as if it were a good thing.  Too much flexibility can be a bad thing.  I want a Visual Studio Project Template that sets up a defacto standard Prism project implementation.  I don't want to revisit all the conventions and layout details and decisions with each app.

    The lack of a good standard is holding me back from developing anything.  I want to write to a well-known standard that will be around for a few years.  I don't want to write an app now, then have to rewrite it every couple of years as a new standard "emerges."  Burbling about creativity and flexibility aside, suppose someone comes into Brian's project which has 200 views, who has no idea how things are laid out or how the program is "wired."  A confusing mass of idiosyncratic code with no standards or conventions. The Horror!  The Horror!


    Please get together with Mike Taulty and write some Visual Studio Templates.  The only ones currently available are out of date, for the app store or Windows RT.

  • @Si1ver1ock: It's important to realize that patterns are not standards.  I think most software developers will agree that flexibility in any framework, tool, or library is a must if it is to be used in a wide variety of development projects.  Everyone's standards will be different, because every development team has different ways of writing software.  Development standards are the responsibility of the dev team, and will vary depending on the type of application you are writing.  If you want standards, create them, document them, and then use them when writing all of your applications.  Just be aware, that your standards will change over time.  As you learn new things, or new approaches, or new technology is released that help solve a problem, you will update your standards to fit your technical skills, and development processes.  This doesn't mean you have to rewrite your existing applications to use your updated approaches to writing software, it just means you have learned something new and have grown as a developer.

    I think your statement may be a little over the top.  Anyone that looks at my WPF Prism apps will have no problem figuring out how things are wired, or laid out, out because I use common patterns, and development practices, that most experienced developers are familiar with. 

    If all you are looking for is for someone to tell you how to structure your applications and write your code, then just ask a developer you respect for their opinion.  I will tell you how I do it for just about every WPF app I write.  I have my own set of project templates that I created that are unique to the way I write applications.  I don't publish them publically because I realize that not everyone likes to do things the same way I do.

    I personally hesitate to even use the word standard, as that implies that I have to abide by, or be locked into, some type of hardline approach to writing software.  I prefer to use the term guidance.  I provide guidance on writing successful WPF Prism applications, but the option is always available to go outside that guidance to solve a unique problem, or to implement a feature that doesn't fit, or have, guidance to begin with.

    Just my 2 cents.

  • Jan KratochvílJan​Kratochvil Jan Kratochvil

    I agree with Robert that XAML binding exceptions should crash the app, not just log to console. That makes them a bit too easy to miss :).

  • Thanks Brian.

    I thought this would be another mis-guided discussion on MVVM and some dogmatic views and misunderstanding between Prism and MVVM. I was pleasantly surprised. I agree with most of what you have said here.

    In my experience, what many WPF devs are missing is the next 40-60min of this discussion.

    • What is a Model?
    • How should I inject my dependencies?
    • How do I keep my UI responsive?
    • How do unit test my ViewModel and Model (while still having code that keeps it responsive)?
    • Does everything have to be a View, a ViewModel or a Model? Do I have to Suffix everything with these distinctions? i.e. you use Person, Would your real project be PersonView, PersonViewModel & PersonModel? What if my Person(Model) is a graph that has Addresses/Favorites/Basket etc hanging off of it; are these models too? Should they all be suffixed with "Model"? 
    • How does DDD fit in with MVVM.


    Would enjoy seeing a show with this level of Q&A happening (i.e. the actual questions that come up in any Enterprise MVVM app after the first hour of coding).

    Again good job. 



  • @LeeCampbell: Most definitely!  Once we understand what MVVM is and isn't, let's learn how to apply it, and use other patterns and design principles to create a complete application.

  • Great video, and I agree to @Brian Lagunas on "Principles are great to have in life, but principles can become very limiting, and costly, in software development."

  • @Brian Lagunas: Thanks for bringing up and clarifying the dos and don'ts of ViewModel base classes (and backing them up with good reasons) - those were of great value to me! More of these please :)

    @LeeCampbell: Excellent point. I would very much like to see those questions answered as well.

    In addition to that, I would like to see more real-world end-to-end scenarios/user-stories instead of the usual "Hello MVVM" entry-level stuff. Specifically, scenarios where:

    • If models (business entities) arrive from an existing library or via a WCF service, should they be exposed directly or stay behind a Facade ie Person->PersonFacade->ViewModel property
    • What about commands vs behaviors and using Blend to hook things up
    • Most of my entities need to go through business rules for validation - what are best practices for implementing those within the MVVM model (data annotations/value converters/ViewMode methods/behaviors/code behind). 
    • Most of my Views are user controls that are isolated from each other but still need to communicate and share state (either with their host or between each other)... are there best practices around that? 

    Would definitely appreciate these topics being covered in next installment of "MVVM Best Practices" 


  • @JanKratochvil: I am with you and Robert on this as well. I think there should be a VS debugger option to "treat XAML binding exceptions as errors" or something...

  • @Brian Lagunas: You mentioned that you were working on this massive MVVM-type app with hundreds of views. Is it open-source by any chance? If yes, would you share a link? If not, would you be able to share the wisdom you've gathered in creating and maintaining it?... a PluralSight course perhaps :)

  • @DanGarkusha: It's not open source, but I am always willing to share my experiences and approaches to creating software.  Currently, I am working on a "What's New in Prism 5.0" Pluralsight course, then I will be doing an "Advanced Prism" course.  After that, I will be doing a "Practical Prism" course, where I will cover most of what you are asking for.  An end-to-end application built from File -> New, all the way to deploying the application.

  • @Brian Lagunas: That's awesome! I am looking forward to them all, "Practical Prism" in particular...

  • Best MVVM video I've ever seen hands down!!!

  • MythgarrMythgarr

    Overall a very excellent talk - thank you! When discussing the MVVM vs Facade relationship Brian says "The problem is that's not MVVM - that's Facade." Were you simply pointing out a technicality - that this isn't technically part of the MVVM pattern - or is there an actual problem with using this pattern with MVVM?

    In most actual use cases the Model I'm working with (whether databases, web services or POCOs) don't provide property change notification. What is the problem with using a ViewModel to represent the Facade?

  • @Mythgarr: Yes and no.  A pattern is doing nothing more than giving a common name to a development approach that we use every day so that when we talk about it, we all know what we are talking about.  So if you are saying you use MVVM, but in actuality you are using Façade, then there is a possibility for a miscommunication.  Also, while there a technical difference based on the pattern definitions, there are also functional differences.  For example, you would not want to be creating commands in a façade object, but instead only in your ViewModel.  By identifying your object as façade, you can more easily add validation and logic to it that can be shared, without impacting existing Views, or worrying about adding custom logic for any particular View.

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.