If you were a professional graphic designer, there certainly would be business involved with using your imaging application - your job is your business!
So "business logic" refers to the parts of the code that define how the user conducts his business (in this case, manipulating images).
Don't forget that back in the day, all software was "business software" - no-one could afford the expensive equipment and skills required to write software for anything other than business purposes. It if didn't make money or save money for a business, it didn't get written.
You could have called it "core logic", but I believe that the first (well-known) multi-tiered apps were actually written for insurance or banking, hence the term "business logic". From there, the pattern took form, and the naming stuck.
Had the first multi-tiered apps been a research project or something, it probably would have been called "core logic".
The origin of the term is in business software, where business specific rules were separated in their own modules. That merely got transferred to all the other software.
“可视化”、“引擎”和“持久存储”是我所从事的模拟中各层的常见名称。使用在您的域中有意义的名称没有问题。但后来我对 SAS 程序员的所有招聘广告感到困惑，因为这在英国国防环境中意味着其他东西；如果你想与商务人士交谈，你必须为他们翻译。
When I write an imaging application, there is no 'business' involved, no customers, no money-based transactions, nothing of the sort. So saying that I have 'business logic' really confuses me, since I'm not conducting business, I'm processing images.
Furthermore, much of the advice about presentation and data starts going south too, as operations such as effects and filters which would be extras in a 'presentation layer' in a business application are the core of yours.
"Visualisation", "Engine" and "Persistent storage", are quite common names for the layers in the simulations I tend to work on. There's no problem using names meaningful in your domain. But then I get confused about all the job ads for SAS programmers, as that means something else in a UK defence setting; if you want to talk to business people you have to translate for them.
Thinking about early computer systems, like credit card processing, there are two large parts to the code, the parts doing the io, talking to the back-ends, tape, etc, and the parts doing the logic of the business, rules like, is the card valid, has the limit been exceeded.
Another way to think about it, it's the things a business person would say are the 'rules' to capture.
业务逻辑是应用程序的一部分，其中“如何”应该由编程团队以外的其他人确定。通常，它是执行客户想要完成的事情的代码。该术语通常仅适用于为非 IT 团队构建的内部软件。
Business logic is that part of an application where "how" is should work is determined by someone other than the programming team. Usually it is the code that does what the customer wants to get done. The term generally only applies to in house software built for a non-IT group.
I think many times its sarcastic, because business logic is not always logical. its done certain way only, because business wants it that way - many times its not the best way. you can fight with them and (if youre lucky) make them see the light or just accept the fact that its business logic and be ready to change it when they realize they made mistake.
I think I agree with DVK - IIRC, at the time, the whole Data->Logic->Presentation layer thing was an "enterprise" (basically: business) software buzzword.
Now that every goddamn web page should be three-tiered, it's much more common.
You also have to remember that while there's a lot of code other than business code, the amount of business code is huge, and a huge business (har har) as well. It's not really surprising that some terms originated there.
I think nmr is quite correct. I'm teaching my HCI software engineering course, and I need to encourage students to stop thinking of "Business Logic" and think more about MVC.
Quite often, their previous professors would tell them that, "Underneath the HCI is the BIDness Logic"
Can we please LOSE the business logic? Since software rarely has NO user interface, we can say, for the rest of the software, there is the View, the user Control, and the Model.
And there will be message passing between these three entities. Which are, by the way, "output", "input"/"state". Just as Turing (and Church) had taught us.
发布评论
评论（13）
出于同样的原因，枪中子弹射出的一端被称为“业务端”。这是主要操作发生的地方。
For the same reason that the end of a gun which the bullets come out of is called the “business end”. It's where the primary action happens.
如果您是一名专业的图形设计师，那么使用您的成像应用程序肯定会涉及到业务 - 您的工作就是您的业务！
因此，“业务逻辑”是指定义用户如何开展业务（在本例中为操作图像）的代码部分。
不要忘记，在过去，所有软件都是“商业软件” - 没有人能够负担得起为商业目的以外的任何目的编写软件所需的昂贵设备和技能。如果它不能为企业赚钱或省钱，它就不会被写下来。
If you were a professional graphic designer, there certainly would be business involved with using your imaging application - your job is your business!
So "business logic" refers to the parts of the code that define how the user conducts his business (in this case, manipulating images).
Don't forget that back in the day, all software was "business software" - no-one could afford the expensive equipment and skills required to write software for anything other than business purposes. It if didn't make money or save money for a business, it didn't get written.
不确定，但我认为该术语应该替换为领域逻辑。
Not sure, but I think the term should be replaced with domain logic instead.
您可以将其称为“核心逻辑”，但我相信第一个（众所周知的）多层应用程序实际上是为保险或银行业务编写的，因此称为“业务逻辑”。从那时起，模式就形成了，命名也随之固定下来。
如果第一个多层应用程序是一个研究项目或其他什么，它可能会被称为“核心逻辑”。
You could have called it "core logic", but I believe that the first (well-known) multi-tiered apps were actually written for insurance or banking, hence the term "business logic". From there, the pattern took form, and the naming stuck.
Had the first multi-tiered apps been a research project or something, it probably would have been called "core logic".
该术语起源于商业软件，其中业务特定规则被分隔在各自的模块中。这只是转移到所有其他软件。
The origin of the term is in business software, where business specific rules were separated in their own modules. That merely got transferred to all the other software.
此外，许多关于表示和数据的建议也开始变质，因为效果和过滤器等操作是业务应用程序“表示层”中的额外操作，而这些操作是您的核心。
“可视化”、“引擎”和“持久存储”是我所从事的模拟中各层的常见名称。使用在您的域中有意义的名称没有问题。但后来我对 SAS 程序员的所有招聘广告感到困惑，因为这在英国国防环境中意味着其他东西；如果你想与商务人士交谈，你必须为他们翻译。
Furthermore, much of the advice about presentation and data starts going south too, as operations such as effects and filters which would be extras in a 'presentation layer' in a business application are the core of yours.
"Visualisation", "Engine" and "Persistent storage", are quite common names for the layers in the simulations I tend to work on. There's no problem using names meaningful in your domain. But then I get confused about all the job ads for SAS programmers, as that means something else in a UK defence setting; if you want to talk to business people you have to translate for them.
考虑早期的计算机系统，例如信用卡处理，代码有两大部分，一部分执行 io，与后端、磁带等通信，另一部分执行业务逻辑，规则如下：该卡是否有效，是否超出限额。
另一种思考方式是，业务人员所说的就是要捕获的“规则”。
Thinking about early computer systems, like credit card processing, there are two large parts to the code, the parts doing the io, talking to the back-ends, tape, etc, and the parts doing the logic of the business, rules like, is the card valid, has the limit been exceeded.
Another way to think about it, it's the things a business person would say are the 'rules' to capture.
业务逻辑是应用程序的一部分，其中“如何”应该由编程团队以外的其他人确定。通常，它是执行客户想要完成的事情的代码。该术语通常仅适用于为非 IT 团队构建的内部软件。
Business logic is that part of an application where "how" is should work is determined by someone other than the programming team. Usually it is the code that does what the customer wants to get done. The term generally only applies to in house software built for a non-IT group.
我认为很多时候这是讽刺，因为业务逻辑并不总是合乎逻辑的。它只是以某种方式完成，因为企业希望这样做——很多时候这不是最好的方式。你可以与他们斗争并（如果你幸运的话）让他们看到光明，或者只是接受其业务逻辑的事实，并准备在他们意识到自己犯了错误时改变它。
I think many times its sarcastic, because business logic is not always logical. its done certain way only, because business wants it that way - many times its not the best way. you can fight with them and (if youre lucky) make them see the light or just accept the fact that its business logic and be ready to change it when they realize they made mistake.
该术语主要用于业务线应用程序和应用程序。人们了解它的另一种方式是 CRUD 应用程序（创建、读取、更新、删除）。
我认为这意味着类包含业务流程如何为给定业务流程工作的逻辑。
It is a term used mainly for Line of business applications & one more way people know of it is CRUD app (create, read, update, delete).
I think it means the class(es) contain the logic of how the business process works for given business process(es).
我想我同意DVK - IIRC，当时，整个数据->逻辑->表示层的东西是一个“企业”（基本上：商业）软件流行语。
现在每个该死的网页都应该是三层的，这更加常见了。
你还要记住，虽然业务代码以外的代码很多，但是业务代码量是巨大的，业务也是巨大的（哈哈）。有些术语起源于此并不奇怪。
I think I agree with DVK - IIRC, at the time, the whole Data->Logic->Presentation layer thing was an "enterprise" (basically: business) software buzzword.
Now that every goddamn web page should be three-tiered, it's much more common.
You also have to remember that while there's a lot of code other than business code, the amount of business code is huge, and a huge business (har har) as well. It's not really surprising that some terms originated there.
我认为核磁共振是非常正确的。我正在教授 HCI 软件工程课程，我需要鼓励学生停止思考“业务逻辑”，而更多地思考 MVC。
很多时候，他们以前的教授会告诉他们，
“HCI 之下是 BIDness 逻辑”
我们可以放弃业务逻辑吗？由于软件很少没有用户界面，
我们可以说，对于软件的其余部分，有视图、用户控件和模型。
这三个实体之间将会有消息传递。顺便说一句，它们是“输出”、“输入”/“状态”。正如图灵（和丘奇）教导我们的那样。
所以......让我们失去“投标逻辑”
I think nmr is quite correct. I'm teaching my HCI software engineering course, and I need to encourage students to stop thinking of "Business Logic" and think more about MVC.
Quite often, their previous professors would tell them that,
"Underneath the HCI is the BIDness Logic"
Can we please LOSE the business logic? Since software rarely has NO user interface,
we can say, for the rest of the software, there is the View, the user Control, and the Model.
And there will be message passing between these three entities. Which are, by the way, "output", "input"/"state". Just as Turing (and Church) had taught us.
So... let's lose 'the bidness logic'
就像漂亮的你去洗手间做你的事情一样，你漂亮的 GUI 也去逻辑去做它的事情..
（抱歉，无法抗拒:)）
Just like the pretty you goes to the bathroom to do your business, your pretty GUI goes to the logic to do its business..
(Sorry, couldn't resist :) )