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