またはFacade == Gateway?
GoF本のFacadeとMartin Fowler's Gatewayへの別の回答のリンクを確認すると、それらの焦点は反対の方向にあるように見えます。
Facadeは、(1つまたは複数の)外部クライアントに複雑な内部のシンプルで統一されたビューを提供します。
ゲートウェイは、外部リソースの単純で統一されたビューをアプリケーションの内部に提供します。
この区別により、設計でより重要なものに焦点を当てることができます。
Facadeでは、外部システムがお客様です。外部インターフェイスをよりシンプルにする場合は、内向きの複雑さを追加することをお勧めします。
ゲートウェイでは、内部システムがお客様です。外部がより複雑な場合でも、できる限りの手助けをしてください。
これらの2つのパターンは、が何かのラッパーとして機能するという点で非常に似ています。違いはcontextにあります:ファサードはサブシステムのグループの上に立っていますが、ゲートウェイはあらゆる機能の上に立っています。この観点から、私にとってFacadeはGatewayの具体的なケースです(反対ではありません)。
サブシステムの操作が複雑またはであると考えられる場合、複数のサブシステムコールを1つの[メソッド]実行にグループ化する場合、ファサードが適用されます。ただし、これは必ずしもサブシステムにアクセスできない、またはサブシステムが十分に複雑であることを意味するわけではありません。これは単に、サブシステムがhaveであることを意味します。
ゲートウェイは、いくつかのものをラップして別の方法で公開したいときに適用されます。ゲートウェイは、サブシステムではなく、比較的複雑な機能をラップしている可能性があります。ゲートウェイは、generalパターンであり、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パターンの1つではなく、私はそれをエンタープライズ統合パターン、つまりFacadeよりもかなり高いレベルと見ています。ファウラーの definition を参照
ゲートウェイは、主にインターフェイスの複雑さではなく、技術の複雑さを隠すこと、つまりメインフレームや外部システムへの接続の詳細を隠すことだと考えています。実際、ゲートウェイがリクエストルーターのようなものになることをしばしば期待します。おそらく、リクエストの詳細に基づいて異なるバックエンドシステムを選択することさえあります。ゲートウェイは、ゲートウェイであることに焦点を当てていると考えています。
明らかに、非公式にゲートウェイは詳細を隠すという点でファサードですが、GOFファサードとファウラーゲートウェイを実装すると、まったく異なることを行うことになります。
Gatewayは、Facadeの特定のケース、つまり外部システム上のファサードだと思います。
ファウラーの本からの直接の引用は次のとおりです。
Facadeはより複雑なAPIを簡素化しますが、通常は一般的な使用のためにサービスの作成者が行います。ゲートウェイは、特定の用途のためにクライアントによって作成されます。さらに、Facadeは常に、カバーするものとは異なるインターフェイスを暗示しますが、Gatewayは、ラップされたファサードを完全にコピーし、置換またはテストの目的で使用できます。
[第18章]
これはいくぶん単純化されているかもしれませんが、ここに私の見解があります。
簡単に言うと、Facadeはデザインパターンであり、Gatewayはアーキテクチャパターンです。
たとえば、Application Gatewayはインフラストラクチャアーキテクチャパターンです。ノードはDMZにあり、アプリケーションゲートウェイにのみ接続できる外部クライアントから内部ノードを隔離します。
アーキテクチャパターンについて考えるときは、ノードについて考えてください。デザインパターンについて考えるときは、クラス/オブジェクトについて考えてください。
Nodeは次のものの抽象化です:デバイス-ハードウェアとシステムソフトウェア-例OS、プラットフォーム/フレームワークなど。システムソフトウェアはデバイスに「割り当て」られます。 Nodeデバイスとシステムソフトウェアの両方を「カプセル化」し、アーキテクチャを構成する他のノードに関連しています。
ゲートウェイは、サーバーノードをクライアントノードから隔離するノードです。クライアントノードはサーバーノードに直接接続できません。ゲートウェイは接続を受信し、宛先ノードへの接続自体を確立します。
単一のオブジェクトと2つの異なるモジュール/システムを接続するためのゲートウェイのように、いくつかのオブジェクトのグラフを操作するために使用されるファサード。
ファサードパターン主な値は、 'simplify'内部コンポーネント(ファサードの背後)を使用することです。ファサードの1つのエントリポイントまたは機能が内部コンポーネントの複数の機能を使用するようにすることもできます。ゲートウェイが同じ値の「simplifying」を使用している場合、その背後にあるAPIまたはコンポーネントの使用は、ファサードと見なすことができます。他の状況では、ゲートウェイは単にミドルウェア、アダプター、ラッパー、またはアーキテクチャーのコール転送要素である可能性があります。または、ゲートウェイは、いくつかのフローを単純化し、認証または許可ミドルウェアとして同時に機能しながらコールを転送するなど、複数の帽子をかぶっています。したがって、IMHO ゲートウェイは、ファサード、アダプター、ラッパー、デコレーター、ミドルウェアなどの1つ以上の特定の構造パターンを含むことができる非常に抽象的なパターンです。
Martin Fowlerゲートウェイの定義は本質的に狭く(少なくとも1つ ここ )、より近いAPI Gateways形式のように振る舞いますデコレータ。
実装に関する限り、ゲートウェイができることとできないことには制限がありません。それは実質的にそれ自身のアプリケーションであり、あらゆる機能を提供できます。
あなたの質問に答えるために、私はFacade == Gatewayとは言いませんが、Facade≈Gatewayと言います。つまり、それらはほぼ等しいということであり、上記の異なる意見に基づいて、それらがどのように異なるかは明らかではありません。
一般に、デザインパターンと用語の重要なコンポーネントの1つは、アイデアをより簡単に伝えることです。あなたが常にファサードの観点から話すなら、それが言われているので、あなたはそれが最も頻繁に使用される用語であるとして理解されるより大きなチャンスになります。
私は多くのパターンをプロキシパターンの特殊なケースと考える傾向があり、具体的にどのパターンであるかはあまり気にしません。
つまり:
Facadeは、多数の複雑なクラスに対する単純なプロキシです。
アダプターは、現時点で必要なインターフェースと互換性のないインターフェースを備えたシステムの一部へのプロキシです
等...
「ゲートウェイパターン」のGoogle検索で見つけたものから判断すると、Gateway == Proxy:Dのようです