3

私の経験では、これはどのように見られたスプリングコントローラーが使用されたかです：プレゼンテーション層にあるタイプの値を返すスプリングコントローラーを定義します。コントローラ要求マッピングメソッドは、サービスレイヤを呼び出します。サービス層自体は、インターフェースと実装で構成されています。サービスインターフェイスには常に1つのメソッドしか含まれていないため、「1つの形式」を一貫して保持するため、実際には多態的ではありません。サービスの実装は、おそらくDAOから何らかのデータにアクセスし、それをコントローラーに返す場合があります。コントローラは、返されるデータをプレゼンテーション層に戻す前に、このデータをわずかに修正する場合があります。

この場合、インターフェースを持つことのこのポイントは何ですか？複数のコントローラーから呼び出されるSpringServiceの実装に遭遇したことはありませんが、なぜインターフェイスなのですか？

サービス実装のアクションを実行するヘルパーコントローラークラスを使用する方が理にかなっていますか？

4

4 に答える 4

4

サービス層を使用すると、ビジネスロジックをコントローラータスクから論理的に分離できるため、有益です。Serviceクラスでは、などの特定の側面に関連するビジネスロジックをカプセル化できますPaymentService。PaymentServiceでは、のようなさまざまなメソッドを実装できますcardPayment(), paypalPayment(), refund()。さまざまなコントローラーが単一のサービスを使用します。さらに、サービスレイヤーはコードの再利用にも便利です。

後でいくつかのAOP機能を使用することにした場合、コードを変更せずにコントローラーとサービスの間にロジック（ロギングなど）を追加する場合は、インターフェイスを使用すると便利です。

于 2013-02-22T16:24:51.727 に答える
1

その通りです。サービスインターフェイスはユースケース固有である傾向がありますが、インターフェイスを作成する理由はいくつかあります。

  • そのちょうど良い習慣。たとえば、サービスの新しい実装でスワップできます。IDEを介してインターフェイスを抽出するためのコストや悪影響は実際にはありません。
  • トランザクション管理、セキュリティ上の懸念などにDynamicProxiesを使用できるようにします。動的プロキシはcglibプロキシよりも高速であり、デフォルトのコンストラクターを必要としません。。。また、過去には、コンクリートオブジェクトのプロキシが不安定になることがありましたが、DynamicProxiesは非常に単純で、問題が発生する可能性はほとんどありません。
  • ルーク・テイラーが述べたように、それはテストを単純化します。
于 2013-02-23T01:26:10.453 に答える
0

インターフェイスを使用する理由の1つは、テストのためです。コントローラを個別にテストする場合は、モックまたはスタブにインターフェイスを使用するのが最も理にかなっています。

于 2013-02-22T16:24:08.270 に答える
0

インターフェイスを使用すると、実装でビジネスロジックを維持でき、リモートでの公開方法を気にする必要がないため、インターフェイスは良いアイデアだと思います。インターフェイスをRESTまたはSOAPサービス、EJB、またはその他の必要なものにすることができます。データを出し入れしても、ビジネスロジックは変わりません。そしてそれはそれをコントローラーから完全に分離します。そのサービスをWeb層の外部で使用する場合があります。

于 2013-02-23T01:47:10.627 に答える