I have heard umpteen times that we 'should not mix business logic with other code' or statements like that. I think every single code I write (processing steps I mean) consists of logic that is related to the business requirements..
我听过很多次,我们不应该将业务逻辑与其他代码或类似的语句混合在一起。我认为我编写的每一个代码(我的意思是处理步骤)都包含与业务需求相关的逻辑。
Can anyone tell me what exactly consists of business logic? How can it be distinguished from other code? Is there some simple test to determine what is business logic and what is not?
任何人都可以告诉我究竟什么是业务逻辑?如何区别于其他代码?是否有一些简单的测试来确定什么是业务逻辑,什么不是?
8 个解决方案
#1
43
Simply define what you are doing in plain English. When you are saying things businesswise, like "make those suffer", "steal that money", "destroy this portion of earth" you are talking about business layer. To make it clear, things that get you excited go here.
只需用简单的英语定义您正在做的事情。当你在商业上说话时,比如“让那些受苦”,“偷钱”,“摧毁这部分地球”,你在谈论商业层。为了说清楚,让你兴奋的事情就在这里。
When you are saying "show this here", "do not show that", "make it more beautiful" you are talking about the presentation layer. These are the things that get your designers excited.
当你说“在这里展示”,“不要表现出来”,“让它变得更美丽”时,你正在谈论表现层。这些都是让设计师兴奋的事情。
When you are saying things like "save this", "get this from database", "update", "delete", etc. you are talking about the data layer. These are the things that tell you what to keep forever at all costs.
当你说“保存这个”,“从数据库中获取”,“更新”,“删除”等等时,你正在谈论数据层。这些东西告诉你不惜一切代价永远保留什么。
#2
8
It's probably easier to start by saying what isn't business logic. Database or disk access isn't business logic. UI isn't business logic. Network communications aren't business logic.
通过说出什么不是业务逻辑,开始可能更容易。数据库或磁盘访问不是业务逻辑。 UI不是业务逻辑。网络通信不是业务逻辑。
To me, business logic is the rules that describe how a business operates, not how a software architecture operates. Business logic also has a tendency to change. For example, it may be a business requirement that every customer has a single credit card associated with their account. This requirement may change so that customers can have several credit cards. In theory, this should just be a change to the business logic and other parts of your software will not be affected.
对我而言,业务逻辑是描述业务运营方式的规则,而不是软件架构的运作方式。业务逻辑也有变化的趋势。例如,每个客户都有一个与其帐户相关联的信用卡可能是业务要求。此要求可能会更改,以便客户可以拥有多张信用卡。从理论上讲,这应该只是对业务逻辑的改变,而软件的其他部分也不会受到影响。
So that's theory. In the real world (as you've found) the business logic tends to spread throughout the software. In the example above, you'll probably need to add another table to your database to hold the extra credit card data. You'll certainly need to change the UI.
这就是理论。在现实世界中(正如您所发现的),业务逻辑倾向于在整个软件中传播。在上面的示例中,您可能需要在数据库中添加另一个表来保存额外的信用卡数据。您当然需要更改UI。
The purists say that business logic should always be completely separate and so would even be against having tables named "Customers" or "Accounts" in the database. Taken to its extreme you'd end up with an incredibly generic, impossible to maintain system.
纯粹主义者说,业务逻辑应该始终是完全独立的,因此甚至会反对在数据库中使用名为“Customers”或“Accounts”的表。在极端情况下,你最终会得到一个非常通用,不可能维护的系统。
There's definitely a strong argument in favour of keeping most of your business logic together rather than smearing it throughout the system, but (as with most theories) you need to be pragmatic in the real world.
肯定有一个强烈的论据支持将大部分业务逻辑保持在一起而不是在整个系统中涂抹它,但是(与大多数理论一样)你需要在现实世界中务实。
#3
5
I think you confusing business logic with your application requirements. It's not the same thing. When someone explains the logic of his/her business it is something like:
我认为您将业务逻辑与您的应用程序要求混淆。这不是一回事。当有人解释他/她的业务逻辑时,它是这样的:
"When a user buys an item he has to provide delivery information. The information is validated with x y z rules. After that he will receive an invoice and earn points, that gives x% in discounts for the y offers" (sorry for the bad example)
“当用户购买商品时,他必须提供送货信息。信息通过xyz规则验证。之后,他将收到发票并获得积分,这为y要约的折扣提供了x%”(对不起的例子感到抱歉) )
When you implement this business rules you'll have to think in secondary requirements, like how the information is presented, how it will be stored in a persistent way, the communication with application servers, how the user will receive the invoice and so on. All this requirements are not part of business logic and should be decoupled from it. This way, when the business rules change you will adapt your code with less effort. Thats a fact.
实施此业务规则时,您必须考虑二级需求,例如信息的呈现方式,如何以持久的方式存储信息,与应用程序服务器的通信,用户如何收到发票等等。所有这些要求都不是业务逻辑的一部分,应该与它分离。这样,当业务规则发生变化时,您将更轻松地调整代码。这是事实。
Sometimes the presentation replicates some of the business logic, mostly in validating user input. But it has to be also present in the business logic layer. In other situations, is necessary to move some business logic to the Database, for performance issues. This is discussed by Martin Fowler here.
有时,演示文稿会复制一些业务逻辑,主要是验证用户输入。但它必须也存在于业务逻辑层中。在其他情况下,有必要将一些业务逻辑移动到数据库,以解决性能问题。 Martin Fowler在此对此进行了讨论。
#4
4
To simplify things to a single line...
Business Logic would be code that doesn't depend on/won't change with a specific UI/implementation detail.. It is a code-representation of the rules, processes, etc. that are defined by/reflect the business being modelled.
将事物简化为单行...业务逻辑将是不依赖于/不会随特定UI /实现细节而改变的代码。它是规则,流程等的代码表示。是由/反映被建模的业务。
#5
1
I dont like the BLL+DAL names of the layers, they are more confusing than clarifying.
Call it DataServices and DataPersistence. This will make it easier.
我不喜欢层的BLL + DAL名称,它们比澄清更令人困惑。称之为DataServices和DataPersistence。这将使它更容易。
Services manipulate, persistence tier CRUDs (Create, Read, Update, Delete)
服务操作,持久层CRUD(创建,读取,更新,删除)
#6
0
For me, " business logic " makes up all the entities that represent data applicable to the problem domain, as well as the logic that decides on "what do do with the data"..
对我来说,“业务逻辑”构成了代表适用于问题域的数据的所有实体,以及决定“如何处理数据”的逻辑。
So it should really consist of "data transport" (not access) and "data manipulation".. Actually data access (stuff hitting the DB) should be in a different layer, as should presentation code.
所以它应该真的包括“数据传输”(不是访问)和“数据操作”。实际上数据访问(击中数据库的东西)应该在不同的层中,就像表示代码一样。
#7
0
If it contains anything about things like form, button, etc.. it's not a business logic, it's presentation layer. If it contains persistence to file or database, it's DAL. Anything in between is business logic. In reality, anything non-UI sometimes gets called "business logic," but it should be something that concerns the problem domain, not house keeping.
如果它包含任何关于形式,按钮等的东西..它不是业务逻辑,它是表示层。如果它包含文件或数据库的持久性,则它是DAL。介于两者之间的是业务逻辑。实际上,任何非UI有时被称为“业务逻辑”,但它应该是涉及问题领域而不是内容管理的东西。
#8
0
Business logic is pure abstraction, it exists independent of the materialization/visualization of the data in front of your user, and independent of the persistence of the underlying data.
业务逻辑是纯粹的抽象,它独立于用户面前数据的实现/可视化,并且独立于底层数据的持久性。
For example, in Tax Preparation software, one responsibility of the business logic classes would computation of tax owed. They would not be responsible for displaying reports or saving and retrieving a tax return.
例如,在税务准备软件中,业务逻辑类的一个职责是计算欠税。他们不负责显示报告或保存和检索纳税申报表。
@Lars, "services" implies a certain architecture.
@Lars,“服务”意味着某种架构。
#1
43
Simply define what you are doing in plain English. When you are saying things businesswise, like "make those suffer", "steal that money", "destroy this portion of earth" you are talking about business layer. To make it clear, things that get you excited go here.
只需用简单的英语定义您正在做的事情。当你在商业上说话时,比如“让那些受苦”,“偷钱”,“摧毁这部分地球”,你在谈论商业层。为了说清楚,让你兴奋的事情就在这里。
When you are saying "show this here", "do not show that", "make it more beautiful" you are talking about the presentation layer. These are the things that get your designers excited.
当你说“在这里展示”,“不要表现出来”,“让它变得更美丽”时,你正在谈论表现层。这些都是让设计师兴奋的事情。
When you are saying things like "save this", "get this from database", "update", "delete", etc. you are talking about the data layer. These are the things that tell you what to keep forever at all costs.
当你说“保存这个”,“从数据库中获取”,“更新”,“删除”等等时,你正在谈论数据层。这些东西告诉你不惜一切代价永远保留什么。
#2
8
It's probably easier to start by saying what isn't business logic. Database or disk access isn't business logic. UI isn't business logic. Network communications aren't business logic.
通过说出什么不是业务逻辑,开始可能更容易。数据库或磁盘访问不是业务逻辑。 UI不是业务逻辑。网络通信不是业务逻辑。
To me, business logic is the rules that describe how a business operates, not how a software architecture operates. Business logic also has a tendency to change. For example, it may be a business requirement that every customer has a single credit card associated with their account. This requirement may change so that customers can have several credit cards. In theory, this should just be a change to the business logic and other parts of your software will not be affected.
对我而言,业务逻辑是描述业务运营方式的规则,而不是软件架构的运作方式。业务逻辑也有变化的趋势。例如,每个客户都有一个与其帐户相关联的信用卡可能是业务要求。此要求可能会更改,以便客户可以拥有多张信用卡。从理论上讲,这应该只是对业务逻辑的改变,而软件的其他部分也不会受到影响。
So that's theory. In the real world (as you've found) the business logic tends to spread throughout the software. In the example above, you'll probably need to add another table to your database to hold the extra credit card data. You'll certainly need to change the UI.
这就是理论。在现实世界中(正如您所发现的),业务逻辑倾向于在整个软件中传播。在上面的示例中,您可能需要在数据库中添加另一个表来保存额外的信用卡数据。您当然需要更改UI。
The purists say that business logic should always be completely separate and so would even be against having tables named "Customers" or "Accounts" in the database. Taken to its extreme you'd end up with an incredibly generic, impossible to maintain system.
纯粹主义者说,业务逻辑应该始终是完全独立的,因此甚至会反对在数据库中使用名为“Customers”或“Accounts”的表。在极端情况下,你最终会得到一个非常通用,不可能维护的系统。
There's definitely a strong argument in favour of keeping most of your business logic together rather than smearing it throughout the system, but (as with most theories) you need to be pragmatic in the real world.
肯定有一个强烈的论据支持将大部分业务逻辑保持在一起而不是在整个系统中涂抹它,但是(与大多数理论一样)你需要在现实世界中务实。
#3
5
I think you confusing business logic with your application requirements. It's not the same thing. When someone explains the logic of his/her business it is something like:
我认为您将业务逻辑与您的应用程序要求混淆。这不是一回事。当有人解释他/她的业务逻辑时,它是这样的:
"When a user buys an item he has to provide delivery information. The information is validated with x y z rules. After that he will receive an invoice and earn points, that gives x% in discounts for the y offers" (sorry for the bad example)
“当用户购买商品时,他必须提供送货信息。信息通过xyz规则验证。之后,他将收到发票并获得积分,这为y要约的折扣提供了x%”(对不起的例子感到抱歉) )
When you implement this business rules you'll have to think in secondary requirements, like how the information is presented, how it will be stored in a persistent way, the communication with application servers, how the user will receive the invoice and so on. All this requirements are not part of business logic and should be decoupled from it. This way, when the business rules change you will adapt your code with less effort. Thats a fact.
实施此业务规则时,您必须考虑二级需求,例如信息的呈现方式,如何以持久的方式存储信息,与应用程序服务器的通信,用户如何收到发票等等。所有这些要求都不是业务逻辑的一部分,应该与它分离。这样,当业务规则发生变化时,您将更轻松地调整代码。这是事实。
Sometimes the presentation replicates some of the business logic, mostly in validating user input. But it has to be also present in the business logic layer. In other situations, is necessary to move some business logic to the Database, for performance issues. This is discussed by Martin Fowler here.
有时,演示文稿会复制一些业务逻辑,主要是验证用户输入。但它必须也存在于业务逻辑层中。在其他情况下,有必要将一些业务逻辑移动到数据库,以解决性能问题。 Martin Fowler在此对此进行了讨论。
#4
4
To simplify things to a single line...
Business Logic would be code that doesn't depend on/won't change with a specific UI/implementation detail.. It is a code-representation of the rules, processes, etc. that are defined by/reflect the business being modelled.
将事物简化为单行...业务逻辑将是不依赖于/不会随特定UI /实现细节而改变的代码。它是规则,流程等的代码表示。是由/反映被建模的业务。
#5
1
I dont like the BLL+DAL names of the layers, they are more confusing than clarifying.
Call it DataServices and DataPersistence. This will make it easier.
我不喜欢层的BLL + DAL名称,它们比澄清更令人困惑。称之为DataServices和DataPersistence。这将使它更容易。
Services manipulate, persistence tier CRUDs (Create, Read, Update, Delete)
服务操作,持久层CRUD(创建,读取,更新,删除)
#6
0
For me, " business logic " makes up all the entities that represent data applicable to the problem domain, as well as the logic that decides on "what do do with the data"..
对我来说,“业务逻辑”构成了代表适用于问题域的数据的所有实体,以及决定“如何处理数据”的逻辑。
So it should really consist of "data transport" (not access) and "data manipulation".. Actually data access (stuff hitting the DB) should be in a different layer, as should presentation code.
所以它应该真的包括“数据传输”(不是访问)和“数据操作”。实际上数据访问(击中数据库的东西)应该在不同的层中,就像表示代码一样。
#7
0
If it contains anything about things like form, button, etc.. it's not a business logic, it's presentation layer. If it contains persistence to file or database, it's DAL. Anything in between is business logic. In reality, anything non-UI sometimes gets called "business logic," but it should be something that concerns the problem domain, not house keeping.
如果它包含任何关于形式,按钮等的东西..它不是业务逻辑,它是表示层。如果它包含文件或数据库的持久性,则它是DAL。介于两者之间的是业务逻辑。实际上,任何非UI有时被称为“业务逻辑”,但它应该是涉及问题领域而不是内容管理的东西。
#8
0
Business logic is pure abstraction, it exists independent of the materialization/visualization of the data in front of your user, and independent of the persistence of the underlying data.
业务逻辑是纯粹的抽象,它独立于用户面前数据的实现/可视化,并且独立于底层数据的持久性。
For example, in Tax Preparation software, one responsibility of the business logic classes would computation of tax owed. They would not be responsible for displaying reports or saving and retrieving a tax return.
例如,在税务准备软件中,业务逻辑类的一个职责是计算欠税。他们不负责显示报告或保存和检索纳税申报表。
@Lars, "services" implies a certain architecture.
@Lars,“服务”意味着某种架构。