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

Question

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

因此，我们使用asp.net mvc 2并拥有数据访问层，它可以对数据库进行所有查询，然后我们拥有业务层，其中包含需要完成的业务逻辑和验证。最后我们有Presentation Layer，基本上有所有的视图。此外，我们还在不同的文件夹中有一些帮助程序，DTO和viewmodel类作为我们库的一部分。但我试图阅读有关架构的内容，而服务层似乎是架构的重要组成部分。

我所理解的是服务层是调用所有功能的东西。 但我真的不能在我们的应用程序中看到Service层的需要吗？或者它可能已经存在并且我看不到它......任何人都可以用一个例子解释一个服务层是如何重要的？它与业务层有什么不同，因为从我读过的内容看起来非常相似？ 如果它在第一个需要的话？我们所要做的就是以最佳方式构建我们的应用程序您对它的想法和经验是什么？

Answer 1

所有这些都是关于将您的应用程序拆分为自包含的部分，每个部分都由执行一项工作的要求定义。

这允许您将专门的设计模式和最佳实践应用于每个组件。

例如，业务层的工作是实现业务逻辑。完全停止。公开设计为由表示层使用的API并不是它的“关注点”。

这种角色最好由服务层执行。考虑到这个专门的层可以让你为每个单独的组件应用更专业的模式。

没有必要以这种方式进行设计，但是社区积累的经验表明它会导致应用程序更容易开发和维护，因为您确切知道每个组件应该做什么，甚至在之前你开始编写应用程序。

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

此外，由于从业务逻辑中分解出来，您可以获得更容易被“业务”消耗的其他应用程序和服务使用的更简单的业务对象。

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

由于对如何专注于组件的这种日益增长的理解，程序正在从原始的一碗汤和意大利面变成不同和奇怪的东西。他们可以解决的复杂性，同时仍然使用简单的结构，正在增加。进化正在发展。如果生活是可以接受的，那就必须是好的，所以保持球的滚动。

Answer 2

您可能会发现Architecture Astronaut这个词很有趣。

重点是，不要陷入人们所痴迷的所有这些“层”中。每当你有一个应用程序的另一层时，就必须有一个目的。

例如，有些人成功地将数据访问和业务逻辑层的概念合二为一。它并不适用于所有解决方案，但它对很多解决方案来说都很完美。有些人甚至可能将演示与商业相结合......这在很多圈子中都是一个重要的不，但同样，对于有关需求可能是完美的。

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

你可以随心所欲地复杂化，但一个好的经验法则是保持简单直到 并发症是必要的。

Answer 3

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

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

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

请在此处查看architectural diagram。用户通过表示层访问应用程序。外部系统通过服务层访问应用程序。表示层和服务层与业务层中的应用程序外观进行通信。

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

正如Chris Lively所指出的那样，人们不应该因为创建图层而感到厌烦。我建议只创建在您的应用程序中有用的图层。根据我的经验，对服务层的需求并不频繁，但是对业务层的需求非常频繁。

Answer 4

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

例如，服务层可能会公开创建帐户。而业务层可能包括验证创建帐户所需的参数，构建要保留的数据对象等。

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

了解这一点，您可能会意识到您的业务层确实也是服务层。在某些时候，你提出这个问题就是这样一个观点，这种区别主要是语义上的。

Answer 5

从我的角度来看，服务层允许您将表示层与业务层隔离开来，就像业务和数据访问层将您与数据持久化隔离的方式相同。

在您的业务层中，您可以放置​​对您的“业务”至关重要的内容。一个人为的（可能是构思不佳的例子）就是让产品价格折扣的地方。

服务层允许您进一步从业务中分离界面。甚至可以根据业务变化情况换掉其他业务层。

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

Answer 6

在“PA EAA”一书中看看兰迪斯塔福德关于服务层的内容 http://martinfowler.com/eaaCatalog/serviceLayer.html

  

服务层定义了一个   应用程序的边界[Cockburn PloP]   及其可用的操作集   从接口的角度来看   客户层。 它封装了   应用程序的业务逻辑，   控制交易和   协调反应   执行其业务。

Answer 7

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

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

Answer 8

我知道这个线程已经过时了，但我在Service层中做的一件有用的事情就是处理事务（Business Layer不需要知道如何处理回滚，操作的顺序等等）。

我做过的另一件事是用它在域实体和DTO之间进行转换。业务层处理域模型，但我已经以DTO的形式将数据传递回表示层（在某些情况下，由于各种原因将整个域模型暴露给表示层是不切实际的），所以服务层处理这个映射。

最终，我认为业务层更细粒度，而服务层可能更粗糙，因为它可以在BLL中调用多个操作，并在一个服务调用中命令调用。

Answer 9

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