我不只是得到一件事......我正在研究一些内部项目..（java / spring / hibernate）。我使用dao层，presentaion层..是否有必要在我的应用程序中使用Business层？
我问的原因是，无论dao中的方法是什么，业务层中也存在相同的方法..所以我可以直接将DAO用于我的控制器而不是业务层对象..
如果我错了，请纠正我..我在编写大型应用程序代码时没有多少经验..所以请告诉我（如果可能的话，请提示）
你说的服务层是什么？你觉得我需要这个像我这样的小应用吗？ （我想我们只在使用webservices时使用服务层，对吗？）
等待你的回复
答案 0 :(得分：0)
除了最简单的丢弃应用程序之外，您应该拥有一个业务层。我甚至可以说，将业务逻辑与业务逻辑分离比将业务逻辑与数据访问分离更重要（尽管你应该同时拥有这两者）。
当应用程序只做CRUD时，通常看起来不需要业务层。然而，这在以下情况下会失败：
如果将业务逻辑放入表示层/控制器，那么您的业务逻辑将永远与您的表示层绑定。您基本上将人工寿命期限放在您正在编写的代码上并同时限制其可重用性。当您需要更改UI技术时，您需要再次编写业务逻辑。
由于这个原因，有许多VB6应用程序不得不放弃和重写：它们应该在C ++ COM对象中编写业务逻辑......它们可以从.NET调用。这些相同的VB6程序员继续使用VB.NET Winforms并再次犯了同样的错误。
编辑：至于服务：在需要时编写服务层。服务层通常是位于业务层前面的薄层。它实际上是您的业务逻辑的客户端。通常它将具有相同的接口。除非需要通过网络公开逻辑，否则不需要一个。我一直致力于那些坚持在业务逻辑之前编写WCF层的团队......然后才能在同一台机器上运行所有代码。浪费时间并减慢应用程序。