业务层 3答案 - 爱码网

【问题标题】：business layer 3业务层 3
【发布时间】：2011-04-06 12:22:32
【问题描述】：

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

【问题讨论】：

那么告诉我们应该是什么？

标签： architecture layer

【解决方案1】：

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

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

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

这是“业务”，因为每个软件都支持某些业务。

【讨论】：

【解决方案2】：

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

【讨论】：

我认为他们不会使用相同的数据库，它们是不同的主题。也许你的意思是同一个数据库服务器。

【解决方案3】：

好的，这是我的 2 美分。

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

N-Tier 范式是一个古老的范式——已有 10 多年的历史。 N-Tiere 设计虽然在某些时候有助于将视图逻辑与业务逻辑分开，但现在不再流行了。

今天，Domain Driven Design 又名 DDD 是一种新的范式，它着眼于领域逻辑并在此基础上构建系统。 领域逻辑无处不在，在数据库中、在 UI 中以及在中间层中。因此，如果您正在为比萨店制作软件，那么实际上您的桌子将被称为 Order、Topping 等，而如果您正在为银行开发软件，它将具有 Account、Transaction。 所以业务逻辑无处不在，在中间层以及 UI 或数据库中。

所以现在虽然分层架构仍然被认为是一种好的架构方法（它有一个不再称为“业务层”的中间层），但 N-Tier不是。

【讨论】：

我不太同意。首先，DDD 一点也不新鲜。然后，使用 DDD，域逻辑仅在域对象中。不在 UI 上，不在数据库中。领域对象代表“业务层”
域对象是实体。它们不代表业务层。它们实际上驻留在数据层中。
是的，它们是实体。但它们不是 DAO 层——有一个单独的层负责数据库操作（存储库）。瘦服务层负责协调领域对象。尽管如此，业务逻辑并没有像你说的那样分散。
它们不仅仅在数据层，它们无处不在，从数据到 UI。但是由于您需要创建一个依赖层次结构，它们位于每个库都引用的依赖关系的顶部。

【解决方案4】：

在 OO 应用程序中，我喜欢将业务层视为应用于对象的业务规则、流程或工作流。然而，在许多情况下，我看到这意味着对象只是 POCO（C# 中的普通旧 C# 对象，Java 中的 POJO 等）。这样做的问题是对象的行为与对象分离并移动到任意“业务逻辑”类中。

我个人的看法是，“业务层”应该作用于对象，而不是取代对象的行为。这也允许更好地实现其他实践，例如使用继承和多态的开放封闭原则。

考虑这个示例"OCP"，其中Area 类将是“业务层”，但各种Shape 对象包含每种形状类型的行为逻辑。这样，区号很少需要更改。

【讨论】：