服务层与商业层架构的Web应用程序？
我知道这可能听起来很愚蠢，但我发现很难理解服务层的需求及其与业务层的差异。
所以，我们使用的是asp.net mvc 2，并且有数据访问层，它可以完成数据库的全部查询，然后我们有业务层需要完成业务逻辑和validation。 最后我们有了基本上具有所有视图的表示层。 另外我们也有一些帮助器，DTO和viewmodel类作为我们库的一部分放在不同的文件夹中。 但是我已经尝试了解架构，看起来服务层是架构的重要组成部分。
我所知道的是服务层是调用所有function的东西。 但是我真的不能在我们的应用程序中看到服务层的需求吗？ 或者它可能已经在那里，我不能看到它…任何人都可以解释一个例子如何服务层是重要的？ 它与业务层有什么不同，因为从我看过的东西看起来很相似？ 如果它在第一需要呢？ 我们所要做的就是以最好的方式构build我们的应用程序，您的想法和经验是什么？
这完全是关于把你的应用程序分解成自包含的部分，每个部分都由要求做得很好的需求来定义。
这使您可以将专门的devise模式和最佳实践应用于每个组件。
例如，业务层的工作是实现业务逻辑。 句号 暴露一个旨在被表示层使用的API不是它的“关注”。
走之间的angular色最好由服务层来执行。 分解这个专门化的层让您可以将更多的专业模式应用到每个单独的组件。
没有必要用这种方式来devise事物，但是社区的积累经验表明，它导致了一个更容易开发和维护的应用程序，因为即使在开始编码之前，您也确切地知道每个组件都应该做什么该应用程序。
每一层都应该做得很好。 服务层之间的angular色是一个如此明确定义的工作，这就是它存在的原因：它是一个一次又一次以相同方式devise的复杂性单元，而不是重新发明轮子每次都要用它不属于的业务逻辑来强化这个angular色。 将服务层视为映射组件。 它是业务逻辑的外部，不属于它的类，也不属于控制器。
此外，由于被分解出业务逻辑，您将得到更简单的业务对象，这些业务对象更容易被“业务”消耗的其他应用程序和服务使用。
如果不是一个平台，ASP.NET MVC就没有什么特别的组件可以让你编写应用程序。
由于对如何专门化组件的认识不断增加，程序正在从原始的一碗汤和意大利面发展成为不同而奇怪的东西。 他们可以解决的复杂性，同时仍然使用简单的结构，正在增加。 进化正在发展。 如果生命中有任何事情要做，那就一定要好，所以保持球的滚动。
你可能会发现build筑宇航员这个词很有趣。
关键在于，不要陷入人们喋喋不休的“层面”。 每次你在应用程序中都有另外一层时，就必须有一个目的。
例如，一些人成功地将数据访问和业务逻辑层的概念合并为一个。 每个解决scheme都是不正确的，但是对于其中的很多解决scheme来说，它是完美的。 有些人甚至可能把演示和商业结合起来，这是很多圈子里的一个主stream，但是，对于有需要的人来说，也是完美的。
基本上，你正在解决的问题应该决定应用程序的结构。 如果其他应用程序需要与您的应用程序集成，则可能需要添加服务层。 这可能采取简单的Web表单的forms，其他人可以发布数据，或者可以进一步充分的在Web服务上。 甚至有些情况下，您希望服务层成为多个演示文稿的主要位置。
你可以像你想的那样复杂，但是一个好的经验法则是保持简单，直到并发症成为必要。
在某些devise中，表示层不使用服务层。
服务层由其他应用程序调用，这些应用程序要使用应用程序中的业务层和数据访问层。
从某种意义上说，服务层是与表示层分开的另一个前端。
请参阅此处的架构图 。 用户通过表示层访问应用程序。 外部系统通过服务层访问应用程序。 表示层和服务层与业务层中的应用程序外观交谈。
作为这些其他“外部系统”可能的例子，Web服务和WCF服务调用服务层。 其他一些Web应用程序可以在Web服务调用中调用此应用程序的服务层。 这将是确保两个应用程序都应用相同业务逻辑的一种方法，并且对业务逻辑所做的任何更改都会反映在这两个应用程序中。
正如Chris Lively所指出的那样，人们不应该为创build图层而感到厌倦。 我会build议只创build将在您的应用程序中有用的图层。 根据我的经验，对服务层的需求不是很频繁，但对业务层的需求非常频繁。
服务层通常是根据客户端必须支持的离散操作来构build的。
例如，服务层可能会公开创build帐户。 而业务层可能包括validation创build帐户所需的参数，构build要保留的数据对象等。
服务层通常使用过程式或事务式脚本样式代码来编排业务和/或逻辑层。
知道这一点，你可能会意识到你的业务层也是一个服务层。 在某个时候，你提出这个问题的重点就是这样一个问题，这个区别主要是语义的。
从我的angular度来看，服务层允许您将表示层与业务层隔离开来，就像业务层和数据访问层将您与持久化数据的隔离方式一样。
在你的业务层面，你会把关键的事情放在你的“业务”上。 一个人为的（也许构思不清的例子）就是让产品的折扣价格出现。
服务层允许您进一步分离业务接口。 甚至根据不断变化的业务情景交换其他业务层。
并不是每个应用程序都需要一个（很多variables都会影响到这个决定），但太多的架构可能会导致团队可能不需要的复杂性。
看看Randy Stafford在“EAA的书”中所说的服务层http://martinfowler.com/eaaCatalog/serviceLayer.html
服务层从接口客户层的angular度定义应用程序的边界[Cockburn PloP]及其可用操作集。 它封装了应用程序的业务逻辑 ，在执行操作时控制事务处理和协调响应。
简单。 要将您的业务逻辑公开给客户端，请使用服务层。 问你自己：
在改变业务逻辑时，服务层是否应该改变？ 如果答案是“不总是”，则需要服务层。
我知道这个线程是旧的，但我在服务层做的一件有用的事情是处理事务（业务层不需要知道如何处理回滚，操作的顺序等）。
我做的另一件事是用它来翻译域实体和DTO。 业务层处理领域模型，但是我已经以DTO的forms将数据传递回表示层（在某些情况下，出于各种原因将整个领域模型展示给表示层是不实际的），所以服务层处理这个映射。
最后，我认为业务层更加细化，而服务层可能更粗糙，因为它可以调用BLL中的多个操作，并在一个服务调用中进行调用。
是的，我也会注意到，服务层是一个authentication的好地方，既是基于angular色的，也是基于用户的。
