私がサポートするのに役立つアプリケーションは、それほど大きくない、表面的にn階層のプロジェクトですが、実際のビジネスオブジェクトはありません。私たちのチームが "ビジネスオブジェクト"と呼んでいるのは、実際にはデータベース行の周りに自動生成されたラッパーだけで、実際のビジネスロジックはすべてWeb UIコードと混在しています。新しい機能性については、私たちのチームがビジネスエンティティのデータとビヘイビアを真に表現するオブジェクトのコーディングを開始し、UIからビジネスロジックを可能な限り排除することを本当に望んでいます。しかし、関係をどのようにモデル化すべきかについていくつかの矛盾があります。アソシエーション：IDまたはオブジェクト参照を使用しますか？
ここでは、ドメインを大幅に単純化するために、PersonとTasksがあるとします。各タスクには担当者が割り当てられています。
public class Person
{
public int ID { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
タスクはどのようにモデル化されるべきですか？
public class Task
{
public int ID { get; set; }
public string Title { get; set; }
public int AssignedPersonID { get; set; }
}
OR
public class Task
{
public int ID { get; set; }
public string Title { get; set; }
public Person AssignedPerson { get; set; }
}
ウェブUIをコーディングするより多くの時間を費やすものは、人が自分のIDによって参照される以前に、欲しいです。彼らは、別のPersonがタスクに割り当てられている場合、task.AssignedPersonID（新しいIDはUIのドロップダウンリストから簡単に利用可能）を変更してデータベースに書き込む方がよいと主張しています。私にとってこれは今やっているアプローチと変わりはありません。それは実際のビジネスモデルよりもデータベース行を反映しています。彼らは、より多くのコードがあり、対応するPersonインスタンスをインスタンス化してから、task.AssignedPersonを設定する必要があり、最終結果（タスクテーブルのAssignedPersonID列が更新されたこと）がまったく同じである場合、
オブジェクト指向の観点から、ここでどのようなアプローチが望ましいでしょうか？
用語に関する混乱にごめんなさい。継承に関しては、私にとって最も自然になる用語は「基本クラス」と「サブクラス」であり、継承のコンテキストでは「親」と「子」は考慮しませんでした。これは私の質問に関連してオンラインで情報を見つけるのが難しかったことのいくつかを説明するかもしれない。 – Mark42
問題ありません。それらも非常に一般的です。私たちはプログラマーとして、本当に多くの場所で専門用語を混乱させました。サブクラス、派生クラス、子クラス、スーパークラス、ベースクラス、親クラス...大きな問題になる可能性があります。私が言ったように、あなたの質問は実際には本当に良いものです。 – rbwhitaker
質問の性質をよりよく反映するようにタイトルを更新しました。あなたの視点に感謝します。 – Mark42