エンティティの実装方法について

質問

たまたま、java で開発することになったので
このカテゴリーで質問します。
（どちらかというとオブジェクト指向に関する質問かも）

現在、RDBにアクセスする際の
エンティティクラスをjavaで作成しようと
しています。
で、エンティティの単位とは
どのような単位で作成するものかと悩んでいます。

具体的には、

売上明細　というテーブルがあったとして、
売上明細エンティティ　としては、売上明細の
レコードをそのまま取得できる形で考えていますが、
売上明細の集計情報を知りたいときは
その売上明細エンティティが集計情報を返すのか？
という意見が出ました。

その意見を出した人の論理では、売上明細エンティティは、
”売上明細”そのものであって、その情報を取得
するときには、集計だろうがどのような形でも
”売上明細”に関す る情報を返却するのが正しい
ということです。

わたしとしては、”売上明細”の集計ということで
あれば、それは既に別の実態であり、別のエンティティである
と考えるわけですが、どちらの理論がよいでしょうか

回答No.3

Healer99

多分質問者さんはEJBでのエンティティ詳細設計を指示されたと仮定して話を進めます。

最近の流れから言って、EJBという重いもので開発するのもどうかと思うのですが、それは質問者さんに関係ないでしょうから、以前経験したアドバイスを。

もちろんプロジェクトによってエンティティの定義は違いますが(ER図で言うエンティティは置いといて)、月別担当者別実績、とか、月別店舗別実績、とか、古い時代の考え方では、SQL文をこねくりまわして作っていた部分を、利用モジュール側がSQLを考えるのではなく、与えたパラメタでコレクション(Listとか)が返ってくる単位でメソッドを作成してあげればいいでしょう。

ですから、売上集計は売上明細とは別カテゴリだと思うのであれば、明細と集計のエンティティクラスを分ければいいのですし、売上結果としてひとつの単位で扱うことが多い(特に画面のラジオボタン程度の分岐でしかない)のであれば、ひとつのモジュールにしてしまっても構いません。

もっと明確な答えが欲しいのであれば、クラス図なり、ＥＲ図を設計した人に線引きを任せるべきであって、実装者が"技術的な部分でない"クラス分けを考えるのはおかしい話です。

もし質問者さんがまさに今設計しているのであれば、問題の回答はここよりも、設計レビューで出ると思われます。

回答No.2

unibon

RDB が絡むか絡まないかで、考えが変わってくると思います。
RDB が絡まない場合、純粋にオブジェクト指向の範疇で考えますと、この場合でもやっぱり、売上明細クラス自体に集計機能を持たせるか、それとも集計機能を外に出すか、という2つのやりかたのどちらにすれば良いかで悩みます。
巷の、初心者向けの書籍を見ると、売上明細クラスの中に集計機能を持たせることが多いようです。一方、私の個人的な好みとしては、外に出せるものはできるだけ外に出したほうが良いと思います。外部でできることをわざわざ内部でやる必要はありません。集計といっても、合計だけならまだしも、平均や標準偏差などの種類があります。これらのバリエーションが増えるたびにクラスのメソッドが増えるのは変だと考えます。
ただし RDB が絡むと話が変わってきます。集計である SUM や AVG 等は SQL の段階で済ませてしまうほうが高速になります。1レコードずつ SELECT して、それの合計をしても100倍位遅いだけで別に悪くはないですが、でも、それをやるのはやっぱり躊躇してしまいます。だから RDB が絡む場合は、集約機能は内包させることに落ち付くことが多いと思います。

回答No.1

noname#25358

ここでいう「エンティティ」とは何でしょうか？
　辞書上は「本体」とか「それそのもの」といった意味になります。
　なので、質問文を見ると「エンティティとは、データ自体を格納しておくテンポラリ領域である」と「エンティティとは、データを入出力するためのプログラムである」という２つの解釈が成り立ってしまい、あなたがどっちを意識しているのか分かりません。

　もし前者であれば、集計結果の出力形態が同じ場合、同じエンティティを使いまわすことが可能でしょう。
　ですが後者であれば、プログラムの形態そのものが変わってきますし、引数の内容も違ったものになります。またメソッド名も違ってくるでしょうから、エンティティは区別する必要があります。

　これは「理論的にどっちが正しいか」ではなく、「どっちがやりやすいか」で区別すべき問題です。