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

尽管它是一个可观的，表面上是n层的项目，但我帮助支持的应用程序没有真正的业务对象可言。我们的团队称之为“业务对象”实际上只不过是自动生成的数据库行周围的包装，而所有实际的业务逻辑都与Web UI代码混合在一起。对于新功能，我真的希望看到我们的团队开始使用/编码真正代表业务实体数据和行为的对象，并尽可能地将业务逻辑从UI中排除出去。然而，关于如何建模关系存在一些冲突。关联：使用ID还是对象引用？

为了达到这个目的，大大简化了域名，比如说你有人员和任务。每个任务都有一个人分配给它。

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

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

那些花更多的时间编写Web UI希望越早，其中人是他的ID引用。他们认为，当一个不同的人员分配给一个任务时，最好只更改task.AssignedPersonID（新的ID很容易从UI的下拉列表中获得）并写入数据库。对我而言，这与我们现在所做的方法没有什么不同;它仍然反映了比实际业务模型更多的数据库行。他们认为，如果最终结果 - 任务表中的AssignedPersonID列被更新 - 完全相同，那么他们认为必须采用该PersonID并实例化相应的Person实例，然后设置task.AssignedPerson，代码更慢并且速度更慢。

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

来源

2012-01-27 Mark42

我宁愿有一个对象的实际引用，而不仅仅是ID。

如果您只有ID，并且您经常使用它来查找Person以使用它进行操作，那么您处于不良状态，因为这些频繁查找需要时间。另一方面，如果你有Person对象，并且需要这个ID，就像调用Person.ID一样简单。

使用ID路径有一些可能的原因，Wes命中了我甚至没有想过的其中几个（特别是性能问题），还有它与您的数据库保持一致的事实结构更好，并且（取决于您的代码当前的结构），可能需要更少的代码更改才能完成此操作，但我认为其中的任何一个都没有那么重要。

所以，虽然它取决于具体情况，但我认为大多数面向对象的程序员更喜欢拥有实际的对象引用。

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

来源

2012-01-27 20:43:29 rbwhitaker

对于术语混淆抱歉。对于继承来说，对我来说最自然的术语是“基类”和“子类”，在继承的背景下，我没有考虑“父”和“小孩”。这可能解释了我在查找有关我的问题的在线信息时遇到的一些困难。 – Mark42 2012-01-27 22:08:53

没问题。这些也很常见。作为程序员，我们在很多地方真的弄得一团糟。子类，派生类，子类，超类，基类，父类......它可能是一个大问题。就像我说的那样，你的问题实际上是一个很好的问题。 – rbwhitaker 2012-01-27 22:28:16

我更新了标题，希望更好地反映问题的性质。感谢您的观点。 – Mark42 2012-01-27 23:11:28

任务是否曾经调用其指定人员的方法？您是否可以预见未来的任务可能需要调用其分配人员的方法？由于某种原因实例化Person特别昂贵？

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

来源

2012-01-27 20:36:36

我肯定会说第二种选择，即指实际的人。假设任务类需要发送消息给assignedPerson。为什么要知道如何通过她的身份证明来获取这个人？我不明白你的问题，“如果一个不同的人被分配到一个任务......”：谁来分配它？分配它的人应该更好地了解被分配的人员（或知道如何访问该人员的ID），这不是任务类别的业务。

这不是一个性能问题，性能可能会是一样的，这是关于良好的设计和有一个责任类。

来源

2012-01-27 20:48:50

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

但是，如您所示，您的应用程序不是面向对象的。 “对象”不是获取者/设置者的集合。他们有行为（“业务逻辑”），我相信你的自动生成的类不会。你想做的事听起来很正确，但我怀疑要说服别人会有很多工作要做。

来源

2012-01-27 20:50:42 SingleShot

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

回答

相关问题