Question

ViewModel创建应该在哪里进行？在服务层中，在控制器中？

public class ObjectA {
 public string Name {get;set;}
 public IList<ChildB> Children {get;set;}
}

public class ObjectAViewModel {
 public ObjectA ObjectA {get;set;}
 public IList<ChildB> SelectableChildren {get;set;}
}

如果必须在运行时计算ObjectA上的某些属性，该怎么办？

public class ObjectA {
 public string Name {get;set;}
 public IList<ChildB> Children {get;set;}
 public CalculateMethod {get;set;}
 public decimal CalculatedValue {get;set;}
}

假设ObjectA.CalculatedValue是根据存储库中的所有或部分ChildB对象（不仅是相关对象）计算出来的，并且它们的计算方式也不同{{1}有价值？我应该延长CalculateMethod，在这种情况下，我应该把它放在哪里？和ObjectA一起，还是作为其他地方的DTO？应该在哪里进行计算？

Answer 1

这似乎是一个非常重要的问题。有一个思考的起点here，并从那里引用其他讨论。

我来自Java背景，因此没有直接的经验，但从概念上讲，我的想法是：

模型对视图一无所知，只是提供数据，还可以提供视图可能有用的验证规则。例如：这里是某个日期，这个字段是“部门”字段。以下是所有有效部门的列表，作为一个模型，我对View先生一无所知，但您猜测可能会填充该部门列表中的下拉列表。

问题在于模型最终会发送视图不关心的大量数据，请继续阅读......

控制器对视图和模型的实际内容一无所知，但他们确实知道某些视图对某些模型感兴趣。因此，他们有责任选择一个审批视图并安排它来获取所需的数据。财务总监就像一个约会机构，进行介绍，然后走开。

因此，在最一般的场景中，View本身会被赋予一个模型并帮助自己获得所需的数据。因此，View了解模型，但反之亦然。现在作为一个implmentation细节，我们可以从ViewModel类中删除该关系，以保存视图的有趣数据，我们也可以将逻辑拉出到ViewModelFactory类。控制器实际上可能有责任根据我们要查看的View选择合适的ViewModelFactory，因此在某种意义上Controller正在“制作”ViewModel，但逻辑是（概念）View的责任。

Answer 2

对于你的第一个问题，我会在控制器中说，因为它知道它将服务哪个视图，所以这个视图需要知道。

MVC，在哪里生成ViewModel类？

2 个答案: