Question

我正试图掌握MVVM，所以我读了很多文章 - 大多数都集中在View - ＆gt; ViewModel关系和关于什么是什么的普遍一致。 ViewModel - ＆gt;模型关系和模型的构成变得不那么集中，并且存在分歧。我很困惑，想要一些帮助。例如，this article将Model描述为业务对象，而this article描述管理业务对象的类。这些都是正确的还是别的？

Answer 1

我认为你走在正确的轨道上。 “模型”在很多情况下都是模糊的 ，因为它与其他人不同，这是正确的。

对于 me ，我的业务从我的WCF服务返回的对象我认为我的模型。由于这个我的项目没有那个漂亮的文件结构与神圣的三位一体命名空间： * .Models，* .ViewModels和* .Views。我个人考虑从业务逻辑中回来的对象或任何性质 the“model”。

一些人倾向于将业务对象和业务逻辑混为一谈并将其称为“模型”，但我发现有点混乱因为我想了一个模型比我的业务逻辑更静态，但它的语义。

因此，当您查看MVVM项目的示例并且没有看到任何非常清楚的“模型”时，这只是因为人们以不同的方式对待它们。除非应用程序非常独立，否则实际上我会非常怀疑具有实际* .Model命名空间的应用程序。

另一件很棒的事情是很多时候你已经对这些类型的业务对象进行了投资，我认为很多人都会看到“MVVM”并立即假设他们需要开始定义“M”，甚至虽然他们已经拥有的东西非常好。

模型和ViewModel之间的混淆也很常见。基本上我知道如果我需要数据和行为的组合，我需要一个ViewModel。例如，我不希望在模型上实现INotifyPropertyChanged，但我会使用ViewModel。

Answer 2

从其他答案可以看出，ViewModel和Model之间的关系有点模糊。请注意，没有什么能阻止您在同一个类中使用ViewModel和Model，并且当您在特定区域中的要求足够简单时，这可能就是您所需要的一切！

如何构建ViewModel和Model之间的分离将在很大程度上取决于需要它的项目或软件的需求，您的截止日期的要求以及您对拥有结构良好且可维护的代码库的关注程度。

分离ViewModel和Model只是构建代码的一种方式。构建代码有许多不同的方法，即使在这种模式中也是如此！因此，您将听到不同程序员所宣扬的不同方法，这一点不足为奇。主要的是分离可以帮助简化和重用代码的独立部分。当您将业务数据，业务逻辑和表示逻辑完全分离时，您可以轻松地混合，匹配和重用视图，逻辑和数据，以创建新的UI。分离和简化的代码通常也更容易理解，测试，调试和维护。

显然不是每个人都同意这个答案。我认为这是问题固有的模糊性的一部分。通常，您需要考虑并权衡优势与ViewModel和Model之间的分离成本，并且知道决定ViewModel中的内容以及模型中的内容并不总是一项简单的任务。它可能有助于制定您或您的组织将遵循的一些基本规则，然后在您了解哪种级别的分离最适合您的问题域时发展您的规则。

我认为值得一提的是，我曾经在编写Windows Forms时使用类似于MVVM的方法，事实上WPF对此有更直接的支持（以数据绑定和命令的形式），这真的是我的一天。

Answer 3

有很多不同的实现和解释。

然而，在我看来，ViewModel的价值来自于协调。

模型代表商业数据。它封装了标量信息，而不是进程。

查看显然是该模型的展示。

ViewModel 是协调员。在我看来，视图模型的工作是在视图和模型之间进行协调。它不应该包含业务逻辑，但实际上是与业务服务的接口。

例如，如果您的视图是小部件列表，并且从服务中获取小部件，那么我会假设：

模型是List<Widget> 查看是绑定到 ViewModel 属性小部件的ListBox ViewModel 会公开 Widgets 属性。它还有一个 IWidgetService 引用，可以调用它来获取这些小部件。

在这种情况下，视图正在与业务对象协调，因此视图不必知道任何有关它的信息。模型应该不了解视图模型，视图和其他所有东西......它们应该独立于它们的使用方式而存在。 IWidgetService 将使用一些依赖注入容器源绑定到视图模型，使用Unity构造函数注入或使用MEF导入等。

希望有意义......不要重载你的viewmodel。可以将其视为理解业务对象和模型的协调员，但不了解视图或业务流程的执行情况。

Answer 4

模型添加的值是它与ViewModel和View的分离。想想你是否必须在ViewModel中构建和维护业务逻辑，你会有很多重复的代码。

例如 - 如果你有一个带有GearBoxView（CockpitView中的一个控件），CarViewModel和CarModel的汽车游戏 - 从CarViewModel中抽象CarModel中的内容的优点是CarModel可以在WorldViewModel和任何其他ViewModel。 CarModel可以与其他模型（GearsModel，WheelModel等）建立关系。

您的问题专门询问了如何将模型用作业务对象或管理业务对象：我的答案是它可以同时执行这两项操作 - 并且应该对两者都负责。

下面是一个例子

public class WorldModel //Is a business object (aka game object)
{
    private List<CarModel> _cars;
    public List<CarModel> Cars
    {
        get //Here's some management of other business objects
        {
            //hits NetworkIO in a multiplayer game
            if(_cars == null)
            {
              _cars = myExternalDataSource.GetCarsInMyGame();
            }
            return _cars;
        }
    }
    public Level CurrentRaceCourse { get; set; }
    public CourseTime TimeElapsed { get; set; }
}

Answer 5

我认为模型是包含最小业务实体单元的东西。模型中的实体不仅用于我的应用程序中的视图模型，还用于跨应用程序。因此，一个模型提供了许多应用程序，对于那些使用MVVM的应用程序，提供了许多视图模型。

视图模型是模型中实体的任意集合，它们汇集在一起以满足视图需要。如果视图需要其中2个和其中1个，那么它的视图模型从模型中提供它们。通常，每个视图我有1个视图模型。

所以模特就像杂货店。视图模型就像购物车。一种观点就像一个家庭。

每个家庭都有独特的要求。每个家庭都有自己的购物车，可以从杂货店中挑选出家庭需要的东西。

MVVM中的模型：业务对象还是别的什么？

6 个答案: