使用 Entity Framework 和 MVVM 时将我的应用程序逻辑放在哪里答案

【问题标题】：Where to put my application logic when using Entity Framework and MVVM使用 Entity Framework 和 MVVM 时将我的应用程序逻辑放在哪里
【发布时间】：2013-08-13 18:19:41
【问题描述】：

在过去的几天里，我花了很多时间为我的程序创建架构，但仍然存在问题。目前它看起来像这样：

DataLayer：这里我的上下文类派生自 DbContext 和映射器类派生自 EntityTypeConfiguration 像 JobMap 为领域对象驻留
DomainLayer：我的域/业务对象（例如 Job 或 Schedule）驻留在此处。
表示层：这里我有 *ViewModel 和 *View 类（我使用 WPF 作为视图）

现在我的问题是：我想构建一个具有一些优化能力的调度应用程序（它是一个单用户和单台 PC 应用程序，因此不需要像 Web 应用程序那样进一步解耦）。但是我有一个问题，我不知道这个应用程序适合这个架构吗？

考虑以下用例：用户单击视图上的“开始”按钮，该按钮调用 ViewModel 重定向到我的调度/优化应用程序。然后，此应用程序从数据库中获取所有新作业并创建/更新当前计划。然后 ViewModel 应该使用新创建的计划更新旧计划。最后，视图向用户显示生成的时间表。在这种情况下，我的 ViewModel 知道我的应用程序（因为它调用它）和我的域/业务对象（因为我的应用程序将交付例如 ViewModel 封装的 Schedule 域对象）。

这是对 EF、MVVM 和我的应用程序的正确用法吗？

问候

【问题讨论】：

标签： entity-framework mvvm architecture

【解决方案1】：

首先，您需要确定应用程序的哪些部分在哪里，这很容易做到。本质上，您必须问自己：此方法或类是否有助于定义我的域。如果答案是肯定的，你把它放在领域层，如果不是，你把它放在表现层中。

这是您在示例中的看法：

您的表示层 (PL) 通过启动接收消息按钮。
PL 调用域并告诉它生成一个计划。此调用可能是对域服务的调用。
然后您的域服务负责填充 Job 域对象、创建新的 Schedule 域对象（或修改现有的）并返回 Schedule 域对象。
然后您的 PL 会简单地显示返回的计划。

如果您只想获取现有的 Schedule 对象，这可能会有所不同。您可以要求域存储库获取现有计划，而不是调用域服务。存储库将是封装或以其他方式从您的 PL 和您的域中隐藏数据层的方式。

现在，你不想做什么：

不要在 PL 中获取作业列表，然后使用该作业列表在 MVVM 的控制器中创建计划。这将是定义您的域的业务逻辑。
如果调度通常是从作业生成的，无论它是从 MVVM 还是 PHP 站点调用的，那么不要通过强制 PL 首先获取作业并将它们传递回要生成计划的域。这两个概念相互关联的事实意味着这种关系有助于定义您的领域，因此属于您的领域层。当要修改的作业和计划都依赖于来自前端的上下文（用户输入）时，可能会出现例外情况，但即使这并不总是例外。
不要将虚拟机传入您的域。让您的控制器过滤掉数据并确定需要发送到哪个域部分。

很难准确地详细说明您应该在哪里放置什么，因为只有您才能清楚地了解定义您的域的内容，但我基本上是这样分解的：

我能否在不影响我的业务/域运作方式的情况下更改/替换它？

如果答案是肯定的，则它不属于您的域。示例：您可以将整个 MVVM 前端替换为扁平的 PHP 或 ASPX，尽管这会带来大量工作和巨大的痛苦，但您可以在不影响其他业务运作方式的情况下这样做。

【讨论】：