为什么3层模型中的第二层称为“业务”层？
答案 0 :(得分：2)
因为业务逻辑驻留在那里。那就是 - 特定于业务场景的逻辑。
其他层不应该有这样的逻辑。前端应显示和收集数据，数据库应存储数据，dao应检索并保存数据。
业务层应该根据来自UI和数据库的输入来执行逻辑。
这是'业务'，因为每个软件都支持某些业务。
答案 1 :(得分：1)
因为它特定于应用程序的性质 - 慈善机构，在线零售商和地产代理商可能都使用相同的网络服务器和数据库 - 但中间的位置是非常不同的。
答案 2 :(得分：0)
好的，这是我的2美分。
为什么呢？因为这是 N-Tier范例中定义的方式。当它被定义为这样时，我们不能问为什么会这样命名。
N-Tier范式是一个旧的 - 超过10年。 N-Tiere设计虽然在某种程度上帮助将视图逻辑与业务逻辑分开，但现在已经不再流行了。
今天，Domain Driven Design又称DDD是一种新的范例，它会查看域逻辑并在其上构建系统。 域逻辑无处不在，在数据库中，在UI中以及在中间层。因此，如果您正在为披萨店制作软件，那么您的表格将被称为Order，Topping等，如果您正在开发软件，Account，Transaction银行。 所以业务逻辑无处不在，在中间层以及UI或数据库中。
所以现在虽然分层架构仍然被接受为一种良好的架构方法（其中一层不称为“业务层”），N-Tier不是。
答案 3 :(得分：0)
在OO应用程序中，我喜欢将业务层视为应用于对象的业务规则，流程或工作流。然而，在许多情况下，我已经看到这意味着对象变成了POCO（C＃中的普通旧C＃对象，Java中的POJO等）。这个问题是对象的行为与对象分离并转移到任意的“业务逻辑”中。类。
我个人的信念是＆＃34;商业层＆＃34;应该对对象采取行动，但不能将对象替换为对象的行为。这也允许使用继承和多态更好地实现其他实践，例如Open Closed Principle。
考虑这个例子"OCP"，其中Area类将是＆＃34; Business Layer＆＃34;但是各种Shape对象包含每种形状的行为逻辑。这样区域代码很少，如果需要改变的话。