在架构Web应用程序中，服务层与业务层？

Question

我知道这听起来可能很愚蠢，但我发现很难理解服务层的需求及其在业务层中的差异。

因此，我们使用的是ASP.NET MVC 2，并具有数据访问层，该数据访问层与数据库一起进行所有查询，然后我们拥有具有业务逻辑和验证的业务层。最后，我们有基本上具有所有视图的演示层。此外，作为我们的库的一部分，我们还在不同文件夹中有一些帮助者，DTO和ViewModel类。但是我试图阅读有关架构的信息，似乎服务层是架构的重要组成部分。

我只知道服务层是调用所有功能的东西。但是我真的看不到我们的应用程序中的服务层吗？否则它可能已经存在了，我看不到它...有人可以用一个示例解释服务层的重要性吗？它与业务层有何不同，因为从我的阅读中看，它看起来很相似？如果它完全需要吗？我们要做的就是以最佳方式架构我们的应用程序，您对此有何想法和经验？

Answer 1

这都是将您的应用程序解耦为自包包的部分，每个应用程序都由完成一项工作的要求定义。

这使您可以在每个组件上应用专门的设计模式和最佳实践。

例如，业务层的工作是实施业务逻辑。全停止。暴露旨在由演示层消耗的API并不是其“关注”。

两者之间的这种角色最好由服务层执行。分解这个专业层，您可以在每个组件上应用更多的专业模式。

无需以这种方式设计事情，但是社区的累积经验表明，它导致应用程序更容易开发和维护，因为您确切地知道每个组件的期望，甚至在开始编码之前应用。

每一层都应该做得很好。在服务层执行的角色之间的作用是如此明确的工作，这就是其存在的原因：它是一个复杂性的单位，以相同的方式进行设计，而不是必须重新发明轮子每次，都以不属于业务的业务逻辑来处理这个角色。将服务层视为映射组件。它是业务逻辑外部的，也不属于其类别，也不属于控制器。

同样，由于从业务逻辑中算出，您会获得更简单的业务对象，这些对象易于使用“业务”消耗的其他应用程序和服务使用。

ASP.NET MVC即使不是一个平台，可以使您能够将应用程序编写为专业组件。

由于对如何专业组件的越来越多的了解，程序正在从原始的汤和意大利面演变为不同和奇怪的东西。他们可以解决的复杂性，同时仍在使用简单的结构正在增加。进化正在前进。如果生命要经历，这一定是好的，所以请保持球的滚动。

Answer 2

您可能会发现该术语 建筑宇航员 有趣的。

关键是，不要陷入人们束缚的所有这些“层”中。每当您有另一层的应用程序时，它都必须有一个目的。

例如，有些人成功将数据访问和业务逻辑层的概念结合到一个概念中。它不是适合每个解决方案的正确，但是它对许多解决方案都非常适合。有些人甚至可能将演示文稿与业务相结合……这是许多圈子中的主要否，但是，同样，对于所讨论的需求可能是完美的。

基本上，您要解决的问题应决定应用程序的结构。如果其他应用程序需要与您的应用程序集成，则可能需要添加服务层。这可能会采用其他人可以将数据发布到的简单Web表单的形式，或者可能会在Web服务上更加完整。甚至在某些情况下，您希望服务层成为主要演示文稿的主要位置。

您可以根据需要变得复杂，但是一个好的经验法则是保持简单，直到并发症变得必要。

Answer 3

在某些设计中，演示层不使用服务层。

服务层是由想要在应用程序中使用业务和数据访问层的其他应用程序调用的。

在某种程度上，服务层是与演示层分开的另一个前端。

看到 建筑图 这里。用户通过演示层访问应用程序。外部系统通过服务层访问应用程序。演示层和服务层与业务层中的应用程序外墙进行对话。

作为其他“外部系统”可能是什么，Web服务和WCF服务调用服务层。其他一些Web应用程序可以在Web服务调用中调用此应用程序的服务层。这将是确保两个应用程序都应用相同业务逻辑的一种方法，并且对业务逻辑进行的任何更改都反映在两个应用程序中。

正如克里斯·莱弗利（Chris Lively）指出的那样，人们不应将创建层带来。我建议仅创建对您的应用程序有用的层。根据我的经验，对服务层的需求并不频繁，但是对业务层的需求非常频繁。

Answer 4

服务层通常是根据必须支持客户的离散操作来构建的。

例如，服务层可以公开创建帐户。尽管业务层可能包括验证创建帐户所需的参数，构造要持续存在的数据对象，等等。

通常，服务层使用程序或事务脚本样式代码来协调业务和/或逻辑层。

知道这一点，您可能会意识到 您的 业务层 真的是 服务层也是如此。在某个时候，您要问这个问题的一点是这样的一点，区别主要是语义。

Answer 5

从我的角度来看，服务层使您可以从业务层中隔离演示层，就像业务和数据访问层相同的方式将您从持久数据的方式中隔离开来。

在您的业务层内，您会将其放置在您的“业务”中至关重要的东西。一个人为的（可能构想的例子很差）是将其说是出现产品折现价格的地方。

该服务层使您可以进一步将界面与业务分开。甚至取决于业务不断变化的情况，甚至交换其他业务层。

不过，并非每个应用程序都需要一个应用程序（该确定的许多变量），太多的体系结构可能会引入您的团队可能不需要的复杂性。

Answer 6

看看兰迪·斯塔福德（Randy Stafford）在“ eaa”书中对服务层的看法http://martinfowler.com/eaacatalog/servicelayer.html

服务层从接口客户层的角度来定义应用程序的边界[Cockburn Plop]及其一组可用操作。 它封装了应用程序的业务逻辑，在实施其运营时控制交易和调整响应。

Answer 7

简单的。要将您的业务逻辑公开到客户端，请使用服务层。问你自己：

在更改业务逻辑时，服务层是否应该更改？如果答案“并非总是”，则需要服务层。

Answer 8

我知道这个线程是旧的，但是我在服务层中所做的一件有用的事情是处理交易（业务层不需要知道如何处理回滚，操作订购等）。

我完成的另一件事是将其用于在域实体和DTO之间翻译。业务层涉及域模型，但是我以DTO的形式将数据传递回了演示层（在某些情况下，出于各种原因将整个域模型公开到演示层不切实际），因此，服务层处理此映射。

最终，我认为业务层更加细粒子，而服务层可能更粗糙，因为它可以在BLL中调用多个操作，并且在一个服务调用中订购了调用。

Answer 9

是的，我还要注意，服务层是基于角色和用户基于角色的身份验证的好地方。