在MV*模式中，非商业模式走向何方？

Question

我正在从ViewModel传递要查看的菜单项。我的菜单定义是一个具有属性标题、图像、hasChildren和isEnabled的模型。但是这个模型是针对UI的，不像Person、ContactDetail、Transaction等业务领域模型。

所以，当我看到这个菜单模型和业务域模型坐在一起的时候，我觉得自己被污染了。有合适的地方放置这种UI特定的模型吗？

谢谢。

Answer 1

我正在从ViewModel传递要查看的菜单项。

我认为你真的很接近，但在MVVM上有点漏掉了。我不知道你是在哪种语言/框架中应用这一点，所以我会笼统地回答。我知道当您听到MVVM时，.NET是典型的，但是这种模式可以在任何地方应用。

让我首先更正一下你最初的陈述：

我正在将菜单ViewModels传递给视图。

您认为这个特定于视图的菜单项模型与您的业务域模型是完全不同的。确保您称它们为ViewModels，而不是模型。

至于你把它们放在哪里，你有几个选择。您可以将它们放在与模型相同的文件夹中，但可以将它们明确命名为ViewModels。您还可以给他们自己的目录，这样您的模型和ViewModels就不会混合在一起了。这都是代码组织的问题，这两个选项都是有效的。也许后者(单独的文件夹)稍微干净一些。

注意，我没有说ViewModels是从哪里传递的。考虑模型、ViewModels和视图是如何相互传递的更好的方法是描述每个视图的消费位置。这也取决于您的框架如何传递(或声明)事物，但以下是基本的想法。

视图可以引用包含需要绑定的数据的ViewModel。视图没有业务模型的概念，或者至少它不直接与商业模型一起工作。

ViewModel可以引用一个模型。它可能直接从它获得数据，甚至调用模型的方法来派生数据。它也可能有自己的一些逻辑，即视图特定的逻辑，而不是特定于域的逻辑。它通常是原始模型的一个子集，增加了特定于视图的关注点，比如格式化日期和数字。ViewModel不需要了解视图，它甚至可以被多个视图所消耗。

该模型没有ViewModels或视图的概念。它是您的纯业务模型/域对象。它可以处理基于业务逻辑的数据计算或派生。它不应该关心像格式化这样的演示文稿问题。

为了进一步阅读，我建议使用这篇文章中的“模型的演变-视图-视图模型”一节，特别是该部分的最后两段。

Answer 2

MVC模型是最高层的模型。UI本身可以被看作是另一个SW，下面是一个抽象级别。但是它本身可以有自己的实体(由用户设置的持久UI配置)和您提到的模型。

当然，我们现在面临的是一个矛盾。根据该模型，只有控制器层的组件才能相互对话。但是这些控制功能没有什么共同点！但是，只有当我们从字面上理解MVC概念时，这才是一个矛盾。纯三个“层”只能服务于最原始的体系结构，其中只有两个极点--数据和用户，我们沿着它们之间的纽带定义层。一个真正的应用程序有许多这样的极点。在一根柱子和另一根杆子之间的任何连接都可以而且应该被切成几层。

这些极点的定义取决于您，我不知道您的工作有多复杂，但是由于您显然想要动态接口，就会有最小的树极点--业务数据、接口数据和用户。有两个联系--用户-BuD和用户-InD。你会有两个不同的控制器，每个控制器。您还可以有两个接口--普通接口和接口设置的推断。后两者将有共同的因素。有趣的是，在这个抽象级别上，控制器不会相互协作，接口也不会合作。

顺便说一句，即使这个体系结构也非常简化，因为您还需要管理数据吗？也许是许可数据？你也需要为他们服务。

Answer 3

您正在处理模型/视图/控制器中的视图。

模型是您的应用程序的工作。视图显示可视元素(在本例中是菜单)，Controller处理动态用户交互(击键可以做什么，哪些指针选择要求视图是活动的等等)。视图和控制器几乎总是非常紧密地联系在一起。当然，在HTML世界中，我们很少考虑UI的控制器方面，但是在编写本机应用程序时，它比现在要多得多。

M、V和C中的大多数类都有实例变量。没有必要为你的菜单(即视图)有状态而感到尴尬，认为它是视图的一部分仍然是完全有效的。

我还认为，您可以在视图中子类(或不)许多不同的菜单设计，但不需要将属性视为模型。它们是呈现视图所需的状态，细节属于视图。