MVC:是否应在Controller或每个Action中实例化存储库?

时间:2014-02-16 23:23:58

标签: c# asp.net-mvc controller repository inversion-of-control

标题真的说明了一切。我有一些根本不使用存储库的Action方法,比如只显示静态页面的Index()方法。

public ActionResult Index()
{
    return View();
}

在我看来,在控制器中实例化存储库就像在这些情况下浪费时间一样......但对于IoC,我想提交一个接口,因此必须在控制器中发生:

public PerfMvcController(IPerfRepository repo)
{
    repo = repo ?? new PerfRepository();
}

简而言之,我对使用IoC在控制器中实例化存储库的最佳实践感兴趣。

2 个答案:

答案 0 :(得分:1)

我认为通过控制器的构造函数注入IPerfRepository会比使用动作中的代码重复更好。

如果您担心存储库的构造函数很重,并且无论您是否使用存储库而执行它,您都可以考虑使用支持注入Lazy<T>的IoC容器。

Autofac就是一个很好的例子:对于使用Autofac注册的任何服务,例如IPerfRepository,您可以申请Lazy<IPerfRepository>。这样,除非您访问注入对象的.Value属性,否则您甚至不会实例化新的存储库。

答案 1 :(得分:0)

什么更浪费?

  1. 在整个地方复制代码,或
  2. 单线初始化(DRY原则)
  3. 在构造函数中注入存储库是一般接受的原因是因为它使依赖关系变得清晰(它们只在一个地方和一个地方)

    只需检查构造函数即可明确依赖关系,而不是深埋在实现中。您可能在早期阶段没有注意到这一点,因为您只有基本功能(CRUD),但随着应用程序的增长,您将开始注意到不必追捕依赖项的优势。

    如果您担心性能问题,大多数ORM(如果您使用的话)都有延迟初始化。

    另一种常见做法是在其他地方实例化存储库(IoC容器),然后注入控制器的构造函数。

    关闭主题

      

    repo = repo ??新的PerfRepository();

    在控制器中构建自己的具体存储库会增加耦合,因此打破 IoC模式。相反,你应该在null时抛出异常,并且它支持fail-fast technique(一种构建高质量应用程序的技术)