将复杂对象作为类成员处理的最佳实践是什么？ [关闭]答案

【问题标题】：What is the best practise for handling complex objects as class members? [closed]将复杂对象作为类成员处理的最佳实践是什么？ [关闭]
【发布时间】：2013-05-08 17:41:32
【问题描述】：

好的，举个基本的例子，假设我有一个包含费用的应用程序，并且我的 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) 这将再次访问数据库以完成员工对象。这很方便，因为现在我可以通过费用访问员工成员/功能.. I.E.如果我绑定为 ObjectDataSource，我可以显示类似Eval("Employee.Name") 的内容并显示更友好的内容，然后只是一个数字，因为它存储在数据库中。

但是，如果我要获取每个对象的第一个费用详细信息，然后是员工详细信息，那么我正在处理的当前项目可能会运行 10 万行，并且数据库请求的数量将会猛增。（实际上我当前的项目有一个包含 6-7 个外键的表）。

有什么方法可以让我的蛋糕也吃吗？

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

感谢所有阅读本文的人，即使您没有任何答案。

【问题讨论】：

似乎使用 LazyLoading 的对象关系框架非常接近“两全其美”。

标签： c# asp.net oop

【解决方案1】：

这取决于：如果您使用功能丰富的 ORM (NHibernate) 可以干净地处理诸如关系之类的事情，那么第一个代码会更方便；或者，如果这些是您的 View Model 对象，您可以将此任务委托给 DI 引擎（如 Ninject）。

如果您的应用程序设计需要更多地控制对象的来来去去，或者如果您大量使用费用（不是员工），您应该使用第二种设计（当然，即 NHibernate 有一个复杂的缓存工具箱可以用来实现这个）。

【讨论】：

【解决方案2】：

在我看来，您的第二个示例不会阻止您在数据集中同时获取费用和员工。另一方面，我猜你可以为一个员工支付很多费用，所以如果你获取与 100 名员工相关的 1000 项费用，那么你有 1000 个员工对象漂浮在各处，其中 900 个是自重。您在类中表示它们的方式不一定会改变您在数据库中表示它们的方式。

【讨论】：