MVVM中的模型:业务对象还是其他什么?

rtotam 发布于 2019-11-10 model 最后更新 2019-11-10 12:10 262 浏览

我试图去理解MVVM,所以我阅读了大量的文章 - 大多数关注于View - > ViewModel关系,并且关于什么是关于什么的总体协议。 ViewModel - > Model关系以及Model的构成关注点较少,存在分歧。我很困惑,并希望得到一些帮助。例如,this article将Model描述为业务对象,而this article描述管理业务对象的类。这些是正确的还是其他的?

已邀请:

prem

赞同来自:

我认为模型是包含最小业务实体单元的东西。模型中的实体不仅用于我的应用程序中的视图模型,还用于跨应用程序。因此,一个模型提供了许多应用程序,对于那些使用MVVM的应用程序,许多视图模型。 视图模型是模型中实体的任意集合,它们汇集在一起​​以满足视图需要的任何需求。如果视图需要其中2个和其中1个,则其视图模型从模型中提供它们。通常,每个视图我有一个视图模型。 所以模特就像杂货店。视图模型就像购物车。一种观点就像一个家庭。 每个家庭都有独特的要求。每个家庭都有自己的购物车,樱桃从杂货店挑选家庭需要的东西。

benim

赞同来自:

我认为你走在正确的轨道上。在许多情况下,“模型”含糊不清,因为它与其他人不同,这是正确的。 对我来说,从我的WCF服务回来的业务对象我认为我的模型。因此,我的项目没有那个具有神圣命名空间的漂亮文件结构: .Models, .ViewModels和 .Views。我个人认为从业务逻辑或任何性质的东西回来的对象是“模型”。 有些人倾向于将业务对象和业务逻辑混为一谈并称之为“模型”,但我发现有点令人困惑,因为我认为模型比业务逻辑更静态,但它是语义。 因此,当您查看MVVM项目的示例并且没有看到任何非常明确的“模型”时,这只是因为人们以不同的方式对待它们。除非应用程序是独立的,否则我实际上会非常怀疑具有实际 .Model命名空间的应用程序。 另一件很棒的事情就是很多时候你已经对这些类型的业务对象进行了投资,我认为很多人都会看到“MVVM”并立即假设他们需要开始定义“M”,即使它们是什么已经很完美了。 模型和ViewModel之间的混淆也很常见。基本上我知道如果我需要数据和行为的组合,我需要一个ViewModel。例如,我不希望在Model上实现INotifyPropertyChanged,但我会使用ViewModel。

zhic

赞同来自:

有很多不同的实现和解释。 然而,在我看来,ViewModel的价值来自于协调。 该模型代表了业务数据。它封装了标量信息,而不是进程。 View显然是该模型的表现形式。 ViewModel是一名协调员。在我看来,视图模型的工作是在视图和模型之间进行协调。它不应包含业务逻辑,但实际上是与业务服务的接口。 例如,如果您的视图是小部件列表,并且从服务中获取小部件,那么我会假设: 该模型是List<Widget> View是一个绑定到ViewModel属性Widgets的ListBox ViewModel公开Widgets属性。它还有一个可以调用的IWidgetService引用来获取这些Widgets。 在这种情况下,视图正在与业务对象协调,因此视图不必知道任何有关它的信息。模型应该不了解视图模型,视图和其他所有东西......它们应该独立于它们的使用方式而存在。 IWidgetService将使用一些依赖注入容器源绑定到视图模型,使用Unity构造函数注入或使用MEF导入等。 希望有意义......不要重载你的viewmodel。可以将其视为理解业务对象和模型的协调员,但不了解视图或业务流程的执行方式。

kquam

赞同来自:

模型添加的值是它与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; }
}

amodi

赞同来自:

内容太长未翻译

tqui

赞同来自:

从其他答案可以看出,ViewModel和Model之间的关系有点模糊。请注意,没有什么可以阻止您在同一个类中使用ViewModel和Model,并且当您在特定区域中的要求足够简单时,这可能就是您所需要的! 如何构建ViewModel和Model之间的分离将在很大程度上取决于需要它的项目或软件的需求,截止日期的要求以及您对拥有结构良好且可维护的代码库的关注程度。 分离ViewModel和Model只是构建代码的一种方式。构建代码有许多不同的方法,即使在这种模式中也是如此!因此,您将听到不同程序员所宣扬的不同方法,这一点不足为奇。主要的是分离可以帮助简化并使代码的独立部分可重用。当您将业务数据,业务逻辑和表示逻辑完全分离时,您可以轻松地混合,匹配和重用视图,逻辑和数据,以创建新的UI。分离和简化的代码通常也更容易理解,测试,调试和维护。 显然不是每个人都同意这个答案。我认为这是问题固有的模糊性的一部分。通常,您需要考虑并权衡优势与ViewModel和Model之间的分离成本,并且知道决定ViewModel中的内容以及模型中的内容并不总是一项简单的任务。它可能有助于制定您或您的组织将遵循的一些基本规则,然后在您了解哪种级别的分离最适合您的问题域时发展您的规则。 我认为值得一提的是,我在编写Windows Forms时曾经使用过与MVVM类似的方法,事实上WPF对此有更多的直接支持(以数据绑定和命令的形式),这真的是我的一天。