4

Or should I only create viewmodels for the domain data being represented? While reading on MVVM, I came across this:

"The ViewModel is responsible for these tasks. The term means "Model of a View", and can be thought of as abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model. "

http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx

If the viewmodel is a model of the view, then doesn't it make sense to put properties of the view in the viewmodel rather than on the code behind of the view itself?

I guess in making a custom control I just have a hard time deciding when I should just add a property to the control's code behind and when it is worthwhile to make a viewmodel for the control to represent it. Honestly I kind of feel that moving all of the control's view related properties to the viewmodel would clean up the code behind of the control leaving only the control logic.

However, if I were to change things like this, then at times when an item needs properties from the control itself I can no longer use {Binding ElementName = control, Path=property} and have to instead get the data context of the parent (because the current datacontext would be on the individual subitem of the observable collection.

Basically I was considering whether I should move properties from Class GraphViewer into a GraphViewerViewModel and then just bind to it.

Code is worth a million words so: public class GraphViewerViewModel :DependencyObject { private const int DEFAULT_PEN_WIDTH = 2; private const int DEFAULT_GRAPH_HEIGHT = 25;

    public SignalDataViewModel _SignalDataViewModel
    {
      get;
      set;
    }
    public PreferencesViewModel _PreferencesViewModel
    {
      get;
      set;
    }
}

Meanwhile 

public class SignalDataViewModel : INotifyPropertyChanged
  {
    public event PropertyChangedEventHandler PropertyChanged;

    ObservableCollection<SignalViewModel> _signals;
    public ObservableCollection<SignalViewModel> Signals
    {
      get
      {
        return _signals;
      }
      private set
      {
        _signals = value;
      }
    }

    ObservableCollection<SignalViewModel> _AddedSignals;
    public ObservableCollection<SignalViewModel> AddedSignals
    {
      get
      {
        return _AddedSignals;
      }
      private set
      {
        _AddedSignals = value;
      }
    }

it is a pain to type:

PenWidth="{Binding RelativeSource = {RelativeSource AncestorType={x:Type DaedalusGraphViewer:GraphViewer}}, 
                                  Path = _GraphViewerViewModel._SignalDataViewModel._AxisDivisionUnit.GraphPenWidth, Mode=OneWay}"

and I'm wondering if it is worthwhile to make the change or whether I'm misunderstanding what a view model should be used for in mvvm.

4

1 回答 1

7

我想在制作自定义控件时，我很难决定何时应该将属性添加到控件的代码后面，以及何时值得为控件创建一个视图模型来表示它。老实说，我觉得将所有控件的视图相关属性移动到视图模型会清理控件背后的代码，只留下控件逻辑。

一般来说，自定义控件是 100% 视图层代码。因此，它确实完全不在 MVVM 范围内。

在使用 MVVM 设计的应用程序中使用自定义控件时，主要目标是确保您以与数据绑定完全兼容的方式设计和构建自定义控件。这将允许它像其他控件一样在应用程序的视图层中使用。

因此，这几乎可以保证您将拥有代码，因为实现依赖属性确实需要代码。您也不想在控件内设置自定义控件的 DataContext（因为您想使用该控件继承用户控件或窗口的数据上下文）。

基本上我在考虑是否应该将属性从类 GraphViewer 移动到 GraphViewerViewModel 中，然后绑定到它。

如果类型特定于您的域，那么这实际上通常更像是您的应用程序使用的 UserControl。在这种情况下，创建一个 ViewModel 并仅绑定可能是好的。

另一方面，如果这是一个完全通用的真正自定义控件（即：任何应用程序中的任何人都可以使用），那么将其保持为“纯视图”自定义控件通常意味着您 1）赢了t 依赖于任何 ViewModel 或特定领域的对象，并且 2) 不设置数据上下文（这意味着没有视图模型）。

于 2013-09-23T19:51:05.067 回答