为什么注入控制器而不是操作

为什么ASP.NET MVC3中的所有依赖注入发生在控制器级而不是操作级。控制器创建通常会被重写，以便在控制器实例化时注入依赖关系。但是，控制器仅作为请求动作的结果而被实例化。为什么不在动作级别处理依赖注入？为什么注入控制器而不是操作

来源

2012-02-08 Travis J

你会如何在动作中注入依赖关系？ – Nope 2012-02-08 21:29:38

因为这是一种已知的图案和所述钩到位在MVC注入到控制器，不的动作。有一个控制器因素，但不是行动工厂。你创建了控制器的一个实例，而不是方法，这就是注入需要发生的地方。

加那里有构造器注入的已知图案，其将是更合适的这里比其他一些方法（即，动作方法）注射，它也允许在构造函数的任何其他的设置可能是必要的。

来源

2012-02-08 21:47:53

感谢您的回复。在创建控制器的实例时，为什么要注入所有方法的依赖关系？ – 2012-02-08 22:01:17

喜欢什么例如？通常，控制器在其动作之间具有相关的依赖关系，例如IUnitOfWork。 ICache或与您的控制器操作相关的ISomeService – 2012-02-08 22:54:18

例如：我有一个Index（）从与日志数据库绑定的readOnly存储库读取并发数据，以及一个保存到写入存储库的HttpPost索引（两个操作，每个都有独立的依赖关系）。注入仍然在控制器中，但注入的依赖关系仅与动作相关。动作调用将在HttpContext中。 – 2012-02-10 00:16:34

我的猜测是，你在上帝控制器10只依赖条件和大量的动作主演，不知道这到底是怎么变得更好？

请记住！控制器应该是瘦身并包含几个动作。我更喜欢我的控制器每个HTTP方法只有一个动作。

来源

2012-02-08 22:00:11

不，尽管我喜欢参考GOD代码，因为它令我感到愉快。 “每个HTTP方法” - 我假设你的意思是HttpPost和HttpGet和/或CRUD。我只是好奇，是否有一种方法可以避免将多个依赖关系（如存储库）注入控制器，而这些依赖关系很可能永远都不会同时需要。几乎没有什么行动的皮包骨头的控制器是好的，我尽量不要破坏200-300行代码，但不要让你的控制器太小，否则你将会过度，并且服务的可用性会受到影响。 – 2012-02-08 22:08:33

您可以使用模型绑定作为各种操作方法注入器。这里有一个小介绍模型活页夹，你可以阅读：

http://www.singingeels.com/Articles/Model_Binders_in_ASPNET_MVC.aspx

你可以实例，并通过信息库，或任何你想在这样的操作方法，并且它会是可重复使用的。

来源

2012-05-05 14:56:06 bevacqua

为什么注入控制器而不是操作

回答

相关问题