分层架构mvc

Question

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

示例登录场景： 模型：登录表单 域Ctrl：AuthCtrl UI: ui 控制器

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

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

Answer 1

你的问题

Is this a good way to structure an app

是一个非常沉重的问题。简单的答案是是，但更正确的答案是这取决于。

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

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

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

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

Answer 2

从高层次来看，是

但这最终取决于 "how" 你在逻辑上分离了你的层。在你的场景中，我没有看到任何应用层。

• 我假设 AuthCtrl 是域？谁创建了 AuthCtrl？它存在于第几层？