Facade와 Gateway 디자인 패턴의 차이점은 무엇입니까?

Facade와 Gateway 디자인 패턴의 차이점은 무엇입니까?

---

또는 Facade == Gateway?

---

GoF 책의 Facade와 Martin Fowler의 게이트웨이에 대한 또 다른 답변의 링크를 검토하면 그들의 초점은 반대 방향으로 보입니다.

Facade는 하나 이상의 외부 클라이언트에게 복잡한 내부의 단순하고 균일 한보기를 제공합니다.

게이트웨이는 애플리케이션 내부에 대한 외부 리소스의 단순하고 균일 한보기를 제공합니다.

이 구별을 통해 디자인에서 더 중요한 것에 집중할 수 있습니다.

Facade에서는 외부 시스템이 고객입니다. 외부 인터페이스를 더 간단하게 만드는 경우 내부를 향한 복잡성을 추가하는 것이 좋습니다.

게이트웨이를 사용하면 내부 시스템이 고객입니다. 외부가 더 복잡하더라도 우리가 할 수있는 모든 도움을주세요.

---

이 두 패턴은 둘 다 무언가에 대한 래퍼 역할을 한다는 점에서 매우 유사 합니다 . 차이점은 문맥에 있습니다 . 파사드는 하위 시스템 그룹을 의미하는 반면 게이트웨이는 모든 기능 위에 위치 할 수 있습니다. 이 관점에서 나에게 Facade 는 Gateway의 구체적인 사례입니다.

Facade는 서브 시스템 작업이 복잡하다고 생각 하거나 여러 서브 시스템 호출을 하나의 [method] 실행으로 그룹화하려는 경우에 적용됩니다 . 그러나 이것이 반드시 하위 시스템에 액세스 할 수 없거나 충분히 복잡하다는 것을 의미하지는 않습니다. 그것은 단순히 우리 에게 서브 시스템이 있다는 것을 의미합니다 .

게이트웨이는 우리가 어떤 것을 포장하고 다른 방식으로 노출하고자 할 때 적용됩니다. 게이트웨이는 하위 시스템이 아닌 비교적 복잡한 기능을 래핑 할 수 있습니다. 게이트웨이는 Facade, Proxy 및 기타 패턴의 기초로 생각할 수 있는 일반적인 패턴입니다.

설명을 위해 여전히 예가 필요한 경우 :

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();
    }
}

[분명히 이것은 의사 코드입니다]

---

외관의 의도는 다음과 같이 주어진다 http://c2.com/cgi/wiki?FacadePattern 로

하위 시스템의 인터페이스 집합에 통합 인터페이스를 제공합니다. Facade는 서브 시스템을 더 쉽게 사용할 수 있도록하는 상위 레벨 인터페이스를 정의합니다. 이것은 여러 복잡한 개체 상호 작용을 단일 인터페이스로 단순화하는 데 사용할 수 있습니다.

여기서 초점은 복잡성을 숨기는 인터페이스를 디자인하는 데 있으며, 핵심 아이디어는 더 유용한 단일 상호 작용에서 여러 세분화 된 상호 작용을 숨기는 것입니다. 따라서 Facade의 초점은 클라이언트 대면입니다.

게이트웨이 패턴은 원래 GOF 패턴 중 하나가 아니며, 저는이를 엔터프라이즈 통합 패턴, 즉 Facade보다 다소 높은 수준으로 더 많이 봅니다. 파울러의 정의보기

나는 게이트웨이를 주로 인터페이스 복잡성보다는 기술적 복잡성을 숨기는 것으로 본다. 메인 프레임과 외부 시스템에 연결하는 세부 사항을 숨기는 것이다. 사실 저는 종종 게이트웨이가 요청 라우터의 어떤 것이 될 것으로 기대하며, 요청 세부 정보를 기반으로 다른 백엔드 시스템을 선택할 수도 있습니다. 그래서 저는 게이트웨이가 게이트웨이가되는 것에 초점을 맞추고 있다고 생각합니다.

