我知道这听起来可能很愚蠢，但我发现很难理解服务层的需求及其与业务层的区别。
因此，我们使用 asp.net mvc 2 并拥有数据访问层，它对数据库进行所有查询，然后我们拥有业务层，它具有需要完成的业务逻辑和验证。最后，我们有了基本上拥有所有视图的表示层。此外，作为我们库的一部分，我们还在不同的文件夹中提供了一些帮助程序、DTO 和视图模型类。但是我尝试阅读有关架构的内容，并且似乎服务层是架构的重要组成部分。
我所理解的是，服务层是调用所有功能的东西。但是我真的看不到我们的应用程序需要服务层吗？或者它可能已经存在并且我看不到它......任何人都可以用一个例子来解释服务层的重要性吗？它与业务层有何不同，因为从我所读到的内容看起来非常相似？如果它是第一个需要的？我们要做的就是以最好的方式构建我们的应用程序，您对此有何想法和经验？
这一切都是关于将您的应用程序解耦成独立的部分，每个部分都由真正做好一项工作的要求定义。
这允许您将专门的设计模式和最佳实践应用于每个组件。
例如，业务层的工作就是实现业务逻辑。句号。公开设计为由表示层使用的 API 不是它的“关注点”。
中间的这个角色最好由服务层来执行。分解出这个专门的层允许您将更专门的模式应用于每个单独的组件。
没有必要以这种方式进行设计，但社区积累的经验表明，它使应用程序更易于开发和维护，因为您甚至在开始编码之前就确切知道每个组件的预期用途应用程序。
每一层都应该很好地完成一项工作。服务层执行的 go between 的角色是一项定义明确的工作，这就是它存在的原因：它是一个复杂性单元，以相同的方式一遍又一遍地设计，而不必重新发明轮子每次，都用不属于它的业务逻辑来破坏这个角色。将服务层视为一个映射组件。它在业务逻辑之外，不属于它的类，也不属于控制器。
此外，由于从业务逻辑中分离出来，您可以获得更简单的业务对象，这些对象更容易被“业务”使用的其他应用程序和服务使用。
如果不是一个使您能够将应用程序编写为专用组件的平台，那么 ASP.NET MVC 就什么也不是。
由于对如何专业化组件的理解越来越多，程序正在从一碗原始的汤和意大利面演变成不同而奇怪的东西。他们可以解决的复杂性，同时仍然使用简单的结构，正在增加。进化正在进行中。如果生活是要过的，这一定是好的，所以继续前进。
你可能会觉得建筑宇航员这个词很有趣。
关键是，不要陷入人们喋喋不休的所有这些“层次”中。每当您在应用程序中添加另一层时，它就必须有一个目的。
例如，有些人成功地将数据访问和业务逻辑层的概念合二为一。它并不适用于所有解决方案，但它适用于许多解决方案。有些人甚至可能将演示与业务结合起来......这在很多圈子中是一个主要的禁忌，但同样，它可能非常适合所讨论的需求。
基本上，您要解决的问题应该决定应用程序的结构。如果其他应用程序需要与您的集成，则可能需要添加服务层。这可能采用简单的 Web 表单的形式，其他人可以将数据发布到该表单，或者它可能会进一步完善 Web 服务。甚至在某些情况下，您希望服务层成为多个演示文稿的主要访问位置。
你可以随心所欲地复杂化，但一个好的经验法则是保持简单，直到复杂化变得必要。
在某些设计中，表示层不使用服务层。
服务层由想要使用应用程序中的业务和数据访问层的其他应用程序调用。
在某种程度上，服务层是与表示层分离的另一个前端。
请参阅此处的架构图。用户通过表示层访问应用程序。外部系统通过服务层访问应用程序。表示层和服务层与业务层中的应用程序外观对话。
作为其他“外部系统”的示例，Web 服务和 WCF 服务称为服务层。其他一些 Web 应用程序可以在 Web 服务调用中调用此应用程序的服务层。这将是确保两个应用程序应用相同业务逻辑的一种方法，并且对业务逻辑所做的任何更改都会反映在两个应用程序中。
正如 Chris Lively 所指出的，人们不应该因创建图层而得意忘形。我建议只创建对您的应用程序有用的层。根据我的经验，对服务层的需求并不频繁，但对业务层的需求却非常频繁。
服务层通常是根据客户端必须支持的离散操作来构建的。
例如，服务层可能会公开创建帐户。而业务层可能包括验证创建帐户所需的参数、构建要持久化的数据对象等。
通常，服务层使用过程或事务脚本样式代码来编排业务和/或逻辑层。
知道了这一点，您可能会意识到您的业务层实际上也是一个服务层。在某些时候，您提出这个问题的点就是这样一个点，区别主要是语义上的。
从我的角度来看，服务层允许您将表示层与业务层隔离开来，就像业务和数据访问层将您与持久化数据的方式隔离开一样。
在您的业务层中，您将放置对您的“业务”至关重要的东西。一个人为的（可能是构思不佳的例子）是让那个地方成为产品折扣价格发生的地方。
服务层允许您将接口与业务进一步分离。甚至可以根据业务场景的变化换掉其他业务层。
虽然不是每个应用程序都需要一个（很多变量都会影响到该决定），过多的架构可能会引入您的团队可能不需要的复杂性。
看看 Randy Stafford 在“EAA 的 P”一书中对服务层的评价 http://martinfowler.com/eaaCatalog/serviceLayer.html
服务层从连接客户端层的角度定义了应用程序的边界 [Cockburn PloP] 及其可用操作集。它封装了应用程序的业务逻辑、控制事务并在其操作的实现中协调响应。
简单的。要将您的业务逻辑公开给客户端，请使用服务层。问你自己：
在改变业务逻辑时，服务层是否应该改变？如果答案是“不总是”，那么需要一个服务层。
我知道这个线程很旧，但我在服务层中做的一件有用的事情是处理事务（业务层不需要知道如何处理回滚、操作排序等）。
我做过的另一件事是用它在域实体和 DTO 之间进行转换。业务层处理领域模型，但我以 DTO 的形式将数据传回表示层（在某些情况下，由于各种原因，将整个领域模型暴露给表示层是不切实际的），所以服务层处理这个映射。
最终，我认为业务层更细粒度，而服务层可以更粗略，因为它可以调用 BLL 中的多个操作，并在一个服务调用中对调用进行排序。
是的，我还要指出，服务层是进行身份验证的好地方，无论是基于角色还是基于用户。