业务层3

Question

为什么第三层模型中的第二层被称为“业务”层？

Answer 1

因为它特定于应用程序的性质 - 一个慈善机构，网上零售商和房地产经纪人可能都使用相同的网络服务器和数据库 - 但中间的位非常不同。

Answer 2

因为业务逻辑驻留在那里。那就是 - 特定于业务场景的逻辑。

其他层不应该有这样的逻辑。前端应该显示和收集数据，数据库应该存储数据，dao应该检索并保存数据。

业务层应根据来自UI和数据库的输入执行逻辑。

这是'业务'，因为每个软件都支持一些业务。

Answer 3

好的，这里是我的2美分。

为什么？因为这是定义在N层范例。当它被定义为这样的时候，我们不能问为什么这样命名。

N层范式是一个旧的 - 超过10岁。 N-Tiere设计虽然有助于将视图逻辑与商业逻辑分开，但现在已不再流行。

今天，Domain Driven Design又名DDD是一种新的范式，在这个范例中查看领域逻辑并在此基础上构建系统。 域逻辑无处不在，数据库中，用户界面以及中间层。所以如果你正在为披萨店制作软件，那么你的桌子将被称为Order,Topping等，如果你正在为银行开发软件，它将会有Account,Transaction。 所以业务逻辑无处不在，在中间层以及在用户界面或数据库。

所以现在虽然分层架构仍然接受作为一个优秀的架构方法（其中有一个中间层是不称为“业务层”了），N层是没有的。

Answer 4

在一个面向对象的应用程序我喜欢把业务层作为被施加到对象的业务规则，流程或工作流。然而在许多情况下，我已经看到这意味着对象变成除了POCO（C＃中的普通旧C＃对象，Java中POJO等）之外的东西。与此相关的问题是对象的行为与对象分离并移动到任意“业务逻辑”类中。

我个人的信念是，“业务层”应当在对象采取行动而不是替代对象的对象的行为。这也允许更好地实现其他实践，例如使用继承和多态的开放闭合原则。

考虑这个例子"OCP"其中Area类将是“业务层”，但各种形状的对象包含每个类型的形状的行为的逻辑。这种方式很少使用区域代码，如果需要改变的话。