我不只是得到一件事..我正在做一些内部项目..（java/spring/hibernate）。我正在使用 dao 层，presentaion 层.. 在我的应用程序中使用业务层有必要吗？
我之所以问是因为，无论 dao 中有哪些方法，业务层中也存在相同的方法。所以我可以直接在我的控制器中使用 DAO，而不是业务层对象。
如果我错了，请纠正我..我在大型应用程序上编写代码方面没有太多经验..所以请给我建议（如果可能的话，请提供任何示例）
你说什么服务层？你认为我需要这个用于像我这样的小型应用程序吗？（我猜我们只有在使用 web 服务时才使用服务层，对吧？）
等待您的回复
除了最简单的一次性应用程序之外，您应该在所有应用程序中都有一个业务层。我想说的是，表示与业务逻辑的分离比业务逻辑与数据访问的分离更重要（尽管你真的应该两者兼而有之）。
通常，当应用程序只做 CRUD 时，似乎不需要业务层。但是，在以下情况下，这会失败：
如果您将业务逻辑放入表示层/控制器中，那么您的业务逻辑将永远与您的表示层绑定。你基本上是在你正在编写的代码上设置了一个人为的生命周期，同时限制了它的可重用性。当您需要更改 UI 技术时，您将需要重新编写业务逻辑。
由于这个原因，有很多 VB6 应用程序不得不被放弃和重写：它们应该在 C++ COM 对象中编写它们的业务逻辑……它们可以从 .NET 中调用。这些相同的 VB6 程序员继续使用 VB.NET Winforms 并再次犯了同样的错误。
编辑：至于服务：在需要时编写服务层。服务层通常是位于业务层前面的薄层。它实际上是您的业务逻辑的客户端。通常它会有相同的接口。除非您需要通过网络公开您的逻辑，否则您不需要一个。我曾在坚持在他们的业务逻辑之前编写 WCF 层的团队工作过……然后无论如何都要在同一台机器上运行所有代码。浪费时间并减慢应用程序。