問題の仕様を考えると、それがデータベース設計の問題なのか、クラス設計（オブジェクト指向設計）の問題なのかをどのように判断するのでしょうか。
質問する
51 次
3 に答える
2
私の頭に浮かぶのは、OOPでは、クラス（オブジェクト）にはメソッドが含まれているのに対し、データベースは単なる関係と値のコレクションであるということです。したがって：
問題は、仕様の「もの」が互いにどのように関連しているかということであると言えば、データベース設計の問題があります。
仕様の「もの」で何ができるかということであれば、オブジェクト指向プログラミングに沿ってさらにモデリングすることになります。
于 2012-11-07T14:58:45.227 に答える
1
データベースを使用してドメインオブジェクトを作成している場合は、両方です。データベース設計とクラス設計は2つの異なるものであり、データベースとクラスを使用している場合は両方が必要です。どちらかを選ぶわけではありません。
ここでORMが役立ちます。データ層がデータベースから情報を取得する場合、一般的なアプローチは、リレーショナルデータをドメインオブジェクトに変換し、それをビジネスロジック層に渡して、アプリケーションの残りの部分がリレーショナルモデルではなくドメインオブジェクトを処理できるようにすることです。 。
次に、ORMはデータを永続化するときに反対のことを行います。つまり、ドメインエンティティを取得し、データベースに保存できるリレーショナル構造に戻します。
注：ここではリレーショナルデータベースを想定しています。そうでない場合は、使用している永続層のタイプをリレーショナルに置き換えてください。
于 2012-11-07T14:53:10.507 に答える
1
データベース指向の問題として扱われるべき仕様は、構造化されたデータ型の操作に焦点を合わせたものだけだと思います。仕様が「顧客レコードの保存」、「注文レコードの削除」、「レコード一致仕様の価格の値を12から33に変更する」に関するものであれば、データベースプロジェクトがあります。
私が働いていたCobolチームがシステム~~アナキスト~~アナリストを雇って以来、そのような問題の仕様を見たことがありません。それ以来私が取り組んできたほとんどすべてのプロジェクトには、データの保存方法ではなく、データの意味に関する要件がありました。
「ユーザーは顧客を作成できます。顧客は注文できます。注文には製品が含まれます。注文には配送方法、支払い方法、ステータスがあります。ステータスはビジネスプロセスに従います」という要件が発生した場合、OOの問題が発生します。おそらくストレージメカニズムが必要ですが、データベースは優れた選択肢ですが、構造化されたデータ型と関係を作成するだけでは実装できないビジネスロジックがあります。
于 2012-11-07T15:22:33.383 に答える