67

読めば読むほど、私は混乱します。

すべての質問は、サービスとファサードがMVCパターンにどのように適合するかに関連していることに注意してください。

私の理解では、ファサードは超スマートなオブジェクトではなく、複雑な操作を実行するための単純なインターフェース/ APIを公開する方法です（例：10ドルの支払いを実行する、それは多くの操作が、そのような複雑さは、特定の順序で対応するオブジェクトを呼び出すだけのファサードによって処理できます...など...）

現在、サービスは、複雑なデータ構造を取得するために複数のDAOへの呼び出しを実行する方法です（これについてはよくわかりませんが、これまでのところ理解しています）。

では、ファサードとサービスの違いは何ですか？結局のところ、ファサードはいくつかのDAOに完全にアクセスして、単純なインターフェイスを提供することで複雑な操作を実行できます。サービスは似たようなもののようです。

トランザクションでも同じことが起こります。サービスがトランザクションを開始する場所であることは理解していますが、ファサードにも配置できると同じように感じています。結局のところ、ファサードは複数のDAOを呼び出すこともあります。

したがって、どちらのスタックがより理にかなっているのでしょうか

controller-facade-dao controller-service-dao

または多分

controller-facadade-daoそして時々controller-facade-service-dao??

4

11 に答える 11

60

サービスは、LDAP IDストア、支払いゲートウェイ、アプリケーション管理インターフェイスなどの外部システムへのインターフェイスを作成する方法です。これは、外部システムを、操作対象の受動的な塊ではなく、おそらく内部の動作を備えた有用なサービスのプロバイダーと見なす概念的な方法です。

ファサードは、何か（サービスを含む）をまとめて、別のコンポーネントにうまく表示する方法です。ファサードは、次の場合によく使用されます。

  • ライブラリまたはコンポーネントは複雑であり、アプリケーションに必要なのはそのサブセットのみです。ファサードは、簡略化されたAPIをアプリケーションに提示します
  • 複数のライブラリまたはコンポーネントを使用していて、それらを統合して、統合されたAPIをアプリケーションに提示する必要があります
  • 使用しているライブラリには複雑なセットアップまたは一連の依存関係があり、ファサードはそれらすべてをアプリケーションのコンテキストでラップします。

本当に紛らわしいのは、1つまたは複数のサービス上にファサードを作成できる（そして多くの場合そうする）ということです。サービスは、コンポーネントが実際にリソースにアクセスする方法であり、ファサードは、コンポーネントを簡素化するビットです（オプションの構成、接続など）。

独自のDAOを作成する場合は、おそらく必要な方法でサービスを作成するため、ファサードを作成することは、それが間違っていたことを示しています。DAOがサードパーティによって構築されており、ニーズよりも複雑な場合は、サービスをファサードできます。

現在、サービスは、複雑なデータ構造を取得するために複数のDAOへの呼び出しを実行する方法です（これについてはよくわかりませんが、これまでのところ理解しています）。

DAOはそれ自体がデザインパターンだと思います。ウィキペディアを参照してください。

DAOとサービスを対比すると、次のようになります。

  • APIのレベル：
    • DAO：プロパティへのきめ細かいアクセス
    • サービス：サービスへのきめ細かいアクセス
  • 実装がある場所：
    • DAO：主にクライアント上にありますが、データベースにデータを（動作なしで）保存します
    • サービス：主にサーバー上
  • インターフェイスの呼び出し方法
    • DAO：クライアントは同じ名前空間とJVM内のオブジェクトに直接バインドします
    • サービス：クライアントは、ネットワーク、クロスVM、またはクロスネームスペース操作の単なるスタブです。

...ファサードは、単純なインターフェイスを提供することで複雑な操作を実行するために、複数のDAOに完全にアクセスでき、サービスは似たようなもののようです。

ファサードはDAOレイヤーを包み込む可能性がありますが、これが便利な方法で行われているとは思えません。ほとんどの場合、オブジェクトの個々のプロパティにアクセスしたり、オブジェクトグラフなどをトラバースしたりするために、APIが必要です。これは、まさにDAOが提供するものです。

