Question

我帮助支持的应用程序没有真正的业务对象可言，尽管它是一个相当大的，表面上是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; } 
}

OR

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

那些花费更多时间编写Web UI的人需要更早的，其中Person由他的ID引用。他们争辩说，当一个不同的人被分配给一个任务时，最好只更改task.AssignedPersonID（新的ID可以从他们在UI上的下拉列表中轻松获得）并写入数据库。对我而言，这与我们现在所采取的做法没有什么不同;它仍然反映了比实际业务模型更多的数据库行。他们争辩说，必须采用PersonID，实例化相应的Person实例，然后设置task.AssignedPerson，当最终结果 - 任务表中的AssignedPersonID列被更新时，它是更多的代码和更慢的 - 正是同样的。

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

Answer 1

我更喜欢对对象进行实际引用，而不仅仅是ID。

如果您只有ID，并且您经常使用它来查找Person来处理它，那么您的状态很糟糕，因为那些频繁的查找需要时间。另一方面，如果你有Person对象，而是需要ID，那就像调用Person.ID一样简单。

使用ID路由有一些可能的原因，并且Wes会对其中几个我甚至没有考虑过的问题（特别是性能问题），以及它与您的数据库结构对齐的事实更好，并且（取决于您的代码当前的结构）可能需要更少的代码更改来执行此操作，但我认为其中任何一个都没有令人信服的理由。

因此，虽然它取决于具体细节，但我认为大多数OO程序员更愿意使用实际的对象引用。

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

关联：使用ID或对象引用？

4 个答案: