应该始终初始化Model类的组合属性？

我试图在SO上找到类似的问题，但没有运气。道歉，如果它是重复的。应该始终初始化Model类的组合属性？

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

在大量的代表业务对象模型类的，我们有这样的事情：

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。

是一种全面的约定“一类的所有属性都应该在任何时候都被初始化，不能为空”非常糟糕？

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

来源

2011-03-17 Leon

这里不是专家，但

如果它是一个列表，因此它需要被初始化，因为你不能添加元素，如果它不是。
如果，整个班级的生活，你的属性可能不会总是需要的，你可以懒加载他们。

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

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

除此之外，我认为这将是密集的所有属性为空，完全有消费类做null检查。 Lazy<T>解决了这个问题。

来源

2011-03-17 14:40:20 gideon

Lazy类的好主意。 – neontapir 2011-03-17 14:41:44

这减轻了我的顾虑。我们将业务对象发送到Web服务，它们是简单的DTO类型的对象，没有逻辑。对象在数据层中被水化，并且没有办法自我保护。 – Leon 2011-03-21 14:36:15

我喜欢初始化值以避免在整个应用程序中检查null值。我大概有延迟加载去：

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

来源

2011-03-17 14:41:23 neontapir

只要你的属性仅列表（如你的例子），它可能是一个好习惯，使你的代码更紧凑，更易于阅读。列表可以是空的，如果你不需要区分空列表和空引用，这可以正常工作。但是，如果您的属性包含其他“业务对象”，这可能无法如此轻松地工作。通常，在构建“父”对象时，这些“子”Business Objects的构建不能或不应该完成。

来源

2011-03-17 14:46:21

应该始终初始化Model类的组合属性？

回答

相关问题