在视图模型中使用业务对象

使用可重用的业务对象时，在构建视图模型时什么是最佳实践？

我们使用调用的对象Builder来构建视图模型。每个视图逻辑单元（订单，用户等）的一个构建器，其中每个单元可以包含许多不同的视图模型（订单包含摘要，订单行等）。

建造者可以通过一个或多个标准业务对象提取数据，以建立视图模型。

在视图模型中使用业务对象/模型时，什么被认为是更好的做法？

方法1

允许在视图模型中使用业务对象？

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary();
        obModel.Order = obOrder;

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public Some.Business.Logic.Order Order;
    //Other methods for additional logic based on the order
    //and other properties
}

方法2

仅从业务对象中获取必要的数据

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary()
        {
            OrderNum = obOrder.OrderNum,
            NumOrderLnes = obOrder.NumOrderLines,
        }

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public int OrderNum;
    public int NumOrderLines
    //Other methods for additional logic based on the order
    //and other properties
}

我可以看到两者的优点和缺点，但是我想知道是否存在一种公认的方法？在方法1中，模型之间没有代码重复，但是会创建对业务逻辑的依赖。在方法2中，您仅获取视图所需的数据，但是在模型周围重复了代码。

选项1在域模型和视图之间创建紧密耦合。这与视图模型设计要解决的非常矛盾。

如果视图本身发生更改，则视图将建模为“更改原因”。通过将域模型对象放在视图模型中，您将介绍另一个更改原因（例如，域已更改）。这清楚地表明违反了单一责任原则。有两个或两个以上的更改原因导致视图模型需要大量维护-可能比跨域/视图模型重复进行的可感知维护成本要高。

我将始终主张方法2。通常情况下，视图模型看起来非常相似，甚至与领域模型对象相同，但是正如我提到的，区别在于它们改变的原因不同。

选项1是可取的，因为它可以避免代码重复。而已。

如果域模型发生重大变化，则几乎可以肯定，视图还是必须进行更改。使用选项2，则必须更改视图模型，构建器以及视图本身。这种事情绝对是可维护性的毒药。亚尼

具有单独的视图模型的目的是将仅对视图有意义的状态（例如，当前选择的选项卡）与业务模型保持独立。但是业务数据本身应该被重用而不是重复。

原则和口头禅有时对指导设计很有价值……但这是我的实际答案：

假设您的视图模型被序列化为JSON或XML。如果您尝试对域模型进行序列化，最终将导致混乱的文本，并且很可能会遇到循环引用等问题。

视图模型的目的不是将域模型分组在一起，以便视图可以使用它们。取而代之的是，视图模型应该是视图的完全平面模型……您正在屏幕上查看的实际内容。您的视图逻辑仅应与结构化视图模型中存在的数据有关。

理想情况下，您的视图模型应该几乎完全由预先格式化的字符串组成。考虑一下...您甚至不需要在视图模型中使用DateTime或小数，因为那样您就无法使用C＃，Javascript，Objective-C等格式逻辑。