トランザクションでも同じことが起こります。サービスがトランザクションを開始する場所であることを理解しています...

絶対に、トランザクションはデータベースと別のコンポーネントまたはシステムによって提供されるサービスであるためです

...しかし、ファサードにも配置できると同じように感じています。結局のところ、ファサードは複数のDAOを呼び出すこともあります。

また、多くの点で、トランザクションマネージャーサービスは、はるかに複雑なバックエンド実装へのファサードであり、Web、アプリケーション、データベース、およびその他のトランザクション対応コンポーネントでトランザクションを調整します。ただし、これはトランザクションサービスの実装によってすでに抽象化されています。ユーザーである私たちに関する限り、パブリックインターフェイスのみがあります。

これは、実際、これらのデザインパターンの概念的なポイントです。つまり、適切な量のAPIをユーザーに提供し、コンポーネントインターフェイスの鉄壁の背後にある実装の複雑さを抽象化します。

したがって、どちらのスタックがより理にかなっているのでしょうか

controller-facade-dao controller-service-dao

または多分

controller-facadade-daoそして時々controller-facade-service-dao??

  1. DAOはデータベースに対する一種のサービスですが、実際にはDAOはデザインパターンそのものです。
  2. 独自のDAOを作成する場合は、ファサードは必要ありません。

したがって、正解は次のとおりです。

  • コントローラー-dao
于 2013-02-26T01:47:41.310 に答える
27

文字通り、名前が示すようにファサードは建物の正面を意味します。道路を通り過ぎて歩いている人々はファサードしか見ることができません。彼らはその中身、配線、パイプ、その他の複雑さについて何も知りません。顔は建物の複雑さをすべて隠し、よりシンプルで親しみやすい顔を表示します。

ソフトウェアの用語では、ファサードは、よりシンプルなインターフェイスを提供することでソフトウェアコンポーネントの複雑さを隠し、独自の機能を持たず、サブシステムへのアクセスを制限しません。オブジェクト指向デザインで一般的に使用されます。良い例はSLF4Jです。これはロギングシステムのシンプルなファサードであり、エンドユーザーが展開時に目的のロギングシステムをプラグインできるようにするAPIです。

サービスは、機能の単位へのアクセスを提供し、常に仕様に書き込まれるパブリックインターフェイスです。さまざまなコンシューマーが必要とする通信コントラクト（メッセージベースの通信、フォーマット、プロトコル、セキュリティ、例外など）をサポートする必要があります。プロセスサービス-ビジネスワークフローのカプセル化、ビジネスロジックサービス-ルール/機能のカプセル化、データサービス-エンティティとの相互作用、データアクセス管理、インフラストラクチャサービス-監視、ロギング、セキュリティなどのユーティリティ機能があります。サービスは、ほとんどの場合、再利用可能で、関連付けられていない、疎結合の機能ユニットです。

それらは非常に似ていますが、それをどのように見るかによって異なります。

私が見る違いは、ファサードは裏返しに設計されています。サブシステムを見て、より簡単なアクセスを提供するファサードを設計します。サービスは外部で設計されています。顧客/クライアントが契約を定義し、サービスを設計するのを見てください。

于 2013-02-26T08:51:30.393 に答える
6

古典的なGoFファサードパターンについての私の理解は、それが主に貧弱なデザインを隠すことを目的としているということです。経験則として、レガシーコードのファサードのみが必要であると言えます。

また、このパターンは、主にEJB仕様（少なくとも2.xまで）が本質的に不十分なサービスレイヤー設計をもたらしたため、J2EEコアパターン（セッションファサード）として普及したと思います。

したがって、あなたの質問に対する私の答えは「はい」です。ファサードは、実際には、最初は適切に実装されていないサービスです。クライアントコードから複雑さを隠す必要がある場合、それは通常、サービスレイヤーではなく、ライブラリを提供することしかできなかったことを意味します。したがって、この場合、ファサードは実際にサービスレイヤーになります。

