0

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

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

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

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

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

问候

4

1 回答 1

1

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

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

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

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

现在，你不想做的事情：

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

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

我可以在不影响我的业务/域的工作方式的情况下更改/替换它吗？

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

于 2013-08-13T20:17:37.673 回答