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

Question

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

• DataLayer：这里我从DbContext派生的上下文类和从EntityTypeConfiguration派生的映射器类（如 JobMap ，用于域对象）
• DomainLayer：此处我的域/业务对象（如作业或计划）驻留。
• 表示层：这里我有* ViewModel和* View类（我使用WPF作为视图）

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

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

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

此致

Answer 1

首先，您需要确定应用程序的哪些部分位于哪里，并且这很容易做到。从本质上讲，您必须问自己：此方法或类是否有助于定义我的域。如果答案是肯定的，则将其放在域图层中，如果不是，则将其放在演示文稿中。

以下是您在示例中的看法：

• 您的表示层（PL）通过开始接收消息 按钮。
• PL调用域并告诉它生成一个计划。此调用可能是域服务。
• 您的域服务负责填充Job域对象，创建新的Schedule域对象（或修改现有域对象），并返回Schedule域对象。
• 您的PL只会显示返回的时间表。

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

现在，你不想做什么：

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

很难准确详细说明您应该放置哪些内容，因为只有您可以清楚地了解您的域名的定义，但这主要是我如何分解它：

我可以在不影响我的商家/网域工作方式的情况下更改/替换此内容吗？

如果答案是肯定的，则它不属于您的域名。示例：您可以将整个MVVM前端替换为平面PHP或ASPX，即使它需要大量工作和巨大的痛苦，您也可以在不影响其余业务运营的情况下执行此操作。