而此场景中的构造函数注入似乎是解决所述问题的更好方法,如下所示
The Explicit Dependencies Principle
方法和类应该显式地(通常通过方法参数或构造函数参数)需要它们所需的任何协作对象才能正常工作。
只需要访问
AppConfig
在你看来,我认为
XY problem
以及一个贯穿各领域的问题。
控制器本身似乎不需要使用依赖项,因此不必显式地将它们注入控制器,只需使依赖项对
意见
.
考虑使用一个操作过滤器,它可以解析依赖关系,并通过相同的
ViewBag
当请求通过管道时。
public class AccessesAppConfigAttribute : ActionFilterAttribute {
public override void OnActionExecuting(ActionExecutingContext filterContext) {
var resolver = DependencyResolver.Current;
var appConfig = (IApplicationConfigurationSection)resolver.GetService(typeof(IApplicationConfigurationSection));
filterContext.Controller.ViewBag.AppConfig = appConfig;
}
}
现在,这使得所需的信息可用于视图,而不需要使用控制器的紧密耦合不需要将依赖项注入派生类。
通过使用filter属性修饰Controller/Action
[AccessesAppConfig] //available to all its actions
public class HomeController : Controller {
//[AccessesAppConfig] //Use directly if want to isolate to single action/view
public ActionResult Index() {
//...
return View();
}
}
或全球范围内的所有请求。
public class FilterConfig {
public static void RegisterGlobalFilters(GlobalFilterCollection filters) {
filters.Add(new AccessesAppConfigAttribute());
}
}
在这一点上,使用哪个IoC容器并不重要一旦配置了依赖关系解析程序,视图就应该可以访问
可视包