QA@IT
«回答へ戻る

回答を投稿

皆さん、様々なご意見ありがとうございました。
皆さんのご意見を私なりに統合しますと、テーブル単位のDAO、サービス単位のDAOどちらを使うか?というよりも併用してよい、ということになるかと思います(当然システム内では共通設計にする必要がありますが)。
併用すると、サービス単位DAOからテーブル単位DAOを呼びだす形になり、SQLの共通利用が最も高められると思われます。デメリットとしては数多くのDAOクラスが必要となるため、DAOの自動生成等を行わないと余計に工数がかかる可能性があること。

ここでもう一点、皆さんにご意見を聞かせていただきたいのですが、
トランザクション処理を含むビジネスロジックをどこに書かれているのでしょうか?
DIやAOPは使わない開発の場合です。

1.ドメインクラスに記述
【メリット】
オブジェクト指向としてはドメインクラスにビジネスロジックを持たせることが正しい。
【デメリット】
POJOとして考えた場合、再利用できないデータベースアクセスが入るのは思想に反している。単体テストが簡単にできない。

2.ビジネスロジッククラスに記述
【メリット】
設計やクラス階層がわかりやすく、他のMVCクラスがビジネスロジッククラス以外とは関連が無い状態になる。
【デメリット】
オブジェクト指向的な設計ではない。

また、サービス単位のDAOの認識もそれぞれ若干異なっているかと思います。私の場合はトランザクション処理も含めたビジネスロジッククラスと同じ意味で使っていましたが、皆さんはどのような認識でしょうか?

投稿者:どらねこ

皆さん、様々なご意見ありがとうございました。
皆さんのご意見を私なりに統合しますと、テーブル単位のDAO、サービス単位のDAOどちらを使うか?というよりも併用してよい、ということになるかと思います(当然システム内では共通設計にする必要がありますが)。
併用すると、サービス単位DAOからテーブル単位DAOを呼びだす形になり、SQLの共通利用が最も高められると思われます。デメリットとしては数多くのDAOクラスが必要となるため、DAOの自動生成等を行わないと余計に工数がかかる可能性があること。

ここでもう一点、皆さんにご意見を聞かせていただきたいのですが、
トランザクション処理を含むビジネスロジックをどこに書かれているのでしょうか?
DIやAOPは使わない開発の場合です。

1.ドメインクラスに記述
【メリット】 
オブジェクト指向としてはドメインクラスにビジネスロジックを持たせることが正しい。
【デメリット】 
POJOとして考えた場合、再利用できないデータベースアクセスが入るのは思想に反している。単体テストが簡単にできない。

2.ビジネスロジッククラスに記述
【メリット】 
設計やクラス階層がわかりやすく、他のMVCクラスがビジネスロジッククラス以外とは関連が無い状態になる。
【デメリット】 
オブジェクト指向的な設計ではない。

また、サービス単位のDAOの認識もそれぞれ若干異なっているかと思います。私の場合はトランザクション処理も含めたビジネスロジッククラスと同じ意味で使っていましたが、皆さんはどのような認識でしょうか?


投稿者:どらねこ