一方（適切なドメインレイヤーがあると仮定して）、単一のメソッド呼び出し（マクロ/エイリアスに似たもの）で複雑なフローを生成するオプションを実際に提供する必要がある場合、これは通常、アプリケーションレイヤーに配置する方が適切です。コアドメインではありません-レイヤリングの用語をドメイン駆動設計に切り替えました。ここでは、「データアクセス」または「サービス」レイヤはなく、「アプリケーション」、「ドメイン」、「インフラストラクチャ」があります。

于 2013-03-01T22:29:11.307 に答える
3

FACADEは、サブシステム内の多くのインターフェイスへの統一されたインターフェイスが必要な問題を解決するデザインパターンであるため、サブシステムを使いやすくする高レベルのインターフェイスを定義します。

ただし、サービスはリソースまたは一連のインターフェイス/オブジェクトへのアクセスを提供し、必ずしもそのようなアクセスを単純化するとは限りません。したがって、ファサードパターンを使用してサービスをより適切に設計できるため、クライアントがサービスの使用方法を理解するのを防ぐことができます。

于 2013-03-04T16:44:49.850 に答える
2

最初に注意することは、デザインパターンは、標準ソリューションでの一般的な（設計）問題の説明であるということです。場合によっては、すべての要件に適合する方法で問題を解決する方法がいくつかあります（たとえば、IteratorパターンとSingletonパターンには多数の異なる実装があります。たとえば、動作を確認Alexandrescuし、標準のGoFソリューションと比較します。 ）、場合によっては、同じ（コード）ソリューションで異なるパターンがあります（たとえば、GoFブックのCompositeパターンとDecoratorパターンのクラス図を比較してください）。

GoFによると、ファサードパターンの目的は次のとおりです（文字通りの引用）。

サブシステム内の一連のインターフェースに統合インターフェースを提供します。Facadeは、サブシステムを使いやすくするためのより高いレベルのインターフェースを定義します。

サービスは、特定の機能を備えた単一の上位レベルのインターフェースをユーザーに提供することを目的としています。サービスは厳密に言えば定義上ではないため、必ずしもファサードになるとは限りません。unified interface to a set of interfaces in a subsystem.

しかし、私たちはそれよりもうまくやることができます

あなたの質問は、パターンが「類似」しているかどうかでした。パターンAがBに等しく、パターンBがAに等しい場合に、それらが「類似」していると見なす場合、2つの質問に答える必要があります。

質問Service1 Facade：？_ サービスは確実に機能を公開する必要があり、この機能を公開する単一のインターフェースであることは間違いありません。機能は通常、小さな断片に分解されるため、サービスはファサードの基本的な要件に適合します。言い換えると、基盤となるインターフェイスを統合された「サービス」インターフェイスとして公開するという問題に直面し、ファサードパターンは要件に適合し、サービスの問題を解決するために使用されます。これに対する答えはイエスです。

質問2 Facade：？_ Serviceサービスは通常、再利用可能で、関連付けられていない、疎結合の機能ユニットとして設計されています。コンポーネントは通常、SOAPやWCFなどのTCP / IPインターフェイスに依存しているため、コンポーネント間の通信について考えることはサービスにとって重要です。これはまた、機能がパラダイムにより厳密に適合するように書き直されることが多く、パターンのパフォーマンス要件によってservices暗黙的に駆動されることを追加することも意味します。ファサードには、この追加の要件はありません。言い換えれば、ファサードはサービスではありません。

正確には、これらの概念は密接に関連していますが、同じではありません。

しかし、私たちはもっとうまくやることができます

この考え方は、サービスがファサードの拡張バージョンであるかどうかという疑問を提起しますか？それは、サービスがファサードのすべての要件を満たし、その上に拡張されている場合です。

GoFによる説明をよく読むと、答えは「はい」です。つまり、1つの条件が満たされた場合、サービスはサブシステムを公開する必要があります。実際には、この条件は通常は当てはまると思います。または、サービスを過剰に設計していると思います。厳密に言えば、これは厳しい制限ではないと思います。

于 2013-02-27T15:31:19.963 に答える
2

通常、これらの用語は特定のコンテキストで使用されます。

  • 「ファサード」の一般的な使用状況：アプリケーションの複雑な部分（サードパーティのライブラリなど）用のシンプルなAPI

  • 「サービス」コンテキスト：システム内のビジネスエンティティのロックを解除して表示します。（SOA、DAO、セキュリティなど）

