mvvm疑惑

[fly___fly]

最近在学习mvvm，对于 view-viewmodel 感觉容易理解，但对 viewmodel-model，总是感觉别扭

比如我在做的一个练习，做一个小的单位转换器，将配置放在xml中

<UnitConversions>
  <uc name=“长度”>
    <unit name="米(m)" times="1000"/>
    <unit name="分米(dm)" times="100" />
   </uc>
  <uc name="面积">
  </uc>
<UnitConversions>

model应该有三个

class Unit
{
   [XmlAttribute("name")]
   public string Name{get;set;}
   [XmlAttribute("times")]
   public double Times{get;set;}
}

class UnitConversion
{
  [XmlElement("unit")
   public List<Unit> Units{get;set;}
}

[XmlRoot(UnitConversions>
class UnitConversionListModel
{
   [XmlElement("uc")
   public List<UnitConversion> UnitConversions{get;set;}
}

界面设计为一个tab窗体，每个tabitem是一个page，对应一个 UnitConversion
ModelView应该怎么做呢？

class UCModelView
{
    public UnitConversion {get; set;}  // 这个应该没有问题
}

class UnitConversionsModelView
{
    public UnitConversionListModel Model {get;set;}    // 这里怎么办呢？  

    public List<UCModelView>  UcModels{get;set;}  // 对子项的modelview怎么创建、分配？Model.UnitConversions 和UcModels之间有无关系？怎么创建关联

}

这里只有两层，如果有三层、四层，都有对应窗口，都应该写modelview，应该怎么处理呢？

[以专业开发人员为伍]

把你这些全都忘掉，先从 view 出发进行设计。纠结底层数据无用。 贴出你的 view 设计。如果连 view 都不是很清楚描述，就不要说 mvvm。

[以专业开发人员为伍]

在 mvvm 中，第一个 m 基本上可以忽略。model 是跨层（例如跨通讯进程前后台，或者跨页面/窗口）通讯时使用的失血的简单数据结构。换句话说，你可以在 ViewModel 中指定某几个很简单的 Field 或者 Property 组成 model。基本上可以忽略。

[以专业开发人员为伍]

基本的持久化/进程间通讯数据结构其实谁都会，真正的技术就在于从前端千变万化的需求出发、从view出发。 如果你发现满脑子只有 Model，那就可以忽略了这些东西了。

[正怒月神]

怎么说呢，viewmodel是为了把model数据组装好，填充给view的。 viewmodel可以是来自一个或者多个model的数据组合。 viewmodel是一个充血模型，可以包含状态和行为。 而model只是一个贫血模型，基本只有属性。

[fly___fly]

我设计类似百度的单位转换，主窗口有一个TabControl，每个TabItem对应一个转换页面，像这样。

所以我设计两个View，一个是主窗口,一个是 Panel窗口，放在TabControl中。

[以专业开发人员为伍]

考虑 model 时，你就关心跨进程、跨界面窗体的（失血的）对象数据结构就够了。因此 model 基本上不占什么精力。 不要把过多精力放到在 model 上。相反地，所有精力都从（整理和需求图片中每一个字段的定义开始。model 应该是手到擒来的简单的（纯粹存一下基本字段的） class 定义。

[以专业开发人员为伍]

引用 4 楼 fly___fly 的回复:

我设计类似百度的单位转换，主窗口有一个TabControl，每个TabItem对应一个转换页面，像这样。 所以我设计两个View，一个是主窗口,一个是 Panel窗口，放在TabControl中。

ViewModel 就是对应每一个输入，以及功能方法。例如对应“长度输入数值”有一个字符串，对应旁边的两个下拉选择有2个字符串数组，对应于第三个下拉选择的选中事件有一个“计算长度”的方法用来绑定。 ViewModel 就是让你的模板设计傻瓜化，从而无需编码。所以 ViewModel 就是从交互界面出发，把界面上需要绑定的属性、方法罗列出来。很简单。

[以专业开发人员为伍]

你可以看到，设计 ViewModel 的一切“想象力”来自于从交互式前端需求设计。比如说假设界面上在各个选项卡上要“自动排序”，按照用户使用的次序将最近用过的选项卡动态地排到第一位。根据这个需求，你就知道你的 ViewModel 中就要为每一个选项卡设计一个 Dictionary<string, DateTime> 数据结构，来记录每一个选项卡的最后一次计算时间。然后将界面上选项卡的 Item 顺序跟这个数据结构（或者它的可计算属性结果）绑定声明。 丰富的设计，来自于前端（用户视角的）需求的千差万别。而不是来自于底层的什么数据。

[sp1234_maJia]

所有的丰富的和前边万化需求，通常来说，最重总会持久化。 但是有人容易养成懒惰的习惯，总想着靠底层数据来千篇一律地“自动产生界面”就能写万能程序了。这是不现实的，但是在许多人身上总也改变不了这种恶习。 真正现实的做法是根据千变万化的需求，以极其经济快速的方式去开发出跟最终用户交互界面需求 100% 相符的程序。而不是满脑子只纠结底层数据。

[以专业开发人员为伍]

设计一个前端应用软件，并不纠结 model。当你100次地遇到有关 model 的问题的时候，（除非你并不熟悉数据结构基础知识，否则）起码有95次你都不是从为了 model 而讨论 model，你都是重新从需求文档看起、重新查看模板布局配置代码。 所以遇到这类不要看 model。遇到这类问题要看界面。

[fly___fly]

多谢各位解答