构建 Web 应用程序时服务层与业务层？
我知道这可能听起来很愚蠢，但我发现很难理解服务层的需求及其与业务层的差异。
因此，我们使用 asp.net mvc 2 并拥有数据访问层，该层负责对数据库进行所有查询，然后我们拥有业务层，其中包含需要完成的业务逻辑和验证。最后我们有表示层，它基本上包含所有视图。此外，我们还在不同的文件夹中提供了一些帮助程序、DTO 和视图模型类，作为我们库的一部分。但我尝试阅读有关架构的内容，似乎服务层是架构的重要组成部分。
我所理解的是服务层是调用所有功能的东西。 但我真的看不出我们的应用程序中需要服务层吗？或者它可能已经在那里，但我看不到它......任何人都可以用示例解释服务层的重要性吗？它与业务层有何不同，因为从我读到的内容来看，它看起来非常相似？ 如果它是第一个需要的？我们所做的就是以尽可能最好的方式构建我们的应用程序，您对此有何想法和经验？
I know this might sound silly but I am finding it hard to understand the need of a service layer and its differences with business layer.
So, we are using asp.net mvc 2 and have Data Access layer which does all the querying with the database and then we have the Business Layer which has the business logic and validations needed to be done. Finally we have the Presentation Layer which basically has all the views. In addition we also have some helpers,DTOs and viewmodel classes in different folders as a part of our libraries. But I have tried to read about architecture and it seems that service layer is an important part of an architecture.
All I understand is that a service layer is something that calls all the functions.
But I can't really see the need of Service layer in our application ? Or it might be already there and I can't see it... Can anyone explain with an example how a service layer is important ? How it is different from a business layer because from what I have read seem pretty similar?
If its in the first needed at all ? All we trying to do is architect our application in the best possible way what are your thoughts and experience on it ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
这一切都是为了将您的应用程序解耦为独立的部分，每个部分都是根据真正做好一项工作的要求来定义的。
这使您可以将专门的设计模式和最佳实践应用于每个组件。
例如，业务层的工作就是实现业务逻辑。句号。公开设计供表示层使用的 API 并不是它的“关注点”。
这个中间人的角色最好由服务层来扮演。分解出这个专门的层可以让您将更专门的模式应用于每个单独的组件。
没有必要以这种方式进行设计，但社区积累的经验表明，它会导致应用程序更容易开发和维护，因为您甚至在开始编码之前就知道每个组件的预期用途该应用程序。
每一层都应该很好地完成一项工作。服务层执行的协调角色就是一项明确定义的工作，这就是它存在的原因：它是一个复杂的单元，以相同的方式一遍又一遍地设计，而不是重新发明轮子每次，都会用不属于该角色的业务逻辑来破坏该角色。将服务层视为映射组件。它位于业务逻辑外部，不属于其类，也不属于控制器。
此外，由于从业务逻辑中提取出来，您可以获得更简单的业务对象，这些对象更容易被“业务”使用的其他应用程序和服务使用。
ASP.NET MVC 如果不是一个使您能够将应用程序编写为专用组件的平台，那么它就毫无意义。
由于对如何专门化组件的理解不断加深，程序正在从一碗原始的汤和意大利面演变为不同且奇怪的东西。他们在仍然使用简单结构的同时可以解决的复杂性正在增加。进化正在发生。如果生活有什么可看的，那就一定是美好的，所以继续前进吧。
It is all about decoupling your app into self contained pieces, each one defined by the requirement to do one job really well.
This allows you to apply specialised design patterns and best practices to each component.
For example, the business layer's job is to implement the business logic. Full stop. Exposing an API designed to be consumed by the presentation layer is not its "concern".
This role of the go between is best performed by a service layer. Factoring out this specialised layer allows you to apply much more specialised patterns to each individual component.
There is no need to do design things this way, but the accumulated experience of the community indicates that it results in an application that is much easier to develop and maintain because you know exactly what each component is expected to do, even before you start coding the app.
Each layer should do one job really well. The role of go between that the service layer performs is one such well defined job and that is the reason for its existence: it is a unit of complexity that is designed in the same way over and over again, rather than having to reinvent the wheel each time, to mangle this role with the business logic where it does not belong. Think of the service layer as a mapping component. It is external to the business logic and does not belong in its classes, or in the controllers either.
Also, as a result of being factored out of the business logic, you get simpler business objects that are easier to use by other applications and services that the "business" consumes.
ASP.NET MVC is nothing if not a platform to enable you to write your apps as specialised components.
As a result of this increasing understanding of how to specialise components, programs are evolving from a primordial bowl of soup and spaghetti into something different and strange. The complexity they can address, whilst still using simple structures, is increasing. Evolution is getting going. If life is anything to go by, this has to be good, so keep the ball rolling.
在某些设计中，表示层不使用服务层。
服务层由想要使用应用程序中的业务和数据访问层的其他应用程序调用。
在某种程度上，服务层是与表示层分离的另一个前端。
请参阅此处的架构图。用户通过表示层访问应用程序。外部系统通过服务层访问应用程序。表示层和服务层与业务层中的应用程序外观进行通信。
作为其他“外部系统”的示例，Web 服务和 WCF 服务称为服务层。某些其他 Web 应用程序可以在 Web 服务调用中调用此应用程序的服务层。这是确保两个应用程序应用相同业务逻辑并且对业务逻辑所做的任何更改都会反映在两个应用程序中的一种方法。
正如克里斯·莱弗利 (Chris Lively) 指出的那样，人们不应该沉迷于创建图层。我建议只创建对您的应用程序有用的层。根据我的经验，对服务层的需求并不频繁，但对业务层的需求却非常频繁。
In some designs, the service layer is not used by the presentation layer.
The service layer is called by other applications that want to use the business and data access layers in the application.
In a way, the service layer is another front-end separate from the presentation layer.
See the architectural diagram here. The users access the application through the presentation layer. And the external systems access the application through the services layer. The presentation layer and the services layer talk to the application facade in the business layer.
As an example of what those other "external systems" might be, web services and WCF services call the service layer. Some other web application could call this application's service layer in a web service call. This would be one way to ensure that both apps are applying the same business logic, and that any changes made to the business logic are reflected in both of the apps.
As Chris Lively points out, one shouldn't get carried away with creating layers. I would recommend only creating the layers that would be useful in your application. In my experience, the need for a service layer is not frequent, but the need for a business layer is very frequent.
您可能会发现术语建筑宇航员很有趣。
重点是，不要陷入人们胡思乱想的所有这些“层次”中。每次您为应用程序添加另一层时，它都必须有一个目的。
例如，有些人成功地将数据访问层和业务逻辑层的概念合二为一。它并不适合所有解决方案，但它对于许多解决方案来说都非常有效。有些人甚至可能将演示与业务结合起来……这在很多圈子里是一个主要禁忌，但同样，可能非常适合所讨论的需求。
基本上，您要解决的问题应该决定应用程序的结构。如果其他应用程序需要与您的应用程序集成，则可能需要添加服务层。这可能采用简单的网络表单的形式，其他人可以将数据发布到其中，或者可能进一步完善网络服务。在某些情况下，您甚至可能希望服务层成为多个演示的主要访问位置。
您可以根据需要变得复杂，但一个好的经验法则是保持简单，直到
并发症变得必要。
You might find the term Architecture Astronaut interesting.
The point is, don't get caught up in all of these "layers" that people bandy about. Every time you had another layer to the application, there has to be a purpose in it.
For example, some people successfully combine the concepts of a Data Access and Business Logic layer into one. It's not right for every solution, but it works out perfectly for a lot of them. Some people might even combine Presentation with Business... which is a major no no in a lot of circles but, again, may be perfect for the need in question.
Basically, the problem you are solving should dictate the structure of the application. If other applications need to integrate with yours, then a Service Layer may need to be added. This might take the form of simple web forms which others can post data to or it might go further to be full on web services. There might even be situations where you want the service layer to be the primary go to location for multiple presentations.
You can get as complicated as you want, but a good rule of thumb is to keep it simple until
the complications become necessary.
服务层通常是根据客户端必须支持的离散操作来构建的。
例如，服务层可以公开创建帐户。而业务层可能包括验证创建帐户所需的参数、构建要持久保存的数据对象等。
服务层通常使用过程或事务脚本样式代码来编排业务和/或逻辑层。
了解了这一点，您可能会意识到您的业务层实际上也是服务层。在某些时候，从你提出这个问题的角度就是这样一个角度，这种区别主要是语义上的。
The Service Layer is usually constructed in terms of discrete operations that have to be supported for a client.
For example, a Service Layer may expose Creating an Account. Whereas the Business Layer may consist of validating the parameters needed in creating an account, constructing data objects to be persisted, etc.
Oftentimes, the Service Layer uses a procedural or Transaction Script style code to orchestrate the business and/or logic layers.
Knowing this, you may realize that your Business Layer really is a Service Layer as well. At some point, the point from which you're asking this question being one such point, the distinction is mostly semantic.
从我的角度来看，服务层允许您将表示层与业务层隔离，就像业务和数据访问层将您与数据的持久化方式隔离一样。
在您的业务层中，您可以放置对您的“业务”至关重要的内容。一个人为的（可能是构思不佳的例子）是让那里成为产品打折的地方。
服务层可以让你将接口和业务进一步分离。甚至根据业务场景的变化更换其他业务层。
不过，并不是每个应用程序都需要一个（这一决定涉及很多变量），太多的架构可能会带来团队可能不需要的复杂性。
From my perspective a service layer allows you to isolate your presentation layer from your business layer, in the same way the business and data access layer isolates you from how you persist the data.
Inside your business layer you'd put things that are pivotal to your 'business'. A contrived (and probably poorly conceived example) would be to have that be the place where say discounting prices on a product occur.
The service layer allows you to further seperate the interface from the business. Or even swap out other business layers depending on the changing scenarios of the business.
Not every application needs one though (a lot of variables go into that determination), too much architecture can introduce complexities your team may not need.
看看 Randy Stafford 在“P of EAA”一书中关于服务层的说法
http://martinfowler.com/eaaCatalog/serviceLayer.html
Have a look to what Randy Stafford says about Service Layer in the "P of EAA" Book
http://martinfowler.com/eaaCatalog/serviceLayer.html
简单的。要将业务逻辑公开给客户端，请使用服务层。
问问自己：
当改变业务逻辑时，服务层是否应该改变？
如果答案是“并不总是”，那么就需要服务层。
Simple. To expose your business logic to a client, use a service layer.
Ask yourself:
When changing the business logic, should the service layer change?
If the answer is "not always" then a service layer is needed.
我知道这个线程很旧，但是我在服务层中所做的一件有用的事情是处理事务（业务层不需要知道如何处理回滚、操作顺序等）。
我所做的另一件事是使用它在域实体和 DTO 之间进行转换。业务层处理域模型，但我已经以 DTO 的形式将数据传递回表示层（在某些情况下，由于各种原因将整个域模型暴露给表示层是不切实际的），所以服务层处理这个映射。
最终，我认为业务层更细粒度，而服务层可以更粗粒度，因为它可以调用 BLL 中的多个操作，并在一个服务调用中排序调用。
I know this thread is old, but one useful thing I've done in the Service layer is to handle transactions (Business Layer shouldn't need to know how to handle rollbacks, ordering of operations, etc.).
Another thing I've done is used it to translate between domain entities and DTOs. The Business layer deals with the domain model, but I've passed the data back to the presentation layer in the form of DTOs (in some cases it wasn't practical to expose the whole domain model to the presentation layer for various reasons), so the service layer handles this mapping.
Ultimately, I see the business layer as more fine grained, whereas the Service layer can be more coarse in that it could call multiple operations in the BLL, and order calls within one service call.
是的，我还要指出的是，服务层是基于角色和基于用户的身份验证的好地方。
Yes, and I would also note on that the service layer is a good place for authentication, both role based and user based.