9

私が見たすべての MVC プロジェクトで、「サービス」クラスと「DAO」クラスは常に独自のインターフェイスを実装していました。しかし、ほとんどの場合、このインターフェイスが役立つ状況は見たことがありません。

これらの場合にインターフェイスを使用する理由はありますか? 「サービス」および「DAO」クラスでインターフェイスを使用しないと、どのような結果になる可能性がありますか? 私はどんな結果も想像できません。

4

5 に答える 5

3

Spring は Inversion of Control コンテナです。これは、ある意味では、使用するクラスの実装がアプリケーションではなく、その構成に依存することを意味します。UserRepositoryインスタンスを格納する必要があるクラスがあるUser場合、それは次のようになります

class UserService {
    @Autowired
    private UserRepository userRepository;
}

interface UserRepository {
    List<User> getUsers();
    User findUserBySIN(String SIN);
    List<User> getUsersInCountry(Long couyntryId);
}

そして、あなたはそれのために宣言されたBeanを持っているでしょう

<bean class="com.myapp.UserRepositoryHibernateImpl">
   ...
</bean>

この Bean はUserRepositoryHibernateImplを実装することに注意してくださいUserRepository。

将来のある時点で、Hibernate プロジェクトのサポートが終了し、Mybatis でのみ利用可能な機能が本当に必要になるため、実装を変更する必要があります。UserServiceクラスはインターフェイス型で宣言されたを使用しているためUserRepository、インターフェイスで表示されるメソッドのみがクラスに表示されます。したがって、実際のポリモーフィック タイプを変更してuserRepositoryも、残りのクライアント コードには影響しません。変更する必要があるのは (新しいクラスの作成を除く) だけです。

<bean class="com.myapp.future.UserRepositoryMyBatisImpl">
   ...
</bean>

アプリケーションは引き続き動作します。

于 2013-08-27T23:45:13.677 に答える
3

インターフェイスを支持する議論はたくさんあります。Google を参照してください。

他の人が言及したポイントに追加できます：

  1. DAO の実装を Hibernate から iBatis に変更したとします。実装ではなくインターフェイスへの依存性は、サービス層にとって大きな助けになります。
  2. AOP または JDK 動的プロキシを使用するプロキシを使用する場合、クラスはインターフェイスを実装する必要があります。これは CGLIB には当てはまりません。
  3. サービス層では、メソッドを他のクライアントに解放して呼び出したい場合は、実装よりも「契約としてのインターフェイス」を提供する方が理にかなっています。
  4. services.jar を daos.jar から分離したい場合は、daos にインターフェースを設定すると、daos.jar が変更された場合に、services.jar が再コンパイルされるのを防ぐことができます。

要するに、インターフェースがあればいいだけです！

于 2013-08-28T03:36:26.663 に答える
0

インターフェイスを早い段階で使用すると、アプリケーションはスケーラブルに対応できるようになります。インターフェイスを使用しないと、アプリケーションのスケーラビリティが犠牲になります。

于 2013-08-28T08:11:49.523 に答える
0

私は最近、まったく同じ質問を自問してきました.1つの実装クラスが存在することを知っていても、インターフェースを作成するのはばかげており、肥大化に追加されていると感じています（より実用的な言語を試したすべてのJavaプログラマーは、フィーリング）。これはまた別のコンパイル モジュールであり、多くの場合、内なる独断主義者を満足させるためにのみ作成されます。

Spring は、プログラマーがブロックを作成するだけで、フレームワークがそれをすべて組み立てる、モジュール/コンポーネント指向のフレームワークに進化したようです。これが、基準に一致する複数の Bean を持つことが問題であり、物事を複雑にする理由です (DI の目的を殺すような修飾子を使用することになります)。プログラマーは当然、必要な構成の量を最小限に抑えるために、型のあいまいさを回避しようとします。理想的には、特定のブロックが 1 つの「スロット」にのみ収まるようにします。

私の意見では、DI の最大の利点は、(構成 XML で宣言されたクラスの型を変更するだけで) 実装を簡単に変更できることではなく、依存関係を簡単に分離できるため、各コンポーネントを分離して簡単にテストできることです。 . そのためには、1 つの子インターフェイスは必要ありません。

クラスをリバース エンジニアリングしてそのインターフェイスを抽出するのは純粋に機械的な作業になるため、「別の実装を追加する必要がある場合」について心配する必要はありません。口論。

免責事項: 中小規模のアプリケーション開発者の意見。大規模なプロジェクトでは状況が変わると確信しています。

于 2013-08-28T23:05:58.877 に答える
0

インターフェイスベースの実装は、テスト スイートでそれらをモックするのに役立ちます。私たちのプロジェクトでは、サービス レイヤーをテストする際に、実際に DB に接続する代わりに、DAO をモックし、ハード コーディングされたデータを提供します。同じ議論がサービス層にも当てはまります。

于 2013-08-27T23:37:40.773 に答える