facade service 层有啥作用

Posted 2023-04-08

传统的J2EE系统的分层，一般是WEB展示层、Web控制层、业务逻辑层、数据访问层。
各层的职责比较简单，控制层仅处理Web参数与数据并传递给业务逻辑层。而具体的业务逻辑放在Service层即业务逻辑层中。同时，事务的控制边界也在这一层。Dao层对数据库的操作，更简单的理解为对SQL的拼装。
上面的各层泛泛来讲，都容易理解。具体用法上，又会有一些延伸。比如说Dao层，有的由一组Dao类来实现，有的则只有统一的Dao。这里的Dao类似一个工具类。比如使用ibatis2的时候，Dao可能只是一个Client及对应的xml。

问题:
在具体实施后，存在一些问题。往往一开始开发的时候，需求比较简单，各表都只需要增删改查。所以，往往类的创建往往是数据库导向的。即一张表对应一个Dao类/接口，进而又对应一个Service类/接口。
随着开发的继续，需求的补充，一些主业务表的Service往往贯穿整个业务系统的流程。自然而然，业务逻辑的代码开始膨胀。结果是主业务表的Service类异常的庞大。

因为领域模型是一个充血的模型，而目前传统的分层属于贫血的模型，转换差别比较大。如果是在原有的贫血模型基础上，再加入Facade层。
可是Facade层跟Service层到底有什么差别呢？如果没有严格的规则的话，最后只会导致Facade层是一个空壳。 参考技术A

使用Facade模式的是为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个外观（Facade）对象，它为子系统中较一般的设施提供了一个单一而简单的界面。将各个子系统整合起来作为Facade，提供给客户端使用。

适用情况：

当你要为一个复杂子系统提供一个简单接口时。

客户程序与抽象类的实现部分之间存在着很大的依赖性。

当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。仅通过facade进行通讯。

Facade 和 Gateway 设计模式有啥区别？

【中文标题】Facade 和 Gateway 设计模式有啥区别？

【英文标题】：What is the difference between Facade and Gateway design patterns?Facade 和 Gateway 设计模式有什么区别？

【发布时间】：2011-05-24 06:14:44

【问题描述】：

或外观==网关？

【问题讨论】：

你应该接受一个答案。 :)

我迟到了，但欢迎读者在下面评论我的回答。

【参考方案1】：

查看 GoF 书中的 Facade 和 Martin Fowler 的 Gateway 的另一个答案中的链接，看来他们的重点是相反的。

Facade 为（一个或多个）外部客户提供了复杂内部结构的简单统一视图；

Gateway 为应用程序内部提供了外部资源的简单统一视图。

这种区别让我们可以专注于设计中哪个更重要：

有了 Facade，外部系统就是我们的客户；如果它使外部接口更简单，最好增加面向内的复杂性。

有了网关，内部系统就是我们的客户；尽我们所能提供帮助，即使外部更复杂。

【讨论】：

这确实是一个重要的区别！感谢您以如此清晰的方式表达！

如果你可以通过简单的类/图表给我举个例子，我会为你的答案投票，Brian...

Facade Pattern 的问题是它不能本地化，只能应用于架构而不是应用程序。这会产生问题，因为任何时候必须在转发到应用程序的 URL INTERNAL 上检查安全性、方法或任何其他内容，它必须通过新请求通过外观返回并返回。同样的问题困扰着 api 门也是。然而，“API 抽象” (slideshare.net/bobdobbes/edit_my_uploads) 回答了这个问题

并且，如果是“内部”到内部？假设我们已经获得了复杂的数据结构，我们需要从该结构中提取数据？

【参考方案2】：

这两种模式非常相似，它们都充当了某些东西的包装器。区别在于上下文：外观代表一组子系统，而网关可以代表任何功能。从这个角度来看，对我来说 Facade 是 Gateway 的具体案例（而不是相反）。

当我们认为使用子系统很复杂或如果我们想将多个子系统调用组合到一个[方法]执行中时，就会应用外观。然而，这并不一定意味着子系统不可访问，或者它们足够复杂。它只是意味着我们拥有子系统。

当我们想要包装一些东西并将它们以不同的方式暴露时，就会应用网关。网关可能不是包装一个子系统，而只是一个相对复杂的功能。网关是一种通用模式，可以被认为是外观、代理和其他模式的基础。

如果仍需要举例说明：

Facade 可以通过查询支票账户子系统、信用账户子系统、储蓄子系统和后台子系统来计算客户的信用度（我想我在 GOF 书籍中看到过类似的例子）。

class MortgateFacade 
    bool IsCreditWorth(string customerName) 
        return !_checkingAccSystem.HasNegativeBalance(customerName) && !_creditAccSystem.HasNegativeCredit(customerName) && !_backOfficeSystem.IsInBlackList(customerName);
    

网关可以查询数据库表并通过ID返回客户。 （是的，就是这么简单！）

class CustomersGateway 
    Customer GetCustomer(int id) 
        return _db.ExecuteOne("SELECT TOP 1 FROM CUSTOMERS WHERE CUSTOMER_ID="+id).AsCustomer();
    

[显然这是一个伪代码]

【讨论】：

谢谢。 Facade 是网关的一个特定案例——我将进一步探讨这个想法。如果我还可以添加到网关点，网关用于将外部系统与我们的核心系统分离。它有助于以不同的方式表达外部 API，以便明天另一个 API 可以以最小的影响代替它。如果您同意或纠正，将对我有很大帮助。 ：） 再次感谢！让我在它到期之前给你那个赏金......

