MVVM 专家需要您对 MVVM 和 Dataforms 的意见

Question

据我了解，ViewModel 应该从视图中抽象模型并添加额外的逻辑来处理演示内容。

我的问题是：

我将如何创建一个假设可以同时处理用户输入的订单和详细信息的数据表单。 它应该显示用于输入订单的字段以及用于 1 个详细信息的字段。

我的模型会有一个包含 OrderDetails 列表的订单对象。

OrderEntryForm 的 ViewModel 看起来如何？

我是否有一个 OrderViewModel 和一个 OrderDetailViewModel 以及我的 我的 OrderEntryForm 将包含 OrderViewModel 的属性和 OrderDetailViewModel 的属性？ （嵌套 ViewModel？） 在这种情况下如何处理验证？由于验证应该接近模型？ 尤其是当我使用 RIA-Service 时... 放在 ViewModel 中不是更有意义吗？

您将模型从 ViewModel 抽象到多远？ 示例：

 private DateTime _OrderDate;
        public DateTime OrderDate
        {
            get { return _OrderDate; }
            set
            {
                if (_OrderDate != value)
                {
                    _OrderDate = value;
                    OnPropertyChanged("OrderDate");
                }
            }
        }

这意味着我必须将 ViewModel-Property 映射到 Model-Properties。此处无法利用模型中的 Validation-Logic...

这个例子：

 public DateTime OrderDate
        {
            get { return Model.OrderDate; }
            set
            {
                if (Model.OrderDate != value)
                {
                    Model.OrderDate = value;
                    OnPropertyChanged("OrderDate");
                }
            }
        }

需要传入一个模型。既可以访问模型的验证逻辑又可以耦合...

网络上的大多数示例显示使用 ViewModel 的数据表单只是表的表示而不是真正的抽象......

我知道并且我看到了这个

stackoverflow.com/questions/744474/combining-net-ria-services-and-mvvm-in-silverlight-3-0

我还阅读了关于此的 nikhils 博客文章，但这也仅处理来自数据库表的 Products 直接映射... =(

我知道很多问题...

你对这个话题有什么看法？ 您将如何处理复杂的数据表单？

Answer 1

克里斯，

我遇到了同样的问题，最终以一种糟糕的方式实现它:-(（每个视图一个两个 vieModel，但是将父视图传递给子视图......坏东西）。

从我的错误中，我了解到下次我会尝试：

• 生成单个 ViewModel，但在子视图中传递数据上下文中的详细实体（此详细实体不必与代理生成的实体匹配，可能是该实体的容器）。

• 生成一个单例控制器类：这个类不会暴露给视图，它对视图是透明的，只是细节视图模型会向控制器询问依赖数据而不是去 DAL。

  不确定这是否会是干净的解决方案，必须尝试并失败:)。

  我同意你的看法……这种场景没有真实的样本。

  你怎么看？

  谢谢 布劳略

  PS：关于验证，如果我们创建自己的超级实体，我们可以在那里定义我们的验证，在我的情况下，我也尝试过使用部分案例扩展实体，然后我可以拥有一个带有特殊验证的实体 myPhoneNumberDetail。

Answer 2

我个人认为没有硬性规定……嗯，有一个——务实。

务实地说，视图模型是模型，数据模型也是。两者都是类，独立于 UI，表面状态作为属性，操作作为方法，通知作为事件。我认为区分它们的地方在于它们的通用性。我认为一个模型通常可以跨多个视图使用，而不是针对特定视图优化的视图模型。

我个人绝不会为了抽象而抽象。我永远不会为每个模型属性显示顶级属性并通过委托给底层模型来实现它。这增加了工作量。它增加了要测试的代码量。它需要传播元数据、更改通知等。如果要添加一些实际逻辑，那么是的，视图模型上会有一些属性，我会酌情公开并委托给底层模型。即使在那里，我也会问是否合理/适当地将它们公开为模型上的计算属性（视图模型和数据模型都是模型）。

就直接与不显示 DAL 类型而言，在我看来这有点正交。这取决于其他因素——你想抽象多少 DAL，DAL 类型有多有用——例如，如果 DAL 类型有很多外键，则表示模型等价物或投影可能更有用完成了一些非规范化。有时安全性可能是编写演示模型/投影的原因 - 例如。我不想向客户发送电子邮件地址，而是想要电子邮件地址的替代表示。

在我的示例中，我直接使用了 DAL 类型，以简化并且不会在单个示例中包含过多的概念。我确实想以专门的方式撰写有关演示模型和投影的博客……因此不想同时将 viewmodel 和 .net ria 服务的帖子与演示模型概念混在一起。

Answer 3

通常情况下，对于模式，这真的取决于。 ViewModel 可以公开底层模型，并且没有硬性规定说您“必须”隐藏所有内容并委托。我与许多严格遵守 LOD 的人交谈过，但他们仍然同意在 UI 绑定的情况下不适用。

现在，对于该模型是否是 DTO，您会发现很多不同的意见。有些人认为唯一应该在客户端上的是纯投影，即所有逻辑都存在于服务器上的 DTO，而另一些人则认为在层之间移动实体是好的。那将是对不同帖子的讨论。 :-)

一般来说，我推荐的指导方针总是至少有一个可用于屏幕状态等的高级 VM。

就子模型而言，例如 OrderDetail，如果子模型足以绑定到，则直接公开它。现在要考虑的一件事是通知，如果您的模型没有实现 INPC，那么您可能别无选择，只能包装它以使绑定正常工作。

即使它实现了 INPC，也可能存在该模型不包含的特定于视图的关注点，但这些关注点是视图运行所必需的。在这种情况下，我将使用简单的聚合并创建一个 OrderDetailVM，它直接公开底层 OrderDetail 并添加其他属性。

例如

public class OrderDetailViewModel
{
  public OrderDetail OrderDetail {get;set;}
  public bool IsValid {get;set;}  
}

IsValid 正在检查某些特定于屏幕的逻辑。

这实际上取决于您想要实现多少封装。我不会发现使用委托模型有什么问题。取决于复杂性，虽然它可能会变得笨拙，例如想象一下 OrderDetail 是否有额外的孩子，等等。

HTH 格伦

Answer 4

为了澄清，VM 是模型的抽象，而不是视图的抽象，反之亦然。

您当然可以使用多个虚拟机来对应视图的离散部分。如果您不需要单独的 VM 用于 Order 和 Details，您可以只拥有一个包含所有内容的 OrderAndDetialsViewModel，整个 View 将直接绑定到它。这就是抽象的用武之地。

您是对的，您的模型的验证逻辑将不同于您的 ViewModel 的验证逻辑，如果您将其中的任何内容放入其中的话。在任何情况下，验证都不会出现在视图中。

我不确定我是否遵循您的第二个示例。什么是 Model 对象？您的 VM 可能知道组成它的模型，但它不会将它/它们直接暴露给视图。

我希望这会有所帮助。如果您的帖子中有任何我未能解决的部分，请告诉我。