분명히 비공식적으로 게이트웨이는 세부 사항을 숨긴다는 점에서 Facade이지만 GOF Facade와 Fowler Gateway를 구현하면 완전히 다른 작업을 수행하게된다고 생각합니다.

---

저는 게이트웨이가 외부 시스템에 대한 외관 인 Facade의 특정 사례라고 생각합니다.

---

다음은 Fowler의 책에서 직접 인용 한 것입니다.

While Facade simplifies a more complex API, it's usually done by the writer of the service for general use. A Gateway is written by the client for its particular use. In addition, a Facade always implies a different interface to what it's covering, whereas a Gateway may copy the wrapped facade entirely, being used for substitution or testing purposes.

[Chapter 18]

---

This might be somewhat simplified but here is my take on it.

• When using the Facade pattern you provide the interface that others can use to talk to your application. Example: You have implemented some application that has multiple "modules", to make the access to the "modules" easier you create a Facade to make it easier to interact with the modules... a single point of contact.
• When using the Gateway pattern you encapsulate some external part that you want to use. Example: you want to use logging but don't want to bound to a specific logging framework, in that case you can define your gateway that defines the functionality you want to use and let the gateway handle the interaction with the logging framework you want to use. This make it easy to change logging framework in the future.

---

Simply put, Facade is a design pattern while Gateway is an architectural pattern.

Application Gateway, for example, is an infrastructure architecture pattern. The node resides in DMZ and insulates internal nodes from external clients who can only connect to application gateway.

When you think about architecture patterns, think about nodes. When you think about design patterns, think about classes/objects.

Node is an abstraction of: device - hardware stuff and system software - e.g. OS, platform/framework etc. System software is "assigned" to the device. Node "encapsulates" both device and system software and is related to other nodes comprising the architecture.

Gateway is a node that insulates server nodes from client nodes - client node cannot directly connect to a server node. Gateway receives the connection and then establishes connection itself to the destination node.

---

Facade used for working with some Object's graph as with single object and Gateway for connecting two different modules/systems.

---

To answer your question, I would not say that Facade==Gateway, but that Facade≈Gateway. By that I mean that they are approximately equal, how they differ is not apparently clear based upon the differing opinions above.

You need to remember that one of the key components of design patterns and terminology in general is to help more easily communicate your ideas. With that being said if you always speak in terms of a facade you will a greater chance of being understood as that is the term used most frequently.

---

A facade pattern main value is to 'simplify' use of internal components (behind the facade). It could be so that one entry point or function in the facade will use multiple functions of the internal components. If a gateway is bringing the same value of 'simplifying' usage of APIs or components behind it then it could be considered a facade. In other situations, a gateway could be merely a middleware, adapter, wrapper or a call forwarding element of the architecture. Or a gateway could be wearing multiple hats, like simplifying few flows, forwarding some calls while acting as an authentication or authorisation middleware in parallel too. Thus, IMHO gateway is a highly abstract pattern that could encompass one or more specific structural patterns like facade, adapter, wrapper, decorator or middleware etc..

Martin Fowler definition of gateway is narrow in nature (at least the one here) and is closer to API Gateways acting like format decorators.

As far the implementation is concerned, there is no limit on what a gateways could and could not do. It is virtually an application of its own and could deliver any functionality.

---

I tend to think of many of patterns as of special cases of Proxy pattern, and don't worry much which one specifically it is.

I.e:

• Facade is your simple proxy to a bunch of complicated classes.

• Adapter is a proxy to parts of the system with incompatible interfaces as the one we need at the moment

• etc...

Judging from what I've found on a Google search for "gateway pattern" it seems that Gateway == Proxy :D

참고URL : https://stackoverflow.com/questions/4422211/what-is-the-difference-between-facade-and-gateway-design-patterns