作为类成员处理复杂对象的最佳实践是什么？

Question

好的，举一个基本的例子，假设我有一个包含费用的应用程序，我的SQL数据库中的每个费用都有一个Id、员工Id和金额。我应该这样做：

public class Expense
{
    public int Id { get; set; }
    public Employee Employee { get; set; }
    public decimal Amount { get; set; }
}

或者这样：

public class Expense
{
    public int Id { get; set; }
    public int EmployeeId { get; set; }
    public decimal Amount { get; set; }
}

您知道，我通常会执行第一个操作，当我从数据库获取费用时，我会通过调用一个构造函数来设置Employee字段，比如：Employee = new Employee(int id)，然后再次访问DB来完成Employee对象中的成员。这很方便，因为现在我可以通过expense访问Employees成员/函数。例如，如果我绑定为ObjectDataSource，我可以显示类似Eval("Employee.Name")的内容，并显示比存储在DB中的数字更友好的内容。

但是，如果我先获取费用详细信息，然后获取每个对象的员工详细信息，那么我正在处理的当前项目可能会运行上千行，并且DB请求的数量将会激增。(事实上，我当前的项目有一个包含6-7个外键的表)。

有什么办法既能吃蛋糕又能吃蛋糕吗？

也许是因为接口类只有Id字段，而不是完整的对象字段？但我觉得我从来没有完全理解过Interfaces，所以我不确定这是否会有所不同。

感谢所有读过这篇文章的人，即使你对我没有任何答案。

Answer 1

这取决于:如果你使用的是一个功能丰富的对象关系模型(NHibernate)，可以干净地处理关系之类的事情，那么第一个代码会更方便；或者，如果这些是你的视图模型对象，你可以把这个任务委托给DI引擎(比如Ninject)。

如果你的应用程序的设计要求更多地控制对象的来去，或者如果你的开销很大(而不是员工)，你应该使用第二种设计(当然，NHibernate有一个复杂的缓存工具箱，可以用来实现这一点)。

Answer 2

在我看来，您的第二个示例不会阻止您同时获取数据集中的费用和员工。另一方面，我会猜测一个雇员可能有很多开支，所以如果你提取了1000个与100个雇员相关的开支，那么你就有1000个浮动的雇员对象，其中900个是重量级的。您在类中表示它们的方式不一定会改变您在数据库中表示它们的方式。