2009-06-20 6 views
4

私はWebアプリケーション用のモデルを作成しています。テーブルには主キーとしてのIDフィールドがあります。私の質問は、IDをクラスのプロパティとして定義する必要があるかどうかです。データベースに保存されているオブジェクトのプロパティとしてIDを含めるべきですか?

オブジェクトをテーブル構造の表現として扱うべきかどうか、またはオブジェクトを永続化する手段としてテーブルを扱うべきかどうかは私には分かりません。

私が前のルートをとった場合、IDはデータベーステーブルの構造の一部であるためプロパティになりますが、私が後者のアプローチをとった場合、IDはデータベースに属するメタデータのピースとして見ることができます厳密にはオブジェクトモデルの一部ではありません。

そして、私たちは中盤に到着します。 IDは実際に私がモデル化しようとしているオブジェクトの一部ではありませんが、オブジェクトをデータベースから取得して永続化し、データベース内のオブジェクトのIDは、システムでは、IDが使用されている対話を容易にするためにそれを含めることが有益かもしれません。

私はソロ開発者ですので、私は本当に問題基本的に

+0

あなたのプラットフォームが何であるかについては言及しませんが、 – gubby

+0

@jgubbyこれはホスティングのコストに大きく左右されますが、可能であればASP.NET MVCを使用したいと思っています。 – Crippledsmurf

答えて

8

上の他のいくつかの、おそらくより多くの経験豊富な展望たい:はい。 すべての永続フレームワーク(Hibernate、Ibatisを含む)は、IDがオブジェクト上にあることを要求します。

私はメタデータについてのあなたの点を理解していますが、データベースのオブジェクトは、データベースと同じ方法でIDを実際に導出する必要があります。通常はint主キーです。それから、オブジェクトレベルの等価性を導出する必要があります。

複合名のような主キー(姓と名など)がある場合があります。この場合、主キーはオブジェクトのアイデンティティの一部であるため 'メタデータ'になりません。

私は、通常、データベースのオブジェクトのID列を予約します。私の意見では、「顧客対応」の目的でそれを使用する(たとえば、プライマリキーIDを顧客番号として使用する)場合、後でいつでも足で自分を撃ちます。

+1

最後のポイントは実際にはデータベース設計だけです。 (プライマリ)キーは決して他の意味を持つべきではありません。意味のあるデータには変更の可能性があります。キーの場合は、問題が発生した場合には問題を尋ねるだけです。これはユーザーに公開できないという意味ではありませんが、ほとんどの人が "ユーザーID 69573"よりも "jgubby"の方がはるかに覚えやすくなるため、これは一般的に避けられます。 –

+0

+1、それは実際には私のユーザーIDです。 – gubby

5

新しいデータを排他的に追加するのではなく、既存のデータを変更した場合は、PKが必要です。それ以外の場合は、DB内でどのレコードを変更するのか分かりません。

+0

私はあなたの後に私の答えを追加し続ける... wierd :)。しかし、良い答え! –

+0

それは私が完全には考慮していなかった点ですが、現時点ではコンテンツの編集は許可されませんが、後で必要になったときに追加したいと思ったのではなく、 – Crippledsmurf

1

私はプロパティとしてIDを含める。オブジェクトにシンプルな一意識別子を持たせることは、オブジェクトがデータベースに永続化されているかどうかにかかわらず、しばしば非常に便利です。また、データベースのクエリをより簡単にすることができます。

私はテーブルがオブジェクトを永続化する手段にすぎないと言いますが、オブジェクトがIDを持つことはできません。

2

オブジェクトにはIDが必要です。それは不可欠です。

例として与えるための最も簡単な使用ケースは平等をテストしている:他に

public bool Equals(Object a, Object b) { return {a.ID = b.ID}; } 

ものは、エラーの対象となり、そしてあなたは、主キー違反の取得を開始するか、既存のデータを上書き起動したとき、あなたはそれを見つけるだろう。反論することで

は、あなたがオブジェクトにIDを持っていないと言います。オブジェクトを変更してデータベースからIDを取得しないと、更新するレコードはどのように分かりますか?


同時に、あなたは私が言及操作がオブジェクトインスタンスには本当にプライベートなので、IDは、必ずしも公共財産である必要はないことに注意してください。

1

は、私はいつもは二つの主要な理由のための私のオブジェクトにIDを公開し、テーブルにはそうであっても、オブジェクトを永続化するための手段であるが、その考え方の非常に多くのです:

  1. データベースIDは、クラス内(テーブル単位のシリアル/オートナンバーIDを使用している場合)または普遍的な(ID-to-classの別のID-クラスを維持している場合)オブジェクトを一意に識別する最も便利な方法です。マッピング)。 Webアプリケーションのコンテキストでは、対象オブジェクトを識別するのに十分な情報をまとめて複数のフィールドを用意する必要がなく、フォームで<input type=hidden name=id value=12345>を指定するだけで、すべての作業が大幅に簡素化され、効率的になります(悪い場合は、十分な識別情報を1つの文字列に連結し、フォームが提出されたときにそれを元に戻します)。

  2. 正当なデータベース構造を維持するためには、IDを持っている必要があります。理由はありません。ではなく、が公開されています。

+0

それを公開しない私の理由は、IDがメタデータであり、文字通りの意味でオブジェクトの一部ではないという議論でした。 ここでの回答を読んだのですが、この意見は、データベースとオブジェクトの間の必要な関係を説明することができないため、多少近視眼的です。 – Crippledsmurf

1

オブジェクトのIDは読み取り専用かどうかを確認してください。私の考えでは、IDは決して変更されません(データベース内のレコードを一意に識別するため)。
新しいオブジェクトを作成するとき(IDがまだ設定されていない)、新しく作成されたIDを返すストアドプロシージャを使用してデータベースに保存し、IDプロパティを読み取った場合にオブジェクトに戻す方法-のみ?

例:
従業員=新しいEmployee();
employee.FirstName = "John";
employee.LastName = "Smith";

EmployeeDAL.Save(employee);

このプロパティが読み取り専用の場合、EmployeeIdプロパティはEmployeeIdプロパティを更新します(実際にデータベースに接続して新しい従業員を保存すると、実際には変更されません)。作成した)。

+0

これはそれ自体の権利ではほとんど別個の質問です。 IDプロパティが読み取り専用である必要があるかどうかの回答では、一般的に、私はそれがあなたが述べた理由ですべきだと信じています。プロパティは読み取り専用で、DALは実際に渡されたオブジェクトに基づいて別のオブジェクトを作成したり、DAL – Crippledsmurf

+0

に応じてリフレクションを使用して値を変更したりすることがあります。オブジェクトに50のプロパティがあるとします。この場合、新しいものを作成し、すべてのプロパティの値をコピーするだけでIDフィールドを更新することができます。 私の考えでは、DALはそれを更新するためにIDフィールドへの書き込みアクセス権を持っていなければなりませんが、IDフィールドは他の世界では読み取り専用でなければなりません。これは、オブジェクトが基になっているクラスとDALが2つの別々のアセンブリにある場合(実装する必要がある場合)に実装するのが少し面倒です。 – Anthony

関連する問題