我已经无数次听到我们"不应将业务逻辑与其他代码混合"或者类似的声明。我认为我编写的每个代码(我指的是处理步骤)都包含与业务需求相关的逻辑。

谁能告诉我到底什么才是业务逻辑？如何将其与其他代码区分开？是否有一些简单的测试来确定什么是业务逻辑，什么不是？

解决方案

回答

只需用简单的英语定义我们在做什么。当我们以商业眼光谈论事情时，例如"让那些人受苦"，"窃取金钱"，"摧毁这部分土地"，我们所谈论的是商业层面。为了明确起见，让我们兴奋的事情就在这里。

当我们说"在这里显示"，"不要显示"，"使其更美观"时，我们是在谈论表示层。这些使设计师兴奋不已。

当我们说诸如"保存此"，"从数据库中获取此"，"更新"，"删除"等之类的内容时，我们正在谈论的是数据层。这些都是告诉我们不惜一切代价永远保留的东西的事情。

回答

对我来说，"业务逻辑"构成代表适用于问题域的数据的所有实体，以及决定"对数据做什么"的逻辑。

因此，它实际上应该由"数据传输"(不是访问)和"数据操纵"组成。实际上，数据访问(东西碰到数据库)应该在不同的层中，表示代码也应该在不同的层中。

回答

如果它包含有关表单，按钮等的任何内容，则不是业务逻辑，而是表示层。如果它包含对文件或者数据库的持久性，则为DAL。介于两者之间的是业务逻辑。实际上，任何非UI有时都称为"业务逻辑"，但这应该是与问题领域有关的，而不是与内部管理有关的事情。

回答

我不喜欢这些图层的BLL + DAL名称，它们比澄清更令人困惑。
将其称为DataServices和DataPersistence。这将使其更容易。

服务操纵持久层CRUD(创建，读取，更新，删除)

回答

业务逻辑是纯抽象的，它独立于用户面前数据的实现/可视化而存在，并且与基础数据的持久性无关。

例如，在税务准备软件中，业务逻辑类的职责之一就是计算所欠税款。他们将不负责显示报告或者保存和检索纳税申报单。

@Lars，"服务"表示某种体系结构。

回答

说什么不是业务逻辑可能更容易开始。数据库或者磁盘访问不是业务逻辑。 UI不是业务逻辑。网络通信不是业务逻辑。

对我而言，业务逻辑是描述业务运作方式而不是软件架构运作方式的规则。业务逻辑也有变化的趋势。例如，可能有一个业务要求，即每个客户都必须拥有与其帐户关联的一张信用卡。此要求可能会更改，以便客户可以使用几张信用卡。从理论上讲，这仅是对业务逻辑的更改，并且软件的其他部分不会受到影响。

这就是理论。在现实世界中(正如我们所发现的)，业务逻辑倾向于在整个软件中传播。在上面的示例中，我们可能需要向数据库中添加另一个表，以容纳额外的信用卡数据。我们当然需要更改UI。

纯粹主义者说，业务逻辑应该始终完全分开，因此甚至反对在数据库中使用名为" Customers"或者" Accounts"的表。
极端到极点，我们最终将获得难以置信的通用性，无法维护系统。

肯定有一个强有力的论据支持将大多数业务逻辑放在一起，而不是在整个系统中涂抹它们，但是(与大多数理论一样)我们在现实世界中需要务实。

回答

要将事情简化为一行...
业务逻辑将是不依赖/不会因特定的UI /实现细节而更改的代码。
它是规则，流程等的代码表示，由规则业务定义/反映所建模的业务。

回答

我认为我们将业务逻辑与应用程序需求混为一谈。这不是同一回事。当某人解释其业务逻辑时，它类似于：

"当用户购买商品时，他必须提供送货信息。该信息将通过xyz规则进行验证。此后，他将收到发票并获得积分，这将为y优惠提供x％的折扣"(抱歉，这个不好的例子)

实施此业务规则时，我们将不得不考虑次级要求，例如信息的显示方式，信息的持久存储方式，与应用程序服务器的通信，用户如何收到发票等。所有这些要求都不是业务逻辑的一部分，应该与其分离。这样，当业务规则更改时，我们将花费更少的精力修改代码。这是事实。

有时，演示文稿会复制一些业务逻辑，主要是在验证用户输入中。但是它也必须存在于业务逻辑层中。在其他情况下，有必要将一些业务逻辑移至数据库，以解决性能问题。这是Martin Fowler在这里讨论的。