Oop 关联：使用ID还是对象引用？

我帮助支持的应用程序没有真正的业务对象，尽管它是一个相当大的、表面上是n层的项目。我们的团队所称的“业务对象”实际上只是围绕数据库行自动生成的包装器，所有实际的业务逻辑都与web UI代码混合在一起。对于新功能，我真的希望看到我们的团队开始使用/编码真正代表业务实体的数据和行为的对象，并尽可能将业务逻辑排除在UI之外。然而，在如何对关系进行建模方面存在一些冲突

为了达到这里的目的，将域大大简化，假设您有人员和任务。每个任务都有一个人分配给它

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; } 
}

或

那些花更多时间编写web UI的人希望更早地使用ID引用人员。他们认为，当（比如）将不同的人员分配给任务时，最好只更改

任务。AssignedPersonID

（新ID可以很容易地从UI上的下拉列表中获得）并写入数据库。对我来说，这和我们现在的做法没有什么不同；它仍然比实际的业务模型更能反映数据库行。他们认为，当最终结果（任务表中的AssignedPersonID列被更新）完全相同时，获取PersonID，实例化相应的Person实例，然后设置

task.AssignedPerson

，这样做的代码更多，速度也更慢

---

从面向对象的角度来看，这里的首选方法是什么？

任务是否调用其指定人员的方法？您能否预见将来at Task可能需要调用其指定人员的方法的情况？由于某种原因，实例化人员的成本是否特别高

---

没有理由不引用实际的Person实例，除非它确实是一个性能问题。

我更喜欢使用对对象的实际引用，而不仅仅是ID

如果你只有身份证，而且你经常用它来查找要用它做事情的人，那么你的状态就不好了，因为频繁的查找需要时间。另一方面，如果您拥有Person对象，并且需要ID，则只需调用Person.ID即可

使用ID路由有一些可能的原因，Wes找到了其中一些我甚至没有想到的原因（特别是性能问题），还有一个事实，即它更符合您的数据库结构，并且（取决于您的代码当前的结构）可能需要更少的代码更改来实现这一点，但我不认为这两个都是令人信服的理由

因此，虽然这取决于具体情况，但我认为大多数OO程序员更喜欢使用实际的对象引用

---

顺便说一句，标题中使用了“父”和“子”两个词，这两个词（您可能已经知道）在面向对象编程的继承上下文中具有特定的含义。在我看来，这不像是亲子关系，而是一种“这用那”的关系。您的问题完全正确，但标题/标题可能有点误导，您可能会用稍微不同的术语得到更好的答案。

我肯定会说第二个选项，即提及真实的人。假设task类需要向assignedPerson发送消息。为什么它必须知道如何通过她的身份证找到那个人？我不明白你的问题的来龙去脉，“如果一个不同的人被分配到一项任务……”：是谁分配的？分配它的人应该更好地了解被分配的人（或者知道如何访问给定id的人），这与任务类无关

---

这不是一个性能问题，性能可能会相同，这是关于良好的oop设计和具有一个职责的类。

从面向对象的角度来看，首选方法是使用对象，而不是ID

---

但是，正如您所指出的，您的应用程序不是面向对象的。“对象”不是getter/setter的集合。它们有行为（“业务逻辑”），我确信您的自动生成类没有。你想做的事情听起来很正确，但我怀疑要说服其他人需要做很多工作。

很抱歉术语上的混乱。对于继承来说，我最自然的术语是“基类”和“子类”，而在继承的语境中，我没有考虑“父母”和“孩子”。这也许可以解释我在网上查找与我的问题相关的信息时遇到的一些困难。没问题。这些也很常见。作为程序员，我们确实在很多地方弄乱了术语。子类，派生类，子类，超类，基类，父类。。。这可能是个大问题。就像我说的，你的问题其实是个很好的问题。我更新了标题，希望能更好地反映问题的本质。谢谢你的观点。

public class Task
{
    public int ID { get; set; }
    public string Title { get; set; }
    public Person AssignedPerson { get; set; } 
}