我听过很多次，我们不应该将业务逻辑与其他代码或类似的语句混合在一起。我认为我编写的每一个代码（我的意思是处理步骤）都包含与业务需求相关的逻辑。
谁能告诉我究竟什么是业务逻辑？如何区别于其他代码？是否有一些简单的测试来确定什么是业务逻辑？什么不是？
答案 0 :(得分：43)
简单地用简单的英语定义你在做什么。当你在商业上说话时，比如“让那些受苦”，“偷钱”，“摧毁这部分地球”，你在谈论商业层。为了说清楚，让你兴奋的事情就在这里。
当你说“在这里显示”时，“不要显示”，“让它变得更漂亮”，你在谈论表现层。这些都是让设计师兴奋的事情。
当您说“保存此”，“从数据库中获取”，“更新”，“删除”等内容时，您正在谈论数据层。这些东西告诉你不惜一切代价永远保留什么。
答案 1 :(得分：8)
首先说明不是业务逻辑可能更容易。数据库或磁盘访问不是业务逻辑。 UI不是业务逻辑。网络通信不是业务逻辑。
对我来说，业务逻辑是描述业务运营方式的规则，而不是软件架构的运作方式。业务逻辑也有变化的趋势。例如，每个客户都有一个与其帐户关联的信用卡可能是业务要求。此要求可能会更改，以便客户可以拥有多张信用卡。从理论上讲，这应该只是对业务逻辑的改变，而软件的其他部分也不会受到影响。
这就是理论。在现实世界中（正如您所发现的），业务逻辑倾向于在整个软件中传播。在上面的示例中，您可能需要在数据库中添加另一个表来保存额外的信用卡数据。您当然需要更改UI。
纯粹主义者说，业务逻辑应该始终是完全独立的，因此甚至会反对在数据库中使用名为“Customers”或“Accounts”的表。 尽管如此，你最终会得到一个非常通用的，不可能维护的系统。
肯定有一个强烈的论据支持将大部分业务逻辑保持在一起而不是在整个系统中涂抹它，但是（与大多数理论一样）你需要在现实世界中务实。
答案 2 :(得分：5)
我认为您将业务逻辑与您的应用程序要求混淆。这不是一回事。当有人解释他/她的业务逻辑时，它就像是：
“当用户购买商品时，他必须提供送货信息。信息将通过xyz规则验证。之后，他将收到发票并获得积分，这为y要约提供x％折扣”（对不起糟糕的例子）
当您实施此业务规则时，您必须考虑二级要求，例如信息的呈现方式，如何以持久的方式存储信息，与应用程序服务器的通信，用户如何收到发票以及等等。所有这些要求都不是业务逻辑的一部分，应该与它分离。这样，当业务规则发生变化时，您将更轻松地调整代码。这是一个事实。
有时，演示文稿会复制一些业务逻辑，主要是验证用户输入。但它必须也存在于业务逻辑层中。在其他情况下，有必要将一些业务逻辑移动到数据库，以解决性能问题。 Martin Fowler here对此进行了讨论。
答案 3 :(得分：4)
将事情简化为单行...
业务逻辑将是不依赖于/不会随特定UI /实现细节而改变的代码。
它是由/反映正在建模的业务定义的规则，流程等的代码表示。
答案 4 :(得分：1)
我不喜欢层的BLL + DAL名称，它们比澄清更令人困惑 称之为DataServices和DataPersistence。这将使它更容易。
服务操作，持久层CRUD（创建，读取，更新，删除）
答案 5 :(得分：0)
对我来说，“业务逻辑”构成了代表适用于问题域的数据的所有实体，以及决定“如何处理数据”的逻辑。 / p>
所以它应该真的包括“数据传输”（不是访问）和“数据操作”。实际上，数据访问（触及数据库的东西）应该在不同的层中，就像表示代码一样。
答案 6 :(得分：0)
如果它包含任何关于形式，按钮等的东西..它不是业务逻辑，它是表示层。如果它包含文件或数据库的持久性，则为DAL。介于两者之间的是业务逻辑。实际上，任何非UI有时被称为“业务逻辑”，但它应该是涉及问题领域的东西，而不是内容管理。
答案 7 :(得分：0)
业务逻辑是纯粹的抽象，它独立于用户面前数据的实现/可视化，并且与底层数据的持久性无关。
例如，在税务准备软件中，业务逻辑类的一个职责是计算欠税。他们不负责显示报告或保存和检索纳税申报表。
@Lars，“服务”意味着某种架构。