logo标签列表

一个应用程序中的“业务逻辑”到底包括什么？

business-logic-layer
20

我听过无数次“不应该将业务逻辑与其他代码混合使用”或类似的说法。我的意思是，我认为我编写的每一行代码（我指处理步骤）都包含与业务需求相关的逻辑。

有没有人能告诉我业务逻辑到底包括哪些内容？它如何与其他代码区分开来？是否有一些简单的测试方法来确定哪些是业务逻辑而哪些不是？

8个回答
49

用简单易懂的语言描述你正在做的事情。当你表述业务内容时，比如“让那些人蒙受损失”、“窃取那笔钱”、“摧毁这部分地球”，你在谈论业务层面。更明确地说，让你兴奋的事情属于该层次。

当你说“在这里展示这个”，“不要展示那个”，“让它更美观”时，你在谈论演示层面。这些是让设计师感到兴奋的事情。

当你说“保存这个”、“从数据库获取这个”、“更新”、“删除”等内容时，你正在谈论数据层面。这些是告诉你要以任何代价永久保留的东西。

在我看来，Serhat所解释的并不像他说的那么简单。你可以从数据库中获取一些数据，在业务层中进行内存操作，或者完全在数据访问层中进行操作。 - Elisabeth
12

说起什么是业务逻辑，也许更容易的是先说出什么不是业务逻辑。访问数据库或磁盘并不是业务逻辑，用户界面也不是业务逻辑，网络通信也不是业务逻辑。

对我而言，业务逻辑是描述企业运营方式的规则，而不是软件体系结构的运行方式。业务逻辑也往往会变化。例如，可能需要每个客户账户关联一个信用卡，这一要求可能会改变为客户可以拥有多张信用卡。理论上，这只应该是业务逻辑的变化，软件的其他部分不应受到影响。

但在现实世界中（正如你所发现的），业务逻辑往往会遍布整个软件系统。在上述示例中，您可能需要向数据库添加另一个表来保存额外的信用卡数据。您肯定需要改变界面。

“纯粹主义者”认为业务逻辑应始终完全独立，因此甚至反对在数据库中使用“Customers”或“Accounts”等命名表。如果走极端，您最终将得到一个非常通用，难以维护的系统。

显然，保持大部分业务逻辑集中在一起而不是遍布整个系统有很有力的论据，但是（就像大多数理论一样），你需要在实际环境中保持实用主义。

5
简单来说，业务逻辑指的是不依赖于特定用户界面/实现细节且不会随之改变的代码。它是对所建模业务定义的规则、流程等的代码表示。
5
我认为你将业务逻辑与应用需求混淆了。这并不一样。当有人解释他/她的业务逻辑时，就像是这样的：
“当用户购买物品时，他必须提供交付信息。该信息经过x y z规则验证。之后，他将收到发票并获得积分，从而为y个优惠提供x％的折扣”（对于糟糕的例子感到抱歉）
当您实施此业务规则时，您必须考虑次要需求，例如如何呈现信息，如何以持久方式存储信息，与应用服务器的通信方式，用户将如何收到发票等等。所有这些要求都不是业务逻辑的一部分，并且应该与其分离。这样，当业务规则更改时，您将以较少的工作量调整代码。这是事实。
有时候，表示层复制了一些业务逻辑，主要是在验证用户输入方面。但它也必须存在于业务逻辑层中。在其他情况下，需要将一些业务逻辑移动到数据库中，以解决性能问题。Martin Fowler在这里讨论了这个问题。
我想补充一点，出于数据完整性的原因，业务逻辑很多时候必须在数据库层面上实现，而不仅仅是为了提高性能。事实上，许多来源都可能影响数据库中的数据，如果业务规则必须在所有情况下都得到应用，那么它就应该放在数据库中。 - HLGEM
2

我不喜欢BLL+DAL层的名字，它们更容易混淆而不是澄清。
改成DataServices和DataPersistence会更容易理解。

服务层(Service)用于数据操作，持久化层(Persistence)则负责CRUD(Create, Read, Update, Delete)。

0
对我来说，“业务逻辑”包括代表问题域适用数据的所有实体，以及决定“如何处理数据”的逻辑。
因此，它应该真正包括“数据传输”（而不是访问）和“数据操作”。实际上，数据访问（命中数据库的内容）应该在不同的层中，演示代码也应该如此。
0
如果它包含有关表单、按钮等内容，那就不是业务逻辑，而是表示层。如果它包含将数据持久化到文件或数据库中，那就是数据访问层（DAL）。介于两者之间的任何东西都是业务逻辑。在现实生活中，所有非 UI 的东西有时都被称为“业务逻辑”，但它应该与问题域有关，而不是与行政管理有关。
0

业务逻辑是纯抽象的，它存在于用户面前数据的实现/可视化之外，也独立于底层数据的持久性。

例如，在税务准备软件中，业务逻辑类的一个职责是计算应缴税款。它们不负责显示报告或保存和检索税务申报表。

@Lars，“services” 意味着一种特定的架构。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接