为什么我们需要业务逻辑层？

Question

我正在开发使用Web服务的ASP.net应用程序。直接来自我的应用程序没有数据库连接 - 所有活动都是使用Web服务处理的。

在UI层中，我可以使用几行Linq代码进行数据自定义和验证。如果我的应用程序没有业务层，有什么缺点？

Answer 1

将所有验证和业务逻辑放入自己的层中有很多原因。

1. 它将您的所有业务逻辑本地化，并在一个地方。结果将来会更容易。

2. 它可让您更轻松地对业务逻辑进行单元测试。这是一个很大的问题。如果此代码与您的网页或窗口形式紧密耦合，则很难针对您的业务逻辑编写自动化单元测试。

3. 它让你的UI更加苗条。

另请参阅：single responsibility principle（简而言之，您的UI类应该执行UI操作，而不是业务逻辑操作）。

Answer 2

如果您的UI代码处理与UI无关的事情，例如业务逻辑，则代码缺少separation of concerns。假设您要使用完全不同的UI - 例如，您希望从Web服务切换到创建实际的Web站点/应用程序。您必须在新UI层中完全重现所有业务逻辑，因为业务逻辑与当前UI相关联。

  

关注点分离（SoC）是将计算机程序分离为尽可能少地在功能上重叠的不同功能的过程。关注点是程序中的任何兴趣或焦点。通常，顾虑与特征或行为是同义词。传统上通过编程和封装的模块化（或操作的“透明度”）在信息隐藏的帮助下实现SoC的进步。信息系统中的分层设计通常也基于关注点的分离（例如，表示层，业务逻辑层，数据访问层，数据库层）。

SoC和SRP让它更简单，更简单：

• 维护现有代码
• 重用现有代码
• 编写测试，特别是单元测试
• 编写健壮的代码，例如更改一个组件的代码不太可能破坏其他组件

---

这是一个类比（是的，它是简化的）：汽车部分使用方向盘和油门踏板控制。方向盘控制汽车的方向，油门踏板控制汽车的速度。

如果一个设备控制汽车的方向和速度，驾驶员将更难安全准确地操作汽车。例如，如果驾驶员必须将方向盘推入或将其拉出以使汽车行驶更快或更慢，他们可能会同时改变汽车的方向。同样，驾驶员在试图转弯时可能会意外地改变车速。

将两个问题（速度和方向）分开使得驾驶更容易，更安全。

---

另见

• How do you explain Separation of Concerns to others?
• Clarify the Single Responsibility Principle.
• Separation of Concern/Single Responsibilty Principle

Answer 3

Separation of concerns：

• 您的用户界面不应该了解您的业务逻辑，它应该只知道显示内容和响应用户交互。
• 您的数据访问代码不应该了解业务逻辑，它应该只知道如何获取和保存数据库。
• 您的业务逻辑不应该存在持久性或UI问题。

此外，正如SOLID原则SRP所述 - 一个类只应因某种原因而改变。如果您没有将业务逻辑分开，则违反了这一原则。

Answer 4

问自己一个问题：此应用程序中是否存在业务逻辑？

或者更确切地说： 你是

吗？

1. 简单地为关系数据库提供基本的开箱即用网络CRUD功能，或者是
2. 创建一个应用程序，其中有一些重要的基础概念已经（或应该）建模到类中。这可能是与您的应用程序处理的业务领域中的规则和实体相关的概念，或者是对正确处理应用程序要求非常重要的算法概念。

在第一种情况下，我会说业务层实际上可能会给简单的应用程序增加不必要的复杂性。

在第二种情况下，您当然应该创建一些业务对象并尝试将它们从数据库和UI中解开（高内聚，低耦合，信息隐藏封装）。使您的业务逻辑可用于独立单元测试，并问自己是否可以快速从Oracle迁移到SQL Server数据库，或者从winforms UI迁移到使用相同业务逻辑的Silverlight应用程序。

Answer 5

如果将来要在此特定UI之外使用相同的验证/业务逻辑，会发生什么？也许这个应用程序需要公开一个包含相同逻辑的web服务？或者您可能正在使用客户端/服务器应用程序，独立的Windows应用程序和asp.net Web应用程序，所有这些都使用相同的业务和验证逻辑 - 在这种情况下，关注点分离将为您节省大量冗余代码和很多错误的机会（从而减少调试时间）。