0

我正在使用 MVC 框架创建一个 Web 应用程序。我想在控制器和域模型之间添加一个层，我认为它在 DDD 中称为应用层，以避免将特定于特定用例的逻辑放入域模型中。控制器将仅与该层交互，该层将使用域模型编排操作。该层将保持尽可能薄，推动所有不是特定于域模型的用例的逻辑。我将调用属于这一层的类DomainCtrl。

登录场景示例： 模型：LoginForm DomainCtrl：AuthCtrl UI：ui 控制器

1.ui 控制器接收请求 2.creates AuthCtrl 的实例 3.AuthCtrl 创建 LoginForm 的实例并用传递给 authCtrl 的请求数据填充它 4.LoginForm 执行登录 5.authCtrl 执行特定于这种特定登录方式的其他事情-> 向 ui 控制器返回错误

这是组织应用程序的好方法吗？

4

2 回答 2

1

你的问题

这是构建应用程序的好方法吗

是一个非常重要的问题。简单的答案是肯定的，但更正确的答案是视情况而定。

让我们从简单的答案开始。让您的主应用程序不知道 UI 通常是个好主意。这意味着您可以轻松地从各个地方使用您的应用程序。在 DDD 中，这个外层通常称为应用层。它主要负责协调您的域、持久性和您可能依赖的其他资源之间的交互。这也使您可以将您的域放在中心，而不知道其他所有内容。如果实施得当，这将使您的域易于测试和维护。

现在答案的“取决于”部分。DDD 并不是构建应用程序的唯一成功方法，在某些情况下，它可能比其他任何事情都更具障碍。你必须问问自己我的应用程序在做什么。是否有许多特定于域的规则？我是否只获取和存储基本数据等？在选择架构和技术之前，这些都是您需要回答的问题。

我仍然会说选择 DDD 方法可能不会出错，因为它通常是做事的好方法。

*注意：您的示例对我来说不是那么清楚，但您应该小心将 UI 概念溢出到您的域/应用程序中。登录表单在某种程度上完全是一个 UI 概念，就像 auth 一样。您可能可以让您的应用程序返回您的用户的详细信息，但 UI 层应决定是否允许用户继续。

于 2015-02-14T21:24:18.657 回答
0

从高层次来看，是的

但这最终取决于您在逻辑上分离图层的“方式”。在您的场景中，我没有看到任何应用程序层。

  • 我假设 AuthCtrl 是域？谁创建了 AuthCtrl？它存在于哪一层？
于 2015-02-16T03:24:16.253 回答