c# – 我应该将服务注入我的MVC视图吗？

我们正在使用ASP.NET MVC技术开发某种云CMS,并且在途中遇到了一些障碍.用户可以通过控制面板更改许多参数,我们需要在视图中结束这些参数.例如,Facebook应用程序ID初始化Facebook JS API.或者在页面上显示其他文本.或背景图片.目前我们没有使用DI来传输这些参数,而是将它们添加到ViewModel中,但这破坏了ASP.NET MVC处理模型的方式(例如表单验证,绑定等)

看起来使用DI注入提供参数,文本和图片的服务可能会使我的视图更少依赖于控制器特定的,甚至有一些微软技术可以做到这一点http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection#Exercise2.但是,在论坛上有很多反对注入的答案使用DI将服务转换为视图.

所以问题是：将一些服务注入视图的正确方法是什么？或者我根本不应该这样做,应用程序设计出了什么问题？

更新：一些真实的代码示例(现在我们使用Model来注入服务)

从数据库中注入文本(它们必须是用户可编辑的,因为它是CMS)：

<div class="steps">@Html.Raw(Model.Texts["Main","Step2"]</div>

从数据库中注入翻译(实际上,它是本地化)：

<div class="gonfalon">@Model.Translations["Title_Winners"]</div>

注入参数(来自数据库,可能是特定于请求的;例如,如果站点具有不同的域,则facebook应用程序应为每个域)：

Facebook.Initialize(Model.Parameters["FbApplicationId"],Model.Parameters["FbApplicationSecret"]);

当前方法的问题在于此代码取自竞赛机制.处理自定义文本,翻译或Facebook应用程序ID绝对不在竞争业务范围之内.它也破坏了模型作为模型模型而不是实际的业务领域,但处理很多事实际上属于View(如翻译和自定义文本)

更新2：修改了以下答案的片段,使其更具通用性：

public static class WebViewPageExtensions 
{ 
    public static I ResolveService<I>(this WebViewPage page) 
    { 
         return DependencyResolver.Current.GetService<I>(); 
    } 
}

public static IMyViewServices MyServices(this WebViewPage view)
     {
         return DependencyResolver.Current.GetService<IMyViewServices>();
     }