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.
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.
有时，演示文稿会复制一些业务逻辑，主要是验证用户输入。 但它也必须存在于业务逻辑层中。 在其他情况下，为了解决性能问题，有必要将一些业务逻辑移至数据库。 Martin Fowler 在此处对此进行了讨论。
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
发布评论
评论（8）
我不喜欢层的 BLL+DAL 名称，它们比澄清更令人困惑。
称之为数据服务和数据持久性。 这会让事情变得更容易。
服务操作、持久层 CRUD（创建、读取、更新、删除）
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.
Services manipulate, persistence tier CRUDs (Create, Read, Update, Delete)
对我来说，“业务逻辑”构成了代表适用于问题域的数据的所有实体，以及决定“如何处理数据”的逻辑。
所以它真的应该由“数据传输”（而不是访问）和“数据操作”组成。实际上，数据访问（击中数据库的东西）应该位于不同的层，表示代码也应该如此。
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.
我认为您将业务逻辑与应用程序需求混淆了。 这不是同一件事。 当有人解释他/她的业务逻辑时，就像这样：
“当用户购买商品时，他必须提供送货信息。该信息通过 xyz 规则进行验证。之后，他将收到发票并赚取积分，这给了y 优惠的 x% 折扣”（抱歉举了个不好的例子）
当您实施此业务规则时，您必须考虑次要需求，例如如何呈现信息、如何以持久方式存储信息、与应用程序服务器的通信、用户如何接收发票等等。 所有这些需求都不是业务逻辑的一部分，应该与其解耦。 这样，当业务规则发生变化时，您可以轻松地调整代码。 这是事实。
有时，演示文稿会复制一些业务逻辑，主要是验证用户输入。 但它也必须存在于业务逻辑层中。 在其他情况下，为了解决性能问题，有必要将一些业务逻辑移至数据库。 Martin Fowler 在此处对此进行了讨论。
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)
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.
将事情简化为一行...
业务逻辑是不依赖于/不会随特定 UI/实现细节而改变的代码。
它是由所建模的业务定义/反映的规则、流程等的代码表示。
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 不是业务逻辑。 网络通信不是业务逻辑。
对我来说，业务逻辑是描述业务如何运作的规则，而不是软件架构如何运作。 业务逻辑也有改变的趋势。 例如，业务要求可能是每个客户都有一张与其帐户关联的信用卡。 此要求可能会发生变化，以便客户可以拥有多张信用卡。 理论上，这应该只是业务逻辑的更改，软件的其他部分不会受到影响。
这就是理论。 在现实世界中（正如您所发现的），业务逻辑往往分布在整个软件中。 在上面的示例中，您可能需要向数据库添加另一个表来保存额外的信用卡数据。 您肯定需要更改用户界面。
纯粹主义者说，业务逻辑应该始终完全独立，因此甚至反对在数据库中使用名为“客户”或“帐户”的表。
极端情况下，您最终会得到一个极其通用、无法维护的系统。
肯定有一个强有力的论据支持将大部分业务逻辑保持在一起，而不是将其涂抹在整个系统中，但是（与大多数理论一样）您需要在现实世界中保持务实。
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.
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.
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.
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.
业务逻辑是纯粹的抽象，它的存在独立于用户面前数据的具体化/可视化，并且独立于底层数据的持久性。
例如，在税务准备软件中，业务逻辑类的职责之一是计算所欠税款。 他们不负责显示报告或保存和检索纳税申报表。
@Lars，“服务”意味着某种架构。
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.
如果它包含有关表单、按钮等的任何内容，那么它不是业务逻辑，而是表示层。 如果它包含对文件或数据库的持久性，那么它就是 DAL。 介于两者之间的任何内容都是业务逻辑。 事实上，任何非 UI 的东西有时都被称为“业务逻辑”，但它应该是涉及问题领域的东西，而不是内务管理。
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.
只需用简单的英语定义您正在做什么。 当你从商业角度说事情时，比如“让那些人受苦”、“偷那笔钱”、“摧毁地球的这一部分”，你正在谈论业务层。 明确地说，让你兴奋的事情都放在这里。
当你说“在这里显示这个”、“不显示那个”、“让它更漂亮”时，你正在谈论表示层。 这些都是让你的设计师兴奋的事情。
当你说“保存这个”、“从数据库获取这个”、“更新”、“删除”等时，你正在谈论数据层。 这些东西告诉你要不惜一切代价永远保留什么。
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.