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