模型类的复合属性是否应该始终初始化？答案

【问题标题】：Should composite properties of a Model class be always initialized?模型类的复合属性是否应该始终初始化？
【发布时间】：2011-07-17 11:09:38
【问题描述】：

我试图在 SO 上找到类似的问题，但没有运气。如有重复请见谅。

在声明类类型变量时实例化它们有什么缺点？

在很多代表业务对象模型的类中，我们都有这样的东西：

public class RateArea {...}
public class FlatRateSchedule 
{
    public string ScheduleID {get;set;}
    public decimal MaxAmount {get;set;}
}

public class PricingData
{
    private List<RateArea> rateAreaList = new List<RateArea>();
    private FlatRateSchedule flatRateSchedule = new FlatRateSchedule();

    public List<RateArea> RateAreaList
    {
        get { return rateAreaList; }
        set { rateAreaList = value; }
    }

    public List<FlatRateSchedule> FlatRateScheduleList
    {
        get { return flatRateScheduleList; }
        set { flatRateScheduleList = value; }
    }
}

在某些时候，这个 PricingData 类被初始化并且一些属性被水合（但并非总是所有属性）。

我们的想法是我们正在创建类的“空白”实例，因此没有任何属性是 null。这很方便，因为我们不必在访问它的成员之前检查任何属性是否为空。无论属性是否水合，对于消费类，它们永远不会是“空的”。如果属性未初始化，则代码需要在每次访问属性之前检查 null。

“一个类的所有属性都应该在任何时候都被初始化并且永远不会为空”的笼统约定真的很糟糕吗？

除了使用一些资源来实例化和存储这些“默认”类实例之外，节省空异常检查代码似乎是值得的。我们错过了什么吗？

【问题讨论】：

标签： c# .net coding-style class-design instance-variables

【解决方案1】：

这里不是专家，但是

如果它是一个 List，它确实需要初始化，因为如果不是，你就不能添加元素。
如果在类的整个生命周期中，可能并不总是需要您的属性，您可以延迟加载它们。

您可以使用 .Net 4.0 的 Lazy<T> 类。

来自 Msdn：“使用 Lazy 的实例来推迟创建大型或资源密集型对象或执行资源密集型任务，特别是当此类创建或执行可能不会在程序。”

除此之外，我认为将所有属性都设为 null 并让每个消费类都进行 null 检查会很费力。 Lazy<T> 解决了这个问题。

【讨论】：

这减轻了我的担忧。我们通过 Web 服务发送业务对象，它们是没有逻辑的简单 DTO 类型对象。对象在数据层中被水合，没有办法自己水合。

【解决方案2】：

我喜欢初始化值以避免在整个应用程序中检查 null。我可能会选择延迟加载：

public List<RateArea> RateAreaList
{
    get {
        rateAreaList = rateAreaList ?? new List<RateArea>(); 
        return rateAreaList; 
    }
    set { rateAreaList = value; }
}

【讨论】：

【解决方案3】：

只要您的属性只是列表（如您的示例中所示），这可能是一个很好的约定，使您的代码更紧凑且更易于阅读。列表可以是空的，如果您不需要区分空列表和空引用，这可以正常工作。但是，如果您的属性包含其他“业务对象”，这可能不会那么容易。通常，那些“子”业务对象的构建不能或不应在构建“父”对象时完成。

【讨论】：