パターンは進化する言語として見ることができます。それぞれのパターンには独自の歴史と文脈があり、完璧な終わりとは思えませんでした。クラスがサービスとファサードとして同時に表示される場合もあれば、そうでない場合もあります。

例：「サービス」という用語でサードパーティのAPIを呼び出すと、コンテキストが間違っているため、誤用と見なされる可能性があります。

于 2013-02-23T20:47:24.963 に答える
2

答える前に、何かを明確にしましょう。エンタープライズアプリケーションには、ファサード、サービスレイヤー、リモートファサードの3つの異なるものがあります。

ファサード-サブシステムをラップしている間もオブジェクトであり、UI（MVC）アプリケーションは通常同じプロセスに存在します。したがって、通信は通常のOOの方法で行われます。つまり、メソッドの呼び出し、プロパティの読み取り、イベントのリッスンです。

サービスレイヤー-ビジネスロジックレイヤーが成熟し、MVCが直接対話するには複雑すぎる場合、サービスレイヤーはそれらの間に配置されます。Service Layerは、MVCがビジネスロジックのラッパーとして使用するAPIです。これはリモートではなく、通信にワイヤが関与しないため、DTOを使用する必要はありません。

リモートファサード-（単純に、任意のリモートサービス）これはファサードとサービスレイヤーのハイブリッドです。リモートファサードは、システム上にある種のラッパー（およびファサードと呼びます）を分散境界として公開する場合に存在し始めます。理由の1つは、複数のUI（MVC）アプリケーションが同じリモートファサードを使用できるようにすることです。

-

比較：

ファサードとサービスレイヤー：どちらもサブシステムをラップしているため、類似しています。違いは、サービスレイヤーはUI（MVC）アプリケーションのニーズに重点を置いており、ビジネスロジックの操作を簡素化するための関数を公開していることです。一方、Facadeは、ビジネスロジックを簡素化する機能を公開していますが、UI（MVC）アプリケーションとの通信を必ずしも簡素化するわけではありません。

ファサードとリモートファサード（サービス？）：リモートファサードは通信メッセージとしてDTOを使用する必要があるため、明らかに異なります。リモートファサードを通常のオブジェクト（プロパティ、イベント）として使用する場合は、何らかのプロキシが必要になります。ただし、プロキシはとにかく実際のオブジェクト、つまりリモートファサードに対してDTOを使用します。

-

可能なフロー：

controller-facade-dao-疑わしいですが、それでも可能です。ファサードは通常、DALだけをラップするために使用されることはありません。サブシステムとして、さらに成熟したものがあるはずです。しかし、ファサードがビジネスロジックの一部である場合、そうです、これは可能です。それでも、サブシステムをより強調する必要があります。私にとって、DALラッピングはそれをファサードと呼ぶのに十分ではありません。

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-これは翻訳できると思います。

-

サービス（またはリモートファサード）はフローのどこにでも存在できることを忘れないでください。これは、配布のニーズによって決まります。

于 2013-03-01T18:30:43.687 に答える
1

サービスインターフェイスは通常、ビジネス上の懸念を表します。いくつかの操作を実行したり、いくつかの情報を取得したりします。サービスプロバイダーが内部バックエンドサービスのファサードとしてサービスを実装することは不合理ではありません-これは決して見られないでしょう。

ファサードは、サービスインターフェイスを含むいくつかの一般的なインターフェイスをラップしている場合があります。

たとえば、銀行口座のサービスインターフェイス（操作：銀行が送金する）と、ローカルの会計記録へのローカルAPI（送金する）があるとします。銀行のサービスインターフェイスを使用し、ローカルの小切手帳も管理する「お金の移動」操作でファサードを導入することができます。

于 2013-02-26T00:45:25.767 に答える
1

重要なのは「コンテキスト」です。ファサードとサービスは競合していません。

まず、MVCのコンテキストで「サービス」と「ファサード」について聞いたことがありません。

