为什么我们需要业务逻辑层？
我正在开发使用Web服务的ASP.net应用程序。 我的应用程序没有直接的数据库连接 – 所有活动都是使用Web服务处理的。
在UI层，我可以使用几行Linq代码进行数据自定义和validation。 如果我的应用程序没有业务层，有什么缺点？
将所有validation和业务逻辑放入自己的层中有很多原因。
-
它将您的所有业务逻辑本地化，并在一个地方。 因此，未来的变化将更加容易。
-
它使您可以更轻松地对业务逻辑进行unit testing 。 这是一个很大的问题。 如果此代码与您的网页或窗口forms紧密耦合，则很难针对您的业务逻辑编写自动化unit testing。
-
它使您的UI更加苗条。
另请参阅： 单一责任原则 （简而言之，您的UI类应该执行UI事务，而不是业务逻辑事务）。
如果您的UI代码处理与UI无关的事情，例如业务逻辑，则代码缺乏关注点分离 。 假设您要使用完全不同的UI – 例如，您希望从Web服务切换到创建实际的Web站点/应用程序。 您必须在新UI层中完全重现所有业务逻辑，因为业务逻辑与当前UI相关联。
关注点分离（SoC）是将计算机程序分离为尽可能少地在function上重叠的不同特征的过程。 关注点是程序中的任何兴趣或焦点。 通常，顾虑与特征或行为是同义词。 传统上，在信息隐藏的帮助下，通过编程和封装的模块化（或操作的“透明度”）实现SoC的进步。 信息系统中的分层设计通常也基于关注点的分离（例如，表示层，业务逻辑层，数据访问层，数据库层）。
SoC和SRP使得它更容易和更简单：
- 维护现有代码
- 重用现有代码
- 写测试，特别是unit testing
- 编写健壮的代码，例如改变一个组件不太可能破坏其他组件的代码
这是一个类比（是的，它简化了）：汽车部分使用方向盘和油门踏板控制。 方向盘控制汽车的方向，油门踏板控制汽车的速度。
如果一个设备控制汽车的方向和速度，驾驶员将更安全，更精确地操作汽车将更加困难。 例如，如果驾驶员不得不推动方向盘或将其拉出以使汽车行驶更快或更慢，他们可能会同时改变汽车的方向。 同样，驾驶员在试图转弯时可能会意外地改变车速。
将两个问题（速度和方向）分开使得驾驶更容易，更安全。
也可以看看
- 你如何解释对他人的分离？
- 明确单一责任原则。
- 分离关注/单一责任原则
关注点分离 ：
- 您的用户界面不应该知道您的业务逻辑，它应该只知道显示内容和响应用户交互。
- 您的数据访问代码不应该知道业务逻辑，它应该只知道获取和保存数据库的东西。
- 您的业务逻辑不应该存在持久性或UI问题。
此外，正如SRP所述的SOLID原则 – 一个类只应出于一个原因而改变。 如果您没有将业务逻辑分开，则违反了这一原则。
问自己一个问题：这个应用程序中是否有业务逻辑？
或者说：是吗？
- 只需向关系数据库提供基本的开箱即用的Web CRUDfunction，或者您
- 创建一个应用程序，其中有一些重要的基础概念，你已经（或应该）建模到类中。 这可能是与您的应用程序处理的业务领域中的规则和实体相关的概念，或者是对正确处理应用程序要求很重要的算法概念。
在第一种情况下，我会说业务层实际上可能会给简单的应用程序增加不必要的复杂性。
在第二种情况下，您当然应该创建一些业务对象，并尝试将它们从数据库和UI中解开（高内聚，低耦合，封装信息隐藏）。 使您的业务逻辑可用于独立unit testing，并问自己是否可以快速从Oracle迁移到SQL Server数据库，或者从winforms UI迁移到使用相同业务逻辑的Silverlight应用程序。
如果将来要在此特定UI之外使用相同的validation/业务逻辑，会发生什么？ 也许这个应用程序需要公开一个包含相同逻辑的web服务？ 或者您可能正在使用客户端/服务器应用程序，独立的Windows应用程序和asp.net Web应用程序，所有这些都使用相同的业务和validation逻辑 – 在这种情况下，关注点的分离将为您节省大量冗余代码和很多错误的机会（从而减少调试时间）。