サービスとファサードの役割は似ていますか？
読むほど、混乱します。
すべての質問は、サービスとファサードがMVCパターンにどのように適合するかに関連していることに注意してください。
私の理解では、Facadeはスーパースマートオブジェクトではなく、単純なインターフェイス/ APIを公開して複雑な操作を実行する方法にすぎません（例：10ドルの支払いを実行します。操作ですが、そのような複雑さは、特定の順序で対応するオブジェクトを呼び出すだけのファサードによって処理することができます...など...）
現在、サービスは、複雑なデータ構造を取得するために、いくつかのDAOへの呼び出しを実行する方法です（これについてはあまりわかりませんが、これまでのところ理解していることです）。
質問は、ファサードとサービスの違いは何ですか？一日の終わりには、ファサードはいくつかのDAOに完全にアクセスして、シンプルなインターフェイスを提供することで複雑な操作を実行できます。サービスは似たようなものに見えます。
トランザクションについても同じことが起こります。サービスはトランザクションを開始する場所であると理解していますが、同じように、ファサードにも複数のDAOを呼び出す可能性があると感じています。
それで、どのスタックがより理にかなっています
controller-facade-dao controller-service-dao
または多分
controller-facadade-daoおよび時々controller-facade-service-dao ??
serviceは、LDAP IDストア、支払いゲートウェイ、またはアプリケーション管理インターフェースなどの外部システムへのインターフェースを記述する方法です。これは、外部システムを、操作対象の受動的な塊ではなく、おそらく内部動作を備えた有用なサービスのproviderと見なす概念的な方法です。
facadeは、（サービスを含む）何かをまとめて別のコンポーネントにうまく表示する方法です。ファサードは次の場合によく使用されます。
- ライブラリまたはコンポーネントは複雑であり、アプリケーションはそのサブセットのみを必要とします。 Facadeは、アプリケーションに簡易APIを提示します
- 複数のライブラリまたはコンポーネントを使用しており、それらを統合し、アプリケーションに統合APIを提示する必要があります
- 使用しているライブラリには複雑なセットアップまたは依存関係のセットがあり、ファサードはアプリケーションのコンテキストですべてをラップします。
本当に紛らわしいのは、1つ以上のサービスの上にファサードを作成できる（そして頻繁に行う）ことです。サービスは、コンポーネントが実際にリソースにアクセスする方法であり、ファサードはコンポーネントを単純化するビットです（オプションの構成、接続など）。
独自のDAOを作成する場合、おそらく必要な方法でサービスを作成することになるため、ファサードを作成することは、間違っていることを示しています。 DAOがサードパーティによって構築されており、ニーズよりも複雑な場合、thenサービスをファサードできます。
現在、サービスは、複雑なデータ構造を取得するために複数のDAOへの呼び出しを実行する方法です（これについてはあまりわかりませんが、これまでのところ理解しています）。
DAOはそれ自体がデザインパターンであると言えます- ウィキペディアを参照 。
DAOとサービスを比較すると、次のようになります。
- APIのレベル：
- DAO：プロパティへのきめ細かいアクセス
- サービス：サービスへの粗粒度のアクセス
- 実装の場所：
- DAO：主にクライアント上ですが、データベースにデータ（動作なし）を保存します
- サービス：主にサーバー上
- インターフェースの呼び出し方法
- DAO：クライアントは同じ名前空間とJVMのオブジェクトに直接バインドします
- サービス：クライアントは、ネットワーク、仮想マシン間または名前空間間の操作の単なるスタブです
...ファサードは、シンプルなインターフェイスを提供することで複雑な操作を実行するために複数のDAOに完全にアクセスでき、サービスは同様のように見えます。
ファサードcouldはDAOレイヤーをラップアップしますが、これが便利な方法で実際に発生することはありません。ほとんどの場合、オブジェクトの個々のプロパティにアクセスし、オブジェクトグラフなどをトラバースするためにAPIが必要です。これはまさにDAOが提供するものです。
トランザクションでも同じことが起こります。サービスはトランザクションを開始する場所であると理解しています...
もちろん、トランザクションは、データベースおよび別のコンポーネントまたはシステムで提供されるserviceであるため
...しかし、私も同様に、ファサードに配置できると感じています。結局のところ、ファサードはいくつかのDAOを呼び出すこともあります。
また、多くの点で、トランザクションマネージャーserviceは、はるかに複雑なバックエンド実装のファサードであり、Web、アプリケーション、データベース上のトランザクションを調整します。他のトランザクション対応コンポーネント。 ただし、これは、トランザクションサービスの実装によってすでに抽象化されています。ユーザーである私たちに関する限り、パブリックインターフェイスのみがあります。
これは、実際、これらの設計パターンの概念的なポイントです。ユーザーに適切な量のAPIを提供し、コンポーネントインターフェースの鉄壁の背後にある実装の複雑さを抽象化します。
それで、どのスタックがより理にかなっています
controller-facade-dao controller-service-dao
または多分
controller-facadade-daoおよび時々controller-facade-service-dao ??
- DAOはデータベースに対する一種のサービスですが、実際にはDAOはデザインパターンそのものです。
- 独自のDAOを作成する場合、ファサードは必要ありません。
したがって、正しい答えは次のとおりです。
- コントローラー-dao
文字通り、名前が示すようにファサードは建物の正面を意味します。道路を通り過ぎて歩いている人々は、ファサードだけを見ることができます。彼らはその内部、配線、パイプ、その他の複雑さについて何も知りません。顔は、建物の複雑さをすべて隠し、よりシンプルな友好的な顔を表示します。
ソフトウェア用語では、facadeは、よりシンプルなインターフェイスを提供することにより、ソフトウェアコンポーネントの複雑さを隠し、独自の機能を持たず、substsyemへのアクセスを制限しません。オブジェクト指向設計で一般的に使用されます。良い例はSLF4Jです。これは、エンドユーザーが展開時に目的のログシステムをプラグインできるようにするログシステム用のシンプルなファサードであるapiです。
サービスは、機能の単位へのアクセスを提供し、常に仕様に書き込まれるパブリックインターフェイスです。さまざまなコンシューマーが必要とする通信コントラクト（メッセージベースの通信、フォーマット、プロトコル、セキュリティ、例外など）をサポートする必要があります。 プロセスサービス-ビジネスワークフローのカプセル化、ビジネスロジックサービス-ルール/機能のカプセル化、データサービス-エンティティとの相互作用、データアクセス管理、インフラストラクチャサービス-監視、ロギング、セキュリティなどのユーティリティ機能。サービスはほとんどが再利用可能で、関連付けられていない、疎結合の機能ユニットです。
それらはよく似ていますが、それをどう見るかによって異なります。
私が見る違いは、ファサードは裏返しに設計されていることです。サブシステムを見て、ファサードを設計して、より簡単なアクセスを提供します。サービスは外部で設計されています。顧客/クライアントを見て契約を定義し、サービスを設計します。
FACADEは、サブシステム内の多くのインターフェイスへの統合インターフェイスが必要な場合の問題を解決する設計パターンであるため、サブシステムを使いやすくする上位インターフェイスを定義します。
ただし、サービスはリソースまたはインターフェイス/オブジェクトのセットへのアクセスを提供し、必ずしもそのようなアクセスを単純化するとは限りません。したがって、ファサードパターンを使用してサービスをより適切に設計し、クライアントを保存して、それを使用するための構築方法を考え出すことができます。
古典的なGoF Facadeパターンの私の理解は、主に貧弱なデザインを隠すことを意図しているということです。経験則として、レガシーコードにはFacadeのみが必要です。
また、EJB仕様（少なくとも2.xまで）が本質的に貧弱なサービス層設計をもたらしたため、このパターンがJ2EEコアパターン（Session Facade）として定着したと思います。
したがって、あなたの質問に対する私の答えはyesになります。ファサードは実際には、最初は適切に実装されていないサービスです。クライアントコードから複雑さを隠す必要がある場合、通常はサービスレイヤではなくライブラリのみを提供することを意味します。したがって、この場合、Facadeは実際にサービス層になります。
一方（まともなドメインレイヤーがある場合）、単一のメソッド呼び出し（マクロ/エイリアスに似たもの）で複雑なフローを生成するオプションを本当に提供する必要がある場合、これは通常、アプリケーションレイヤーに配置し、コアドメインではありません-「データアクセス」または「サービス」レイヤーではなく、「アプリケーション」、「ドメイン」、「インフラストラクチャ」というドメイン駆動設計にレイヤー用語を切り替えたことに注意してください。
答えようとする前に、何かを明確にしましょう。エンタープライズアプリケーションには、3つの明確なものがあります-Facade、Service Layer、およびRemote Facade。
Facade-サブシステムをラップしている間も、オブジェクトであり、UI（MVC）アプリケーションは通常同じプロセスに存在します。したがって、通信は通常のOO方式で行われます。メソッドの呼び出し、プロパティの読み取り、イベントのリッスン。
サービス層-ビジネスロジック層が成熟し、MVCが直接やり取りするには複雑すぎる場合、サービス層がそれらの間に配置されます。サービスレイヤーは、MVCがビジネスロジックのラッパーとして使用するAPIです。通信にはワイヤが関与しないため、リモートではなく、DTOを使用する必要はありません。
リモートファサード単に、リモートサービス）これは、ファサードとサービスレイヤーのハイブリッドです。システム上のある種のラッパーを公開境界として公開する場合（およびファサードと呼びます）、リモートファサードは既存から開始します。理由の1つは、複数のUI（MVC）アプリケーションが同じリモートファサードを使用できるようにすることです。
-
---（比較：
ファサード vs. サービスレイヤー：両方ともサブシステムをラップするため、類似しています。違いは、サービスレイヤーがUI（MVC）アプリケーションのニーズに基づいており、ビジネスロジックの操作を簡素化する機能を公開していることです。一方、Facadeはビジネスロジックを簡素化する機能を公開していますが、UI（MVC）アプリケーションとの通信を必ずしも単純化するわけではありません。
Facade vs. Remote Facade（Service？）：Remote Facadeは通信メッセージとしてDTOを使用する必要があるため、明らかに異なります。リモートファサードを通常のオブジェクト（プロパティ、イベント）として使用する場合は、何らかの種類のプロキシが必要です。しかし、プロキシはとにかく実際のオブジェクト、つまりリモートファサードに対してDTOを使用します。
-
可能なフロー：
_controller-facade-dao_-疑わしいが、まだ可能。ファサードは通常、DALだけをラップするためには使用されません。サブシステムとしてさらに成熟したものが必要です。しかし、ファサードがビジネスロジックの一部である場合は、可能です。それでも、サブシステムをより強調する必要があります。私にとって、DALラッピングはFacadeと呼ぶのに十分ではありません。
_controller-service-dao_-絶対に可能です。多くのリモートサービスは、DALを介してデータベースと直接連携します。
_controller-facade-service-dao_-サービスをサブシステムとして扱う場合。
意味のあるものをもう1つ追加します。
controller-service [layer]-facade (part of business)-subsystem (e.g. accounting, business on its own)-dao-これを翻訳できると確信しています。
-
サービス（またはリモートファサード）はフローのどこにでも存在できることを忘れないでください。これは、ディストリビューションのニーズによって決まります。
ええ、ファサードとサービスは完全に無関係ではありません。また、クライアントがサービスの多くの詳細に煩わされないように、サービスレイヤーをFacadeとして実装することもあります。サービスの呼び出し/インターフェイスがよりシンプルになるほど、クライアントコードはよりシンプルで簡単になります。
マーティン・ファウラーは言う...
サービスレイヤーは、アプリケーションの境界[Cockburn PloP]と、クライアントレイヤーとのインターフェースの観点から利用可能な一連の操作を定義します。アプリケーションのビジネスロジックをカプセル化し、トランザクションの制御とその操作の実装における応答の調整を行います
したがって、サービスレイヤーは、Facadeとして使用されることがあります。
通常、これらの用語は特定のコンテキストでのみ使用されます。
「Facade」の一般的な使用状況：アプリケーションの複雑な部分用のシンプルなAPI（サードパーティライブラリなど）
「サービス」コンテキスト：システム内のビジネスエンティティをロック解除して表示します。 （SOA、DAO、セキュリティなど）
パターンは進化する言語として見ることができます。各パターンが独自の歴史と文脈を持っているということは、決して完璧な終わりのようには見えませんでした。クラスは、サービスとファサードとして同時に表示されることもあれば、そうでないこともあります。
たとえば、「サービス」という用語でサードパーティAPIを呼び出すことは、間違ったコンテキストのために誤用と見なされる可能性があります。
最初に注意することは、設計パターンは標準ソリューションの一般的な（設計）問題の説明であることです。場合によっては、すべての要件に適合する方法で問題を解決するいくつかの方法があります（f.ex. IteratorパターンとSingletonパターンには多くの異なる実装があります; f.ex. Alexandrescuの動作を確認して比較します標準のGoFソリューションと）、同じ（コード）ソリューションと異なるパターンがある場合があります（f.ex. GoFブックのCompositeパターンとDecoratorパターンのクラス図を比較してください）。
GoFによると、Facadeパターンの目的は次のとおりです（リテラル引用）。
サブシステム内の一連のインターフェイスに統一されたインターフェイスを提供します。 Facadeは、サブシステムを使いやすくする、より高いレベルのインターフェイスを定義します。
サービスには、特定の機能を備えた単一の高レベルインターフェイスをユーザーに提供する意図があります。サービスは厳密に言えばunified interface to a set of interfaces in a subsystem.ではなく厳密に言えば、必ずしもファサードになっているわけではありません
しかし、私たちはそれよりうまくやることができます
あなたの質問は、パターンが「似ている」かどうかでした。パターンAがBに等しく、パターンBがAに等しいときに「類似」とみなす場合、2つの質問に答える必要があります。
質問1：はService a Facade ??サービスは間違いなく機能を公開する必要があり、間違いなくこの機能を公開する単一のインターフェイスです。機能は通常、小さな断片に分解されるため、はい、サービスはファサードの基本的な要件に適合します。言い換えれば、基礎となるインターフェースを統一された「サービス」インターフェースとして公開するという問題に直面しているため、ファサードパターンは要件に適合し、サービスの問題を解決するために使用されます。これに対する答えはyesです。
質問2：はFacade a Service？ですか？サービスは通常、再利用可能な、関連付けられていない、疎結合の機能ユニットとして設計されています。コンポーネントは通常、SOAPまたはWCFなどのTCP/IPインターフェイスに依存するため、コンポーネント間の通信を考慮することが重要です。これは、機能がservicesパラダイムにより密接になり、暗黙的なパフォーマンスによるパターンの要件が追加されます。ファサードにはこの追加要件はありません。つまり、ファサードはサービスではありません =。
厳密に言えば、これらの概念は密接に関連していますが、同じではありません。
しかし、もっとうまくできる
この考え方は、サービスがファサードの拡張バージョンである？サービスがファサードのすべての要件を満たし、その上に拡張する場合です。
GoFの説明をよく読むと、答えは「はい」です。つまり、1つの条件が満たされている場合、サービスはサブシステムの公開である必要があります。現実には、この条件は通常維持されるか、サービスを過剰に設計していると思います-厳密に言えば、これは厳しい制限ではないと思います。
serviceインターフェースは通常、ビジネス上の懸念を表しています。何らかの操作を実行したり、情報を取得したりします。サービスプロバイダーが自社のサービスを内部バックエンドサービスのファサードとして実装することは不合理ではありません。これは決してありません。
facadeは、サービスインターフェイスを含む一般的なインターフェイスをラップする場合があります。
たとえば、銀行口座のサービスインターフェイス（操作：銀行送金）、およびローカル会計レコードへのローカルAPI（送金）があります。銀行のサービスインターフェースを使用し、現地の小切手帳も管理する「お金の移動」操作でファサードを紹介できます。
FacadeおよびService Layerには類似性がありますが、両方とも2つのdistinguished意味。簡単な例を使用してこれを説明しましょう。
新しいビジネスアプリケーションを作成するように求められているとします。これには、チェックインアプリケーションを作成する必要がありますが、付加価値のある機能とロイヤルティカード機能が追加されています。
ユーザーが使用したい場合、アプリケーションがFacebookおよびFoursquareのチェックイン機能をサポートする必要があるとしましょう。この機能は非常に必要です。一部のユーザーは、同じ機能を実行する複数のアプリケーションを使用したり、ソーシャル接続を削除したりするためです。
高レベルのアイデアを得るには、次のリンクのサンプルAPIを参照してください https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing
ABCファサードにある上記のチェックインAPIは、Facadeの使用例です。
サービスAPIがあり、クライアントの選択に基づいてFacebookとfoursqureのチェックイン機能もあります。 Facebookおよびfoursqure APIには、特定の実装（SOAP、Restfulなど）およびセキュリティ（OAuthなど）要件などがあります。
これらのAPI（facebook、foursqure）要件のいずれかを満たすには、さまざまなタスクセットを満たす必要があります。これらは、チェックイン要件の異なるサブシステムになります。
したがって、facadeの単純な使用法は、1つの単純な方法によってトリガーされる複数のサブシステムを満たすことです
しかし、MngCheckinSvcにあるチェックインAPIである独自のAPIを検討する場合。これは、サービス層APIです。これは、アプリケーションのチェックイン要件を含むAPIです。これは、アプリケーションへのチェックイン要件を処理するためにMngCheckinSvcからパブリックアクセスを提供するAPIです。
これには複雑な内部動作がありますが、それでもほとんどはアプリケーション固有のロジック実装です。
このAPI（MngCheckinSvc.checkin（....））は、アプリケーションでのマーチャントチェックインを実現するために、異なるDAOセット、内部API、その他の内部サービスなどにアクセスする場合があります。
重要なのは「コンテキスト」です。ファサードとサービスは競合していません。
まず、MVCのコンテキストで「サービス」と「ファサード」について聞いたことがありません。
人々がサービスについて話すとき、それは、外界にビジネスに意味のあるアクションを提供するシステムまたはコンポーネントに関するものです。 「作業単位」に関連する「サービス」（およびトランザクション）が表示される場合があります。
サービスは、アプリケーションの階層化アプローチのコンテキストでも使用されます。DAOの上にサービスがあり、そのサービスはDAOを介してデータにアクセスし、ビジネスロジックはサービスレイヤーに配置されます。
ファサードは通常、設計パターンのコンテキストで使用され、焦点は「複雑な操作を非表示にして単純な操作として公開する」ことです。
ファサードはサービスである場合とそうでない場合があります（Facadeでの操作は作業単位を表さない場合がありますが、それでも有効なファサードです）。同様に、サービスはファサードである場合とそうでない場合があります操作が、それはまだサービスです）。
繰り返しますが、重要なのは「コンテキスト」についてです。
たとえば、アプリケーションの階層化について話している場合、「XXXはDAOにアクセスするためのファサードです」と言うのは単純に非合理的です。同様に、「デザインアプローチ」について話している場合、ここでは「XXX」は「サービス」と呼ぶ代わりに「XXXは複数のバックエンドのファサード」と言う方が合理的です（ただし、XXXは実際にはサービスです）。