业务层3
为什么三层模型中的第二层称为“业务”层？
Why the second layer in 3 layer model known as "Business" layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
为什么三层模型中的第二层称为“业务”层？
Why the second layer in 3 layer model known as "Business" layer?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
因为业务逻辑驻留在其中。即特定于业务场景的逻辑。
其他层不应该有这样的逻辑。前端应该显示和收集数据，数据库应该存储数据，dao应该检索和保存数据。
业务层应根据来自 UI 和数据库的输入来执行逻辑。
这是“业务”，因为每个软件都支持一些业务。
Because the business logic resides there. That is - the logic that is specific to the business scenarios.
Other layers should not have such logic. Front end should display and gather data, database should store data, dao should retrieve and save data.
The business layer should perform the logic based on what is coming as input from the UI, and from the DB.
It's 'business', because every software backs some business.
因为它特定于应用程序的性质 - 慈善机构、在线零售商和房地产经纪人可能都使用相同的网络服务器和数据库 - 但中间的部分非常不同。
Because its specific to the nature of the application - a charity, online retailler and estate agents might all use the same webserver and database - but the bit in the middle is very different.
好的，这是我的 2 美分。
为什么？因为这就是N 层范式中定义的方式。当某事物被如此定义时，我们不能问为什么它如此命名。
N 层范式是一种古老的范式 - 已有 10 多年的历史。 N-Tiere 设计虽然在某种程度上有助于将视图逻辑与业务逻辑分开，但现在已经不再流行了。
如今，领域驱动设计（又名 DDD）是一种新的范式，它着眼于领域逻辑并在此基础上构建系统。 领域逻辑无处不在，在数据库中、在 UI 中以及在中间层中。因此，如果您正在为披萨店制作软件，并且该软件将具有
Account、等，那么实际上您的表格将被称为如果您正在为银行开发软件。 因此业务逻辑无处不在，在中间层以及 UI 或数据库中。Order、Topping等。交易因此，虽然现在分层架构仍然被认为是一种良好的架构方法（其中有一个不再称为“业务层”的中间层），但 N-Tier 却不是。
OK, here my 2 cents.
Why? Because that is how it is defined in the N-Tier paradigm. We cannot ask why something is named as such when it is defined as such.
N-Tier paradigm is an old one - more than 10 years old. N-Tiere design while at some point helped separating view logic from business logic, now is not trendy anymore.
Today, Domain Driven Design aka DDD is the new paradigm where looks at the domain logic and builds the system on that. Domain logic is everywhere, in database, in the UI as well as in the middle layer. So really your tables will be called
Order,Topping, etc if you are making software for pizza shops whil it will haveAccount,Transactionif you are developing software for a bank. So business logic is everywhere, in the middle tier as well as in the UI or database.So now while layered architecture is still accepted as a good architectural approach (which has a middle layer which is not called "business layer" anymore), N-Tier is not.
在面向对象的应用程序中，我喜欢将业务层视为应用于对象的业务规则、流程或工作流。然而，在很多情况下，我认为这意味着对象只不过是 POCO（C# 中的普通旧 C# 对象、Java 中的 POJO 等）。这样做的问题是对象的行为与对象分离并转移到任意的“业务逻辑”类中。
我个人的信念是“业务层”应该作用于对象，而不是取代对象的行为。这还允许更好地实现其他实践，例如使用继承和多态性的开闭原则。
考虑这个例子 "OCP" 其中 Area 类是“业务层”，但各种 Shape 对象包含每种形状类型的行为逻辑。这样，区号很少（如果有的话）需要更改。
In an OO application I like to think of the business layer as business rules, processes or workflows that are applied to the objects. However in many cases I have seen this to mean that the objects become nothing but POCO's (Plain Old C# Objects in C#, POJO's in Java etc). The problem with this is that the object's behaviour becomes detached from the object and moved into arbitrary "Business Logic" classes.
My personal belief is that the "Business Layer" should act upon objects but not replace object an object's behaviour. This also allows for better implementation of other practices such as Open Closed Principle using inheritance and polymorphism.
Consider this example "OCP" where the Area class would be the "Business Layer" but the various Shape objects contain the behaviour logic for each type of shape. This way the Area code rarely, if at all needs to change.