我正在浏览各种WPF文档，我感到不必要的困惑。 “业务逻辑”这个术语分散在其中，好像每个人都应该知道它是什么。
根据这个问题，我可以看到什么是商业逻辑： What exactly consists of 'Business Logic' in an application?
但这个词来自哪里？为什么它被称为“业务逻辑”而不是“核心逻辑”或“主要算法”或任何其他更通用的术语？我编写的程序很少与“业务逻辑”有关，当我想到“业务逻辑”时，我会想到处理信用卡交易，客户数据库维护等的事情。换句话说，与整个计算机科学的一小部分有关的事情。当我写一个成像应用程序时，没有涉及“业务”，没有客户，没有基于货币的交易，没有任何类似。所以说我有'业务逻辑'真的让我困惑，因为我没有开展业务，我正在处理图片。
答案 0 :(得分：29)
出于同样的原因，子弹出来的枪的末端称为“业务终点”。这是主要行动发生的地方。
答案 1 :(得分：19)
如果您是一名专业的平面设计师，那么使用您的成像应用程序肯定将做生意 - 您的工作就是您的事业！
因此，“业务逻辑”指的是定义用户如何开展业务的代码部分（在这种情况下，操纵图像）。
不要忘记，在当天，所有软件都是“商业软件” - 没有人能够承担为商业目的以外的任何其他事情编写软件所需的昂贵设备和技能。如果没有为企业赚钱或省钱，就没有写出来。
答案 2 :(得分：10)
不确定，但我认为该术语应该替换为域逻辑。
答案 3 :(得分：3)
你可以把它称为“核心逻辑”，但我相信第一个（众所周知的）多层应用程序实际上是为保险或银行业务编写的，因此称为“业务逻辑”。从那里开始，模式形成了，命名卡住了。
如果第一个多层应用程序是一个研究项目或类似的东西，它可能会被称为“核心逻辑”。
答案 4 :(得分：2)
当我写一个成像应用程序时，没有涉及“业务”，没有客户，没有基于货币的交易，没有类似的东西。所以说我有'业务逻辑'真的让我困惑，因为我没有开展业务，我正在处理图片。
此外，关于演示和数据的大部分建议也开始向南，因为诸如效果和过滤器之类的操作在业务应用程序的“表示层”中是额外的，是您的核心。
“可视化”，“引擎”和“持久存储”，是我倾向于处理的模拟中各层的常见名称。使用您域中有意义的名称没有问题。但后来我对SAS程序员的所有招聘广告感到困惑，因为这意味着英国防御环境中的其他东西;如果你想与商界人士交谈，你必须为他们翻译。
答案 5 :(得分：1)
该术语的起源是商业软件，其中业务特定规则在其自己的模块中分开。这只是转移到所有其他软件。
答案 6 :(得分：1)
考虑早期的计算机系统，如信用卡处理，代码有两大部分，执行io的部分，与后端，磁带等交谈，以及执行业务逻辑的部分，规则，如卡，有效，超出限制。
考虑它的另一种方式是，商业人士会说的是要捕捉的“规则”。
答案 7 :(得分：1)
业务逻辑是应用程序的一部分，“如何”应该工作是由编程团队以外的人决定的。通常，代码可以完成客户想要完成的任务。该术语通常仅适用于为非IT组织构建的内部软件。
答案 8 :(得分：1)
我认为很多次是讽刺，因为商业逻辑并不总是合乎逻辑的。它只是以某种方式完成，因为企业想要这样 - 很多时候它不是最好的方式。你可以和他们一起战斗（如果幸运的话）让他们看到光明，或者只是接受其业务逻辑的事实，并在他们意识到自己犯了错误时准备改变它。
答案 9 :(得分：0)
这个术语主要用于业务线应用程序＆amp;人们知道它的另一种方式是CRUD app（创建，读取，更新，删除）。
我认为这意味着类包含业务流程如何适用于给定业务流程的逻辑。
答案 10 :(得分：0)
我认为我同意DVK-IIRC，当时，整个Data-＆gt; Logic-＆gt; Presentation层事物是一个“企业”（基本上是：商业）软件的流行语。
既然每个该死的网页都应该是三层的，那就更常见了。
您还必须记住，虽然除了业务代码之外还有很多代码，但业务代码的数量巨大，而且业务量也很大（har har）。一些术语起源于那里并不奇怪。
答案 11 :(得分：0)
就像漂亮的你去洗手间做生意一样，你漂亮的GUI就是为了做生意的逻辑......
（抱歉，无法抗拒:)）
答案 12 :(得分：0)
我认为nmr是正确的。我正在教授HCI软件工程课程，并且需要鼓励学生停止思考“业务逻辑”，而更多地考虑MVC。
以前的教授经常会告诉他们， “ HCI之下是出价逻辑”
我们可以丢掉业务逻辑吗？由于软件很少没有用户界面， 我们可以说，对于软件的其余部分，有视图，用户控件和模型。
这三个实体之间将传递消息。顺便说一下，它们分别是“输出”，“输入” /“状态”。就像图灵（和教会）教过我们一样。
所以...让我们失去“竞价逻辑”