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