使用调用构造函数的静态方法有什么好处(语义或其他)？

Question

我刚刚更新了Visual Studio 2013,我注意到在MVC应用程序的项目模板中,ApplicationDbContext类现在有一个静态方法,它只调用构造函数:

public static ApplicationDbContext Create()
{
    return new ApplicationDbContext();
}

这似乎对我来说很混乱,但我想有一些语义原因我现在应该开始使用ApplicationDbContext.Create()而不是new ApplicationDbContext().这样做有什么好处吗？

Answer 1

其实.是.

在您的特定情况下,通过它包装它可以让您快速启动逻辑操作,例如使用ApplicationDbContext和singleton或以整个应用程序的通用方式处理异常.由于构造函数不能返回null,因此能够捕获异常并返回null非常重要.

Tuple.Create是泛型推理的主要示例,它不适用于构造函数.这让你说

Tuple.Create(Item1, Item2.. ItemN);

让编译器推断类型,而不是

new Tuple<T1, T2...Tn>(Item1, Item2...ItemN);

哪个更冗长,如果要切换其中一种类型,需要更多工作.

还有匿名类型的情况,无法明确指定,因此不能在新语句中使用.我特意有机会在搜索特定属性的程序集以链接命令结构时,我想在搜索期间使用匿名类型创建一个可枚举(在本例中为一个Queue),以便将类引用与其构造函数配对和字符串参数,而不是每次需要时查找它们.因为我可以在方法中再次使用Generic推理,所以我能够将构造函数包装在扩展方法中并完成工作.

单例模式也存在这种情况,其中您希望"GetInstance"方法通常创建一个值,或者如果存在则获取一个值.可能不符合条件,因为它比包装构造函数稍微多一点.

此外,在很多情况下,您可能希望控制实现过程,例如强制它们进入其他线程,将它们记录在数据库中以便稍后撤消,或者在权限系统上进行操作,所有这些都可以通过制作来完成构造函数包装器并添加几行逻辑,然后将构造函数私有化以避免直接调用它.

在某些情况下,我创建了一个工厂方法,该方法委托给已知的子节点,以便根据提供的参数提供返回接口或抽象的不同实现.这具有能够隐藏实现类的额外好处--Type类和IEnumerable接口使用此模式.

Answer 2

这种模式非常有用,特别是如果您使用私有构造函数,并从Create 返回接口类型,而不是具体类型.

private ApplicationDbContext()
{

}

public static IApplicationDbContext Create()
{
    return new ApplicationDbContext();
}

现在,您的类的消费者将无法依赖具体实现 - 他们只能依赖抽象.