【问题标题】:WPF MVVM Model how to get dataWPF MVVM模型如何获取数据
【发布时间】:2017-09-13 05:53:26
【问题描述】:

最近在学习 MVVM 设计模式!

我的方式是在model中编写数据库函数,让viewmodel调用model中的数据库函数,然后viewmodel获取数据库数据并设置为viewmodel notfiypropertychanged。这是我目前使用的方式!

有一些关于模型的问题让我感到困惑, 我读了很多文章告诉我模型只是一个包含数据而不是更多的业务逻辑,这是我的问题,如果模型只是一个数据容器,我需要让我的视图模型调用数据库然后获取数据并设置为模型,我认为这种方式很奇怪,并且视图模型代码很重。有人有其他方法吗?谢谢!

【问题讨论】:

  • 你在使用.NET Core吗?
  • 我现在没有太多时间,但看看Microsoft Document 是否有帮助。
  • 我不知道你从哪里得到“模型只是一个包含数据而不是更多的业务逻辑”,但对我来说,业务逻辑是模型的一部分。但是,我观察到业务逻辑泄漏到我的项目的视图模型中的趋势,我不能说这是否是一件坏事。
  • @aaronR 的 Prism 链接不是最轻的材料。 picture here 可能会有所帮助,但也很有野心。
  • 有些人将他们应用程序的业务逻辑类称为模型!其他人将用于与业务逻辑(例如参数和返回值类型)通信的数据类称为模型!我属于后者!我也更喜欢用感叹号结束我的所有句子!

标签: c# wpf mvvm


【解决方案1】:

模特:

“模型只是一个包含数据而不是更多的业务逻辑”

模型是描述域逻辑中的实体的类。什么是域?星巴克的领域是咖啡饮料和员工(以及其他),福特的领域是汽车、装配线和员工。 NYTimes 的领域是文章、问题、供应路线、订阅者等。

模型包含数据与逻辑。您可以有多个模型来描述您的域。

您可以将数据调用放在模型中,但更常见的做法是使用辅助类、数据访问层 (DAL),将所有数据库调用保存在一个位置,而不是分散开来。

ViewModel:

视图模型位于您的域模型和视图之间。它是一个暴露模型属性并表示视图状态的类。 viewmodel 可能只公开 UI 需要显示的模型中所有属性的子集,但它也可以添加自己的属性,例如;用户是否处于编辑模式?是否进行了需要保存的更改?等等。MVVM 的卖点是 UI 绑定到视图模型上的这些属性,这是一种使 UI 随更改保持最新的机制,并且这个额外的抽象层可以方便地将视图与模型中的任何逻辑解耦对于任一方向的代码更改和可测试性更健壮。关于这个话题还有很多话要说,但我会留给你继续阅读。

关于 MVVM 模式有很多很好的资源和信息;从博客Model-View-ViewModel (MVVM) Explained,到微软The MVVM Pattern 和这里。

如果您喜欢视频,Pluralsight 有关于 MVVM 模式的优秀视频教程 Practical MVVMWPF MVVM In Depths。他们有 30 天的免费试用期。

“只是一个数据容器”

此类只保存要传递的数据的类通常称为数据传输对象 (DTO)。保持它们很小并从 fetch 数据库数据方法调用中返回它们的集合是很常见的。

【讨论】:

    【解决方案2】:

    我对此进行了一些研究,也发现它很混乱。我想指出的第一件事是代码模式是抽象的。这意味着您有很多不同的方式来实现/调整它。

    大多数人告诉我的是,在“现实生活”应用程序中,您通常有多层服务。

    其中一项服务是您从数据库中获取数据。

    模型工作(在我看来)是向开发人员提供有关数据库数据和结构的知识。一个模型到一个数据库表。 它还有助于在将数据发送到数据库之前检查数据是否正确(格式检查、数据类型等)。

    关于如何使用模型没有明确的答案。我见过很多不同的实现,它们都是针对特定任务实现的。

    是的,可能会出现某些 ViewModel 变得繁重的代码和要执行的功能,但这可能不是因为代码模式。这可能是因为代码结构不佳。在我现在的工作中,我发现了一个包含超过 3000 行代码的 ViewModel(这是非常多的)。这可以很容易地分成至少 3 个不同的 ViewModel 和 View,但正如我所说,糟糕的代码结构会导致问题。

    我建议您阅读的一件事是

    • IoC - 控制反转
    • DoP - 依赖倒置原则
    • DI - 依赖注入

    希望这有助于以某种方式解释您的问题。

    【讨论】:

      【解决方案3】:

      我读过很多文章告诉我模型只是一个包含数据而不是更多的业务逻辑

      模型可以由服务、数据库访问层或业务层表示,因此您当前的方法没有任何问题。业务逻辑确实属于模型。

      但有时人们倾向于将“儿童”类型称为模型。例如,如果您的视图模型公开了List<Item> 属性,则Item 类可能被视为模型。也许你的困惑来自于此。

      这种类 (Item) 通常实现 INotifyPropertyChanged 接口以提供更改通知,并且实际上只是不包含任何业务逻辑的“嵌套”视图模型。

      希望这是有道理的。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多