ビジネスオブジェクトには他のオブジェクトへの参照が含まれている必要があります（idフィールドには別のデータベースレコードが参照されるため）か、実際のオブジェクトのインスタンスを持つ必要があります。例えばビジネスオブジェクトにオブジェクトまたは参照を含める必要がありますか？
：
public class Company
{
public int Id { get; set; }
public CompanyStatus Status { get; set; }
}
または
public class Company
{
public int Id { get; set; }
public int Status { get; set; }
}
私の理解では、具体的なクラスではなく、インターフェイスへの参照を含める必要があります。
public class Company
{
public int Id { get; set; }
public ICompanyStatus Status { get; set; }
}
例のCompanyStatusの具体的な実装がクラスであり、列挙型ではないと仮定します。
私はここ数年、このアプローチに非常に満足しています。おそらく、実行時に依存関係（http://en.wikipedia.org/wiki/Dependency_injection）を注入できるという事実と関係しているかもしれません。 – FOR
@ Rake36：なぜ具体的なクラスではなく、インターフェイスを参照するのですか？ –
場合によっては、それが好ましい。スワッピングの実装を可能にし、特定のORMテクノロジに役立ちます。実際には、ビジネスオブジェクトのコントラクトに重点を置いています。 –
あなたがC＃の話をしている場合は、そのオブジェクトを集約すると、あなたはそれへの参照を格納していることを意味します。
データによって異なります。一部のデータは元のオブジェクトのコピーとして保存する必要があり、一部は参照にする必要があります。
おそらく、いつ、どこで2つが発生するかについて詳しく説明することができます。 –
OO形式でビジネスレイヤオブジェクトを作成するときは、オブジェクトを直接使用する必要があります。
あなたの例では、int Statusはどこかに保存されているCompanyStatusオブジェクトのIDを参照していますか？その場合、データレイヤの関心事が増えているように感じられます。通常、データレイヤとビジネスレイヤを混在させないようにするのが最善です。
DALがCompanyIdをデータベースから「CompanyStatus」または実際には「ICompanyStatus」に変換する必要があると思うのは正しいですが、これは正しいですか？ –
うん、まさに。そのように分割すると、DALとビジネスレイヤーを個別に変更する柔軟性がさらに向上します。 –
ここで選択する言語に注意してください。 – GregC
例はC＃であることを示しています。 – Noldorin
@Anthony：何か明確にしていただけますか？あなたの2つの例の違いは何ですか？ 2番目の "Status"はStatusテーブルの整数の外部キーを意味しますか？ –