8

典型的な n 層 Java アプリケーションがあり、データ アクセス層に FooDAO および FooDAOImpl 型の DAO があることに気付きました。私は 2 つの必要性を正当化しようとしていましたが、これが私の分析です。

  1. 同じインターフェースに複数の実装がある場合、抽象化が役に立ちます。しかし、DAOImpl (iBATIS など) に使用するフレームワークを既に選択した場合、それは本当に必要なのでしょうか?
  2. Spring 経由のプロキシを支援します。私が収集したものから、インターフェースを持つクラスは、インターフェースを持たないクラス (cglib ルートが選択される) よりも簡単に (JdkProxy ルートに行く) プロキシすることができ、プロキシされるクラスのサブクラスがあります。サブクラス化には、プロキシするクラスが final であるか、デフォルトのコンストラクターがない場合に問題があります。どちらも、データ アクセス層ではほとんどありません。以前はパフォーマンスが要因でしたが、私が聞いたところによると、もはや心配する必要はありません。
  3. あざけるのを手伝ってください。インターフェイスを持つクラスは、モック フレームワークによるモックに適しています。私はこれを聞いたことがありますが、実際に見たことはありません.

これらの点を考えると、単純な FooDAO で十分なはずの FooDAO と FooDAOImpl を個別に用意する必要はないと思います。私が言及した点を自由に修正してください。

前もって感謝します！

4

3 に答える 3

2

#3 を Mockito で試してみたところ、インターフェースなしで POJO をうまくモックできました。#1 と #2 に対して言及された議論により、私は今のところ DAO と DAOImpl を別々に使用しない傾向があります。他の比較ポイントを自由に追加してください。

于 2012-07-10T16:09:05.957 に答える
1

4 つ目の理由がわかりました。

  • 実装の詳細を非表示

たとえば、チーム、ソフトウェアの予想される寿命、または将来予想される変更の量に応じて、実装が 1 つしかない場合でも、可能な限り非表示にすることには価値があります。

于 2012-07-04T08:25:59.337 に答える
0

FooDAO単一の実装を持つインターフェースを持つことFooDAOImplは、一般的にアンチパターンだと思います。明確な理由がない限り、より単純な解決策 (DAO 用の個別のインターフェイスなし) の方がはるかに望ましいです (ここではそうではないようです)。

個人的には、さらに進んで、DAO を持つことは最善の選択ではないと言いたいと思います。私は、Hibernate や JPA などの ORM API の上に単一の永続化ファサード クラスを実装することを好みます。たぶんiBATISはそれには低レベルすぎる。

于 2012-07-10T19:08:47.393 に答える