我们可以直接在控制器中使用 DAO 而不是业务层对象吗？

Posted 2023-02-24

【中文标题】我们可以直接在控制器中使用 DAO 而不是业务层对象吗？

【英文标题】：Can we use DAOs directly in controller instead of business layer objects?

【发布时间】：2013-02-11 18:07:38

【问题描述】：

我不只是得到一件事..我正在做一些内部项目..（java/spring/hibernate）。我正在使用 dao 层，presentaion 层.. 在我的应用程序中使用业务层是否有必要？

我之所以问是因为，无论 dao 中有哪些方法，业务层中也存在相同的方法。所以我可以直接在我的控制器中使用 DAO，而不是业务层对象。

如果我错了，请纠正我。我在大型应用程序上编写代码的经验并不多。所以请给我建议（如果可能的话，请提供任何示例）

你说的是什么服务层？你认为我需要这个用于像我这样的小型应用程序吗？ （我想我们只有在使用 web 服务时才使用服务层，对吧？）

等待您的回复

【问题讨论】：

Do I really need a service layer?的可能重复

@JBNizet 但我也在询问业务层.. 你能告诉你是否知道..？

业务层和服务层是一回事。同义词。

@JBNizet 我不认为他们是一样的。我听说服务层将建立在业务层之上

请对我的查询进行更多回复..

【参考方案1】：

除了最简单的一次性应用程序之外，您应该在所有应用程序中都有一个业务层。我想说的是，将表示与业务逻辑分离比将业务逻辑与数据访问分离更重要（尽管您应该两者兼而有之）。

当应用程序只做 CRUD 时，似乎不需要业务层。然而，当：

您需要更改应用程序的 UI 框架...而 UI 技术发展迅速 您需要将业务逻辑作为库公开给不同的客户端代码，或通过 Web 服务删除客户端 您的应用程序增长...并获得更严格的业务规则 您想开始对业务逻辑进行单元测试

如果您将业务逻辑放入表示层/控制器中，那么您的业务逻辑将永远与您的表示层绑定。你基本上是在你正在编写的代码上设置了一个人为的生命周期，同时限制了它的可重用性。当您需要更改 UI 技术时，您需要重新编写业务逻辑。

由于这个原因，有很多 VB6 应用程序不得不被放弃和重写：它们应该在 C++ COM 对象中编写业务逻辑......它们可以从 .NET 中调用。这些相同的 VB6 程序员继续使用 VB.NET Winforms，并再次犯了同样的错误。

编辑：至于服务：在需要时编写服务层。服务层通常是位于业务层前面的薄层。它实际上是您的业务逻辑的客户端。通常它会有相同的接口。除非您需要通过网络公开您的逻辑，否则您不需要一个。我曾在坚持在其业务逻辑之前编写 WCF 层的团队工作过……然后无论如何都在同一台机器上运行所有代码。浪费时间并减慢应用速度。