サービスとDAOとの関係は1対1か1対多でなければなりませんか？

Question

この質問を引き起こしたコードは、4つの異なるDAOを含む私の会社のコードベースのサービスでした。私は、このサービスがまったく別のサービスに属する方法と融合しているのを見るまで、このことについてはあまり考えなかった。このサービス内でこれらの不当なメソッドを作成した理由は、必要なDAOがこのServiceクラスのプライベートメンバーであったからです。

この開発者は不正行為ですか、ほとんどの場合、サービスクラスごとに複数のDAOを持つのは間違っていますか？

注：同じデータベース内にすべて含まれている限り、サービスクラスごとに複数のDAOを持つことは妥当と思われます。しかし、複数のデータベースからDAOを取得すると、問題が発生する可能性があります。

Answer 1

サービスクラスごとに複数のDAOがあることは間違いありません。私が何年も前にWeb開発を始めたとき、DAOというサービスは1つしかありませんでした。なぜなら、これは最も論理的で最も単純なアプローチだったからです。その後、私は、異なるサービスを提供するDAOの間で同様のAPIが存在する問題を見始めました。だから、私の「未熟な」解決策は、これらの共通APIをいくつかの親DAOに昇格させてこれらのDAOに継承させることでした。プロジェクトが成長すると、子どもの80％がそのAPIを必要とするが、20％はそうではないが、それでも同じ親から継承する状況があるため、継承がもう意味をなさないDAOは他の同様のAPIを共有しているためです。あなたはここで問題を見る？つまり、Javaでは1つの親からしか継承できないため、最初は継承の原則に完全に違反する親DAOのDAOの「大部分」によって使用される可能性のあるAPIを詰め込むことになりました。

現在、すべてのDAOクラスには特定の責任/タスクがあります。 DAOが別のDAOを呼び出すことは大丈夫です（たとえば、LoggingDAOはほとんどのDAOでユーザーアクションを記録するために使用されます）。このように、特定のサービスを提供する1つのDAOを持つ代わりに、DAOはサービスに役立つ操作のリストを提供します。サービスは、タスクを達成するために必要なDAOを「使用」します。

この説明は役立ちます。

Answer 2

DAOを分割するのが理にかなっている限り、1対多のものは問題ありません。

私はそれがDAOを分割することは理にかなっていると考えることができた理由のカップル：

• 異なるデータベース。アカウントと販売データベースを扱う場合は、DAOをSalesDAOとAccountingDAOに分けたい場合があります。これにより、保守が容易になります。
• 再利用。いくつかの場所で再利用できるいくつかの方法があり、それらを分割するだけでより良い再利用が可能になります。

Answer 3

私が勤めていた会社では、サービスがコントローラと呼ばれ、コントローラーが別のレイヤーを呼び出すことができたが、それはDAOを呼び出すという素晴らしいデザインでした。

これは、高次関数を実行するために複数のDAOを呼び出すことができるアクセスレベルを持っていたため、注文をしたい場合は複数のテーブルを呼び出す必要がありますコントローラはdoOrderメソッドを呼び出します。

各レイヤーをテストすることができるので、分離感覚が保たれ、単体テストが簡単になりました。

サービスが複数のDAOを呼び出すことができる場合は、サービスレイヤをより複雑にするため、単体テストが難しくなる可能性があります。

レイヤをデザインするときは、新しいレイヤを作成してデザインを簡略化し、バグを発見したり、バグを防ぐことができるかどうかを見てください。

UPDATE：

不足している層は、コーディネーターがあって、ルールは各コーディネータは1 DAOに対処し、必要に応じた任意の変換を行うことができますが、ビジネス・ロジックは、コントローラにあったということでした。したがって、コーディネーターは他のコーディネーターと話をして情報を得ることができ、コーディネーターはDAOに行くことができます。

Answer 4

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

DAOの上の量は、単に基礎となる情報源に依存して！