【发布时间】：2011-09-02 02:07:24
【问题描述】：
在我的应用程序中，我通常访问 DAO 层以获取/保存或更新对象到它的存储库，并且我使用 Service 层来执行更复杂的操作.
所以我的问题是：从 Controller 层访问 DAO 层是否正确（根据最佳实践和设计/架构模式），或者我应该通过Service层绕过它？谢谢！
【问题讨论】：
标签： design-patterns architecture
【发布时间】：2011-09-02 02:07:24
【问题描述】：
我想我是这里的偶像破坏者。我同意到目前为止给出的答案，即绕过服务层原则上很好，但在我看来，不是 实际上 .
主要原因是很难预测哪天会引入业务逻辑。例如，我认为“记录”是业务逻辑。如果我想引入日志或日志或限制访问，我不想在 DAO 层中这样做。但是如果我有绕过 DAO 层的代码，那么现在所有这些代码都需要重构。
DAO 层还有另一个优点，我经常发现它很有用。有些操作我可能想暴露给服务层，但不想暴露给它上面的任何层。
作为一个例子，我可以想象一个返回加密密码的 DAO 层，但一个服务层只允许您判断您传入的加密密码是否与数据库中的密码匹配。我不希望控制器层能够获取有效的加密密码 - 我看到了不必要的暴露。
因此，虽然我可能会同意，如果您绝对知道您永远不需要引入业务逻辑（如我所描述的），并且如果您有零需要隐藏一些数据访问操作而暴露其他操作.. . 然后通过各种方式将 DAO 层暴露给更高层。
我的观点是，在实践中，你不能“知道”这一点，也不应该假设。
【讨论】：
-
我想添加优化“绕过”服务层的概念是错误的。它根本不可能提高实际性能。我在 HotSpot VM 的优化器上工作了几年，我可以告诉你，一个仅充当 DAO 方法代理的服务层几乎肯定会被优化器优化（“内联”），例如生成的代码就像您“手动优化”它一样。但是手动优化（通常是一个坏主意）的缺点是将较高层耦合到他们不应该知道的较低层 (DAO)。
你应该绕过它到服务层。
这样做的原因：
- 稍后您可以将事务管理放在此服务层中。
- 如果你想将控制器层完全更改为其他框架（例如将struts更改为Spring MVC），如果你将所有调用DAO的代码放在Service中，那么重构更容易（你只需要Spring MVC调用你的现有服务）。想象一下，如果您必须将所有 DAO 调用放到您的 Spring MVC 层。
【讨论】：
-
一个问题，如果你有一个带有方法 getUserById() 的 DAO，它返回一个 User 对象，那么用 getUserById() 方法创建一个服务层有什么意义呢？它最终会调用 DAO 的 getUserById 方法()??看起来有点矫枉过正，我理解当你需要使用多个DAO时使用服务，或者当你需要预处理或后处理数据时，但如果它是一个简单的原子操作，为什么不直接使用DAO呢？
-
我已经阅读了 octy 的回答，我添加了评论是为了得到您的回答，特别是想知道您是否有任何理由在某些情况下创建模仿 DAO 的服务。跨度>
-
例如，您有 2 个从 DAO 检索数据的函数。一种是直接的方法 getUserById()。另一种是需要业务逻辑的方法，例如 getActiveUserByCountry()。如果我们想基于调用的简单性，是的——你可以让控制器直接调用DAO（控制器有DAO）。但是，getActiveUserByCountry 是一个复杂的函数，仍然需要在 A Service Layer 中实现，它也有一个 DAO。这不是标准的。为什么我们在两层都有 DAO？第二个集中在 Service 中的这个功能将使 AOP 的实现更容易。
理论上：在 MVC 架构模式的上下文中，数据访问层 (DAO) 和服务层之间没有明显的区别。 Service 层和 DAO 层都可以看作是 MVC 中的“模型”。服务层可以很好地实现业务逻辑、复杂的验证等——但它仍然是访问数据的层！只要您在模型、视图和控制器对象之间保持清晰的关注点分离，就可以从控制器对象访问 DAO 层。
在实践中：我已经看到了这两种情况。如果您有一个带有简单数据模型的小型应用程序，那么直接从控制器中使用 DAO 层会很有意义。但是，随着业务逻辑变得复杂，或者如果您的模型由多个应用程序共享，则将业务委托和 DAO 分解出来以重用组件、最大限度地减少更改时的影响、增加两者之间的灵活性会更有意义组件等。这将由相关系统的技术架构决定。
【讨论】：
-
在我做的一些项目中，我一直想知道我是否需要服务“层”！
我认为，如果不需要从 Service 层进行任何类型的处理，那么让 Controller 层直接访问 DAO 是没有问题的。但它确实应该至少有一些处理工作要做，比如在弄乱数据库之前对输入数据进行服务器验证。
【讨论】：