是的，Gateway 可用于将外部 API 转换为更方便的格式。但是，从理论上讲，不要将您对 Gateway 的理解局限于此。好吧，“网关”这个词本身告诉你，这只是通往某个地方的门[路]，或者是另一种看待事物的方式。是的，您将来可以替换网关实现，但这与网关模式完全无关。我将其称为 SOLID 原则中的“D”（依赖倒置）。将“包装器”称为网关并停止。现在，你完全正确！

【参考方案3】：

Facade 的意图由http://c2.com/cgi/wiki?FacadePattern as 给出

为集合提供统一的接口 子系统中的接口。正面 定义了一个更高级别的接口 使子系统更易于使用。 这可以用来简化数字 复杂的对象交互 到一个单一的界面。

这里的重点是设计一个隐藏复杂性的界面，我认为关键的想法是在一个更有用的交互中隐藏多个细粒度的交互。因此，Facade 的重点是面向客户的。

网关模式不是原始 GOF 模式之一，我更多地将其视为企业集成模式，即比门面更高的层次。见福勒的definition

我认为网关主要是关于隐藏技术复杂性而不是接口复杂性 - 隐藏连接到大型机和外部系统的细节。事实上，我经常期望网关成为某种请求路由器，甚至可能根据请求细节选择不同的后端系统。所以我认为 Gateway 专注于它的门户。

显然，非正式的网关是门面，因为它隐藏了细节，但我认为当您实现 GOF 门面和 Fowler 网关时，您最终会做完全不同的事情。

【讨论】：

坦率地说，这是这里唯一正确的答案。

【参考方案4】：

这是福勒书中的直接引述：

虽然 Facade 简化了更复杂的 API，但它通常由 通用服务的编写者。网关由 客户为其特定用途。此外，一个门面总是意味着一个 与它所覆盖的接口不同，而网关可能会复制 完全包裹的外观，用于替换或测试 目的。

[第十八章]

【讨论】：

正如 Fowler 在他的 PofEAA 书中所说。 “我必须承认，与引用现有模式（如 Facade）相比，是否将这个（网关）设为新模式，我一直在苦苦挣扎。”即使对他来说也不是那么简单。

【参考方案5】：

这可能有点简化，但这是我的看法。

使用外观模式时，您提供了其他人可以用来与您的应用程序对话的接口。

示例：

您已经实现了一些具有多个“模块”的应用程序，为了更轻松地访问“模块”，您创建了一个 Facade 以更轻松地与模块进行交互......单点的联系。 使用网关模式时，您封装了一些您想要使用的外部部分。

示例：

您想使用日志记录但不想绑定到特定的日志记录框架，在这种情况下，您可以定义网关来定义您要使用的功能并让网关处理交互使用您要使用的日志记录框架。这使得将来更改日志框架变得容易。

【讨论】：

我相信这可能是最好的答案。立面：您将（内部）复杂系统隐藏在其后面。网关：你在它后面隐藏了一个外部系统。方向相反。

不同框架的日志记录示例看起来像适配器模式？

【参考方案6】：

我认为 Gateway 是 Facade 的一个特定案例 - 外部系统的外观。

【参考方案7】：

简单地说，Facade 是一种设计模式，而 Gateway 是一种架构模式。

例如，应用程序网关是一种基础架构架构模式。该节点位于 DMZ 中，并将内部节点与只能连接到应用程序网关的外部客户端隔离。

当您考虑架构模式时，请考虑节​​点。当您考虑设计模式时，请考虑类/对象。

Node 是以下内容的抽象：设备 - 硬件和系统软件 - 例如。操作系统、平台/框架等 系统软件被“分配”给设备。节点“封装”了设备和系统软件，并与构成架构的其他节点相关。

网关是将服务器节点与客户端节点隔离的节点 - 客户端节点不能直接连接到服务器节点。网关接收到连接，然后自己建立到目标节点的连接。

【讨论】：

加点趣味：代理是一种设计模式，而反向代理是一种架构模式

【参考方案8】：

立面模式的主要价值是“简化”内部组件（立面后面）的使用。可能是外观中的一个入口点或功能将使用内部组件的多个功能。如果网关在其背后带来了“简化”API 或组件使用的相同价值，那么它可以被视为门面。在其他情况下，网关可能只是架构的中间件、适配器、包装器或呼叫转发元素。或者一个网关可能身兼数职，比如简化几个流程、转发一些调用，同时还充当身份验证或授权中间件。因此，恕我直言，网关是一种高度抽象的模式，可以包含一个或多个特定的结构模式，如外观、适配器、包装器、装饰器或中间件等。。

Martin Fowler 网关的定义在本质上是狭隘的（至少是 here），并且更接近于 API 网关，其作用类似于格式 decorators强>。

就实施而言，网关能做什么和不能做什么是没有限制的。它实际上是一个自己的应用程序，可以提供任何功能。

【参考方案9】：

Facade 用于处理某些对象的图形，就像处理单个对象一样，Gateway 用于连接两个不同的模块/系统。

【参考方案10】：

要回答你的问题，我不会说 Facade==Gateway，而是说 Facade≈Gateway。我的意思是它们大致相等，基于上述不同意见，它们的不同之处尚不清楚。

您需要记住，设计模式和术语的关键组成部分之一是帮助更轻松地传达您的想法。话虽如此，如果您总是用外观说话，那么您将更有可能被理解，因为这是最常用的术语。

【参考方案11】：

我倾向于将许多模式视为代理模式的特殊情况，并不太担心具体是哪一种。

即：

Facade 是一个简单的代理 一堆复杂的类。

适配器是部分的代理 接口不兼容的系统 作为我们目前需要的人

等等……

从我在 Google 搜索“网关模式”中发现的内容来看，似乎 Gateway == Proxy :D