JPAはDAOを抹殺したのか？

Data Access Object(DAO)はアプリケーションとデータベースかファイルのような一つかそれ以上のデータストレージ装置間で共通のインターフェースを提供するコンポーネントである。

この性質に関する議論において異なる意見を持ったブロガー達が、それぞれの意見を主張している。このディスカッションを主導していた側のAdam Bien氏は、下記のように述べている。(source)

この使われ方がこれ以上シンプルになることはありえない。Entity Managerがビーンクラスに注入される。DAOパターンは実はジェネラルデータアクセスにおいてはもう何も面白いことはないのだが、保存されたプロシージャやフラットファイル等からデータにアクセスするのに必要とされる。

ここ何週間かに渡って特にEJB3とそのEntity Managerの台頭に伴うDAOパターンの終わりに関するブログへの投稿と声明があった。これらのプロポーサルではEntityManagerをDAOを介してデータアクセスロジックをカプセル化する代わりに、ビジネス指向サービス内で直接EntityManagerを使用することを提案している。私はこの意見に強く反対する。

• データアクセスロジックとビジネスロジックを混合
• 単一責任の原則への違反
• ビジネスロジックとインフラの混合
• 開放閉鎖原則への違反
• データアクセスストラテジーのユニフォームスタイル欠如

DAOのパターンは"Data Service Layer"として考えられ、それはある特定、そして頻繁に独占のデータアクセス認識をカプセル化するものである。そのようなレイヤーの本当の目的は、特定のデータベースかORマッパーを独立させることとなるだろう。しかしながら以前でさえも私はデータベースの入れ替え、またはSQLをLDAPに変更さえし たことがない。 レガシーシステムがレイヤーであったことが必須である場合もある。私の意見としては、DAOはJava EE 5で最適化することができる。（それが消えてなくなるまで！）DAOのインターフェース、実装と実際のSession Beanが崩壊する可能性もある。もちろんEJB3上で依存するのはあまりいい考えではないと言うこともできる。がしかしなぜそれはいけないのだろうか。@Statelessアノテーションだけがその理由だろうか？

それぞれの投稿にはこのディスカッションに関してたくさんのコメントがあった。WarpedJavaGuy氏は下記のようにコメントしている(source)。

DAOの概念はすぐにはなくならないだろう。保持性とデータアクセスは一体ではなく異なるものである。

Java EEはボイラープレートコードで大変苦戦しているのでデザインパターンがアンチパターン、複雑性等になり、だから私はEJB上で EntityManagerCRUD作動を使用するのも問題はない。シンプルなアプリケーションにおいてはDAOパターンをスキップする。

全体的に一般的な世論としてはそれはアプリケーションと条件によるということだ。Adam氏は下記のようにまとめている(source)。

私は、それはアプリケーションが実にどれだけ複雑であるかということに依存していると考える。