人々がサービスについて話すとき、それは外の世界にビジネスに意味のある行動を提供するシステムまたはコンポーネントについてです。「作業単位」（したがって、トランザクション）に関連する「サービス」が表示される場合があります。

サービスは、アプリケーションのいくつかの階層化アプローチのコンテキストでも使用されます。DAOの上にサービスがあります。サービスはDAOを介してデータにアクセスし、ビジネスロジックはサービスレイヤーに配置されます。

ファサードは通常、デザインパターンのコンテキストで使用され、「複雑な操作を非表示にして、単純な操作として公開する」ことに重点が置かれます。

ファサードはサービスである場合とそうでない場合があります（ファサードでの操作は作業単位を表していない場合がありますが、それでも有効なファサードです）。同様に、サービスはファサードである場合とそうでない場合があります（サービスは複雑なものを隠さない場合があります）操作しますが、それでもサービスです）。

繰り返しますが、重要なのは「コンテキスト」です。

たとえば、アプリケーションの階層化について話している場合、「XXXはDAOにアクセスするためのファサードです」と言うのは単純に不合理です。同様に、「デザインアプローチ」について話している場合は、ここでは「サービス」と呼ぶのではなく、「XXXは複数のバックエンドへのファサードです」と言う方が合理的です（XXXは実際にはサービスですが）。

于 2013-02-26T03:24:08.003 に答える
1

ええ、ファサードとサービスは完全に無関係ではありません。また、クライアントがサービスの多くの詳細に煩わされることがないように、サービスレイヤーをファサードとして実装することもあります。サービスの呼び出し/インターフェースが単純であるほど、クライアントコードは単純で簡単です。

マーティンファウラーは言う...

サービスレイヤーは、アプリケーションの境界[Cockburn PloP]と、クライアントレイヤーとのインターフェイスの観点から利用可能な一連の操作を定義します。これは、アプリケーションのビジネスロジックをカプセル化し、トランザクションを制御し、その操作の実装における応答を調整します。

そのため、サービスレイヤーはファサードとして使用されることがあります。

参照

于 2013-02-26T04:52:12.873 に答える
0

ファサードとサービスレイヤーには一種の類似点がありますが、どちらにも2つの異なる意味があります。簡単な例を使ってこれを説明しましょう。

新しいビジネスアプリケーションを作成するように求められたと想像してください。これには、チェックインアプリケーションを作成する必要がありますが、より多くの付加価値機能とポイントカード機能があります。

ユーザーが使用したい場合、アプリケーションはFacebookとFoursquareのチェックイン機能をサポートする必要があるとしましょう。一部のユーザーは、同じ機能を実行する複数のアプリケーションを使用したり、ソーシャル接続を削除したりすることを躊躇するため、この機能は非常に必要です。

高レベルのアイデアを得るには、次のリンクのサンプルAPIを参照してくださいhttps://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing

上記のABCファサードにあるチェックインAPIは、ファサードの使用例です。

サービスAPIに加えて、クライアントの選択に基づいたfacebookおよびfoursqureチェックイン機能も備えています。FacebookとfoursqureAPIには、特定の実装（SOAP、Restfulなど）とセキュリティ（OAuthなど）の要件などがあります。

これらのAPI（facebook、foursqure）の要件の1つを満たすには、さまざまな一連のタスクを実行する必要があります。これらは、チェックイン要件の異なるサブシステムになります。

したがって、ファサードの単純な使用法は、1つの単純な方法によってトリガーされる複数のサブシステムを満たすことです。

しかし、MngCheckinSvcにあるチェックインAPIである独自のAPIを検討するとします。これはサービスレイヤーAPIです。これは、アプリケーションのチェックイン要件を含むAPIです。これは、アプリケーションへのチェックイン要件を処理するために、MngCheckinSvcからのパブリックアクセスを提供するAPIです。

これには複雑な内部動作がありますが、それでもそれらのほとんどはアプリケーション固有のロジック実装になります。

このAPI（MngCheckinSvc.checkin（....））は、アプリケーションでのマーチャントチェックインを実行するために、さまざまなDAOのセット、内部API、他の内部サービスなどにアクセスする場合があります。

于 2013-03-03T11:59:57.870 に答える