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

Question

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

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

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

Answer 1

这完全是关于将您的应用程序分离为自包含的部分,每个部分都由要求完成一项工作确定.

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

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

这种角色最好由服务层执行.通过考虑这个专用层,您可以将更多专用模式应用于每个单独的组件.

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

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

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

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

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

Answer 2

您可能会发现建筑宇航员这个术语很有趣.

关键是,不要陷入人们所说的所有这些"层"中.每当你有一个应用程序的另一层,就必须有一个目的.

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

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

你可以随心所欲地复杂化,但一个好的经验法则是保持简单直到需要复杂化.

Answer 3

在某些设计中,表示层不使用服务层.

服务层由希望在应用程序中使用业务和数据访问层的其他应用程序调用.

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

请参阅此处的架构图.用户通过表示层访问应用程序.外部系统通过服务层访问应用程序.表示层和服务层与业务层中的应用程序外观进行通信.

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

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

Answer 4

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

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

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

了解这一点,您可能会发现您的业务层确实也是一个服务层.在某些时候,你要求这个问题就是这样一个点,这种区别主要是语义上的.

Answer 5

从我的角度来看,服务层允许您将表示层与业务层隔离开来,就像业务和数据访问层将您与数据持久性隔离开来一样.

在您的业务层中,您可以放置​​对您的"业务"至关重要的内容.一个人为的(也可能是构思不佳的例子)就是让产品价格折扣的地方.

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

并非每个应用程序都需要一个(很多变量都会进入该决定),过多的架构可能会引入您的团队可能不需要的复杂性.