服务和门面的角色是否相似?

82
我读得越多,就越感到困惑。
请注意,所有问题都与服务和门面在MVC模式中的适用方式有关。
我的理解是,门面不是一个超级智能的对象,它只是一种暴露简单接口/ API 以执行复杂操作的方法(例如:执行10美元的付款,这是涉及多个操作的复杂操作,但此类复杂性可以通过门面来处理,门面将按特定顺序调用相应的对象等)。
现在,服务是一种执行对多个DAO的调用以获取复杂数据结构的方法(我还不太确定,但这是我目前所理解的)。
问题是,门面和服务之间有什么区别?最终,门面完全可以通过提供简单接口访问多个DAO以执行复杂操作,并且服务似乎也可以做类似的事情。
同样发生在事务中,我了解到服务是启动事务的地方,但我同样觉得它们也可以放置在门面上,毕竟,门面也可能调用多个DAO。
那么哪个堆栈更有意义?
控制器-门面-数据访问对象 控制器-服务-数据访问对象
或者可能是
控制器-门面-数据访问对象,有时候是控制器-门面-服务-数据访问对象?

Façade通常应用于业务,可以制作您的应用程序API。数据服务只是您的服务。除此之外,您还可以在代码中的许多地方使用Façade。以此来制作SAL。因此,它成为了服务访问API。Façade是一种模式,可以制作API。 - Davut Gürbüz
4
Facade 和 Service 的主要区别在于,Service 实际上会执行某些操作,即类定义实际包含了执行某些逻辑的管道。在我看来,一个干净的 Facade 不应该持有任何逻辑,除了必要的委托实际工作给下一个 Service 的逻辑之外。 - kolossus
通过使用控制器 DAO,您不必将请求处理与逻辑分开。通常使用 Facade 将 DTO 对象转换为实体,并使用 DAO 持久化数据。因此,DAO 类与 DTO 对象解耦,控制器与实体解耦。同时,业务逻辑在 Facade 中执行,该 Facade 具有单一职责。因此,控制器 - Facade - DAO 是必须的,也可以使用服务。 - USer22999299
11个回答

0

Facade服务层有一定的相似之处,但它们都有两个不同的含义。让我用一个简单的例子来解释。

假设我们被要求创建一个新的业务应用程序。这需要创建一个签到应用程序,但具有更多的增值功能和会员卡功能。

假设应用程序应支持Facebook和Foursquare签到功能,如果用户希望使用。这个功能是非常必要的,因为一些用户不愿意使用几个执行相同功能的应用程序或者想要摆脱社交连接。

要了解高层次的想法,请参考以下链接中的示例API https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing

上面的签到API位于ABC Facade,是Facade使用的一个示例。

它具有我们的服务API,还基于客户选择具有Facebook和Foursquare签到功能。 Facebook和Foursquare API可以具有特定的实现(SOAP,Restful等)和安全(OAuth等)要求等。

满足这些API(Facebook,Foursquare)的要求需要完成不同的任务集。这些将是我们签到需求中的不同子系统。

因此,facade的简单使用是满足由一个简单方法触发的几个子系统

但是,如果我们考虑自己的API,即位于MngCheckinSvc的签到API。这是一个服务层API。这是包含我们应用程序签到要求的API。这是提供公共访问的API,从您的MngCheckinSvc处理应用程序的签到要求。

这将具有复杂的内部行为,但仍然大多数将是应用程序特定逻辑实现。

此API(MngCheckinSvc.checkin(....))可能访问不同的DAO,内部API,可能是其他内部服务等,以便在应用程序中完成商家签到。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接