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

Question

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

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

Answer 1

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

1. 它将您的所有业务逻辑本地化,并在一个地方.因此,未来的变化将更加容易.

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

3. 它使您的UI更加苗条.

另请参阅: 单一责任原则 (简而言之,您的UI类应该执行UI操作,而不是业务逻辑操作).

Answer 2

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

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

SoC和SRP使得它更容易和更简单:

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

这是一个类比(是的,它简化了):汽车部分使用方向盘和油门踏板控制.方向盘控制汽车的方向,油门踏板控制汽车的速度.

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

保持两个问题(速度和方向)分开使驾驶更容易和更安全.

也可以看看

• 你如何解释对他人的分离？
• 明确单一责任原则.
• 分离关注/单一责任原则

Answer 3

关注点分离:

• 您的UI不应该知道您的业务逻辑,它应该只知道显示内容和响应用户交互.
• 您的数据访问代码不应该知道业务逻辑,它应该只知道获取和保存数据库的东西.
• 您的业​​务逻辑不应该存在持久性或UI问题.

此外,正如SRP所述的SOLID原则- 一个类只应该由于一个原因而改变.如果您没有将业务逻辑分开,则违反了这一原则.

Answer 4

问自己一个问题:这个应用程序中是否有业务逻辑？

或者说:你是

1. 只需向关系数据库提供基本的开箱即用的Web CRUD功能,或者您
2. 创建一个应用程序,其中有一些重要的基础概念,你已经(或应该)建模到类中.这可能是与您的应用程序处理的业务领域中的规则和实体相关的概念,或者是对正确处理应用程序要求非常重要的算法概念.

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

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