私は2つのテーブルを持っています。
注文 - 列 OrderID、OrderStatusID を持つ
OrderStatus - 列を持つ OrderStatusID、説明
データベースを呼び出し、コードで使用するためにそのプロパティを入力する Order オブジェクトがあります。現在、Order.OrderStatusID にアクセスできますが、アプリケーションでは「説明」フィールドにアクセスする必要があります。
優れた OO 設計でこれをどのようにエレガントに処理しますか?
私は2つのテーブルを持っています。
注文 - 列 OrderID、OrderStatusID を持つ
OrderStatus - 列を持つ OrderStatusID、説明
データベースを呼び出し、コードで使用するためにそのプロパティを入力する Order オブジェクトがあります。現在、Order.OrderStatusID にアクセスできますが、アプリケーションでは「説明」フィールドにアクセスする必要があります。
優れた OO 設計でこれをどのようにエレガントに処理しますか?
通常、私はルックアップをValueオブジェクトとして処理することを好みます。NullObjectパターンも使用します。
public class Order {
private int statusID;
public OrderStatus Status {
get {
return OrderStatus.Resolve(statusID);
}
set {
statusID = value != null ? value.ID : null;
}
}
}
public class OrderStatus {
public static OrderStatus Resolve(int statusID)
{
OrderStatus status = null;
// read from cache or DB
...
// if not found return Null object
if (status == null)
status = new OrderStatus(null, string.Empty);
return status;
}
}
私が現在使用しているシステムは、他のビジネス オブジェクトのインスタンスを作成し、ID を設定します。他のビジネス オブジェクトは、使用時に取得されます。例えば
注文のプロパティ
int OrderId = 5
int OrderStatusId = 3
OrderStatus OrderStatus_ref
{
get
{
if OrderStatus_ref == null
OrderStatus_ref = new OrderStatus(OrderStatusId)
return OrderStatus_ref
}
}
とにかくそれが一般的な考えです。
Order と OrderStatus は 1 対 1 の関係ですか? 別の OrderStatus テーブルは実際には必要ないと主張するので、なぜ OrderStatus テーブルを使用するのかという目的に依存すると思いますか?
基本的に、このテーブルで提供されるのは、注文ステータスの説明を変更する機能だけです。コード内から、定義済みの OrderStatusID (シード データから?) または説明に従ってコードを記述します。この場合、Order テーブルに、整数であり、列挙型にマップできる OrderStatus 列が含まれていないのはなぜですか?
OrderStatus テーブルへの Join を使用して SQL select ステートメントを使用し、各テーブルから必要な列を含めることができます...
Select O.OrderId, O.OrderStatusId, S.Descriptiuon
From Order O
Join OrderStatus S
On S.OrderStatusId = O.OrderStatusId
Where OrderId = 23 -- or whatever
私の注文オブジェクトには、ステータスの説明フィールド (読み取り専用 [非内部クラスへ]) と、他の同様のフィールドが含まれる可能性があります。
内部では、私のゲッター (例: LoadByID、LoadAll など) は、これらの記述フィールドをすべて含むビュー (例: OrdersView) を使用する可能性があります。これらの説明フィールドは読み取り専用であるため、変更をデータベースに保存できると考えて、これらのフィールドを誤って設定することはありません。