Partager via

What is an MVVM-friendly DomainDataSource?

  • Article

The second most requested feature on our WCF RIA Services Wish List is an MVVM-friendly DomainDataSource. The neat part about this request is that it means many different things to many different people. The challenge in addressing it is to figure out what are the most valuable changes that will satisfy the greatest number of scenarios.

This is where I turn to you. I’d love to hear some opinions about what people think is important. For now, let’s keep the discussion constrained to two questions.

  1. What are the two most important changes for us to make to the DomainDataSource to make it MVVM-friendly?
  2. If those changes were made, would you use the DomainDataSource in your View Models?

I know there’s more on this topic to talk about, but let’s start slow. I've started this thread on the forum to discuss the issue.

Comments

  • Anonymous
    September 01, 2010
    i find it challening to get clarity on what being mvvm friendly really means.  so 1st a level set on what i see as the differences so my subsequent ask can be looked at further or immediately dismissed. from the reading i've done it seems there is little dispute around the meaning of "m[odel]" and "v[iew]".   the differences between mvc, mvp and mvvm seem to lie in what is instantiated 1st and therefore is responsible for instantiating the other pieces and creating the necessary data bindings. in the mvc camp there is the asp.net mvc2 experience where mvc uniqueness comes from it being an environment where you have the controller instantiating instances of the view and the model(s) that it then injects or binds to the view. in the mvp camp there is the wpf/sl xaml experience where mvp uniqueness comes from it being an environment where you have the view instantiating instances of the presenter which takes care of instantiating instances of the model(s) that it then injects or binds to the view. in the mvvm camp there is the wpf/sl xaml experience where mvvm uniqueness comes from it being an environment where you have the view instantiating instances of the viewmodel, preferrably in xaml, which takes care of instantiating instances of the model(s) that are then bound to the view, preferrably in xaml. with this level set on my perception of the differences i would see the two most important changes for you to make to the DomainDataSource to make it mvvm friendly as follows.
  1.   ensure that xaml declaration of the domaindatasource and all its queryparameters, sort and filter settings something that can be accomplished entirely using blend+vstudio gui toolbox, properties or other services, i.e. i don't want to have to hand code that xaml or break down into view contstructor initialization c# code
  2.  ensure that xaml binding of the model(s) exposed by the xaml DomainDataSource can be accomplished entirely using blend+vstudio gui toolbox, properties or other services, i.e. i don't want to have to hand code that xaml or break down into view event handler code to accomplish this.   I also want the same experience for hooking up entity detail records consisting of taxonomy data and/or detail records to update/add dataForm experiences entirely using blend+vstudio gui toolbox, properties or other services.

  • Anonymous
    September 01, 2010
    change 1: We want the internal EntitycollectionView of the domaindatasource to be used independently chane 2: We like to see changes in filling the items to domaindatasource. i.e: can assign items without going to server (local entities) , and fill entities via domaincontext. I want to use Comaindatasource in my ViewModels.

  • Anonymous
    September 01, 2010
    change 1: We want the internal EntitycollectionView of the domaindatasource to be used independently chane 2: We like to see changes in filling the items to domaindatasource. i.e: can assign items without going to server (local entities) , and fill entities via domaincontext. I want to use Comaindatasource in my ViewModels.

  • Anonymous
    September 10, 2010
    I think some of the key requirements would be:

  • Support all the sorting/filtering/etc that DDS supports today as an API
  • Do not derive from Control or FrameworkElement so that a presumption that this thing will unit test correctly without being displayed can hold
  • Define the API on an interface that the object implements so that it is mockable
  • Declarable and bindable in XAML like CVS, but no presumption that it is in a UI context
  • Desirable: safe to call on background threads (not hard over on this, but would be nice, but this would probably mean you couldn't derive from DependencyObject, which would prevent using it as a binding target in the UI)
  • Anonymous
    October 15, 2010
    just wanted to clarify something that robertob said. I know you (Kyle) know this but others coming here and reading might not. In mvvm, the model IS NOT bound to the view. The ViewModel is bound to the view, and accesses the model/domain to provide data to the view.