MVVM Good or Bad form to define DataContext this way. RRS feed

  • General discussion

  • Question

    Which is best approach for setting DataContext.

    1) Set the DataContext in code to an instance of the ViewModel?

    Pros: If I want to use a button I can just use the click event and call the method I need on the ViewModel.  WAY easier than using ICommand and the hoops for that pain.
    Cons: Designer doesn't pick it up.  Make binding much slow when the designer in Blend or VS don't see the object Properties.

    2) Set the DataContext in the XAML?

    Pros: Much easier to design with.  There is no code behind everything is set to the view model
    Cons: ICommands and running methods via Properties.. that just sucks.

    I personally like it in the Code behind, as it makes handling Buttons and etc, much easier.  I am still using a ModelView, just calling the methods directly.  I don't see why that is bad form, if it is, someone fill me in.  It would be great if I could see the properties in designer though.  That does make life easier.


    Sunday, July 22, 2012 8:36 PM

All replies

  • I have been using MVVM for a while; first and foremost things is 'best practices or patterns are there to solve our problems effectively while keeping our requirement in line. Here in MVVM, setting data context in View or ViewModel holds fine (for me at least). Because you are not violating Model-View-ViewModel pattern rather called View-First approach or ViewModel-First approach. Maybe a quick look at a personal manifesto.

    View-First: The View has a relationship to its ViewModel(usually through data binding).
    ViewModel-First: The ViewModel creates the view (usually through an IOC container).

    Blendability mantra is been achived setting datacontext through XAML. Blendability promote

    a) UI testability which perhaps one among advantage of MVVM.

    b) UI to be modified in tools such as Expression Blend for visualization and layouting.

    Seeting datacontext through code allows us to have better instance management through

    a) IOC container to resolve the ViewModel dependency which promote loose coupling.

    b) better object life time management

    In concise, you can use any approach based on your requirement. Both are there to serve few specific need as described.

    When I have been given an opportunity to decide the best appraoch; I have decide to merge these things together since my solution demands following things

    a) UI testability/ Blendability. 

    b) Dependency inversion/injection.

    c) Better instance management.

    So I have decide to following similar appraoch like below. 

    In codebehind :
        public CustomerUserControl()
            if (!DesignerProperties.IsInDesignTool)
                DataContext = new CustomerViewModel();
    And in my ViewModel:
        public CustomerViewModel()
            if (IsInDesignMode)
                // Design time data for blendability
                Customer = new Customer()
            else {
                  // Load customers from VM and set as data context

    You can find a blog here which talks about the same in detail. 

    If this post answers your question, please click Mark As Answer. If this post is helpful please click Mark as Helpful.

    Nair S

    • Edited by Nair S Sunday, July 22, 2012 10:44 PM formatted to improve redability
    Sunday, July 22, 2012 10:41 PM
  • If you create a ViewModel, and use click events to wire up calls to the ViewModel then you are not using MVVM.  You are tightely coupling the View to the ViewModel in that case.  The Command route is the way to go, but that still doesn't force you to define the ViewModel in Xaml or Code behind.  I prefer XAML when possible because it allows the designer to populate with data at design time in many cases.  Setting up the commands is really not much more work, I suggest just using lambda expression right in the command for simple commands.
    Sunday, July 22, 2012 11:23 PM
  • You are wrong with MVVM, WPF very strong with Databind.
    Monday, July 23, 2012 5:10 AM