MVCビューにサービスを注入する必要がありますか？

Question

私たちは、ASP.NET MVC技術を使って何らかのクラウドCMSを開発しています。途中でいくつかの障害が見つかっています。ユーザーがコントロールパネルを使用して変更できるいくつかのパラメータが、ビューに表示されます。たとえば、FacebookのJS APIを初期化するためのFacebookアプリケーションID。または、ページに表示される追加のテキスト。または背景の画像。今はDIを使用してこのパラメータを転送するのではなく、ビューモデルにViewModelを追加していますが、これはASP.NET MVCのモデル（フォーム検証、バインディングなど）の操作方法を壊しています。

It DIを使用してパラメータ、テキスト、画像を提供するサービスを注入すると、私の見解をコントローラ特有のものにあまり依存させることができないと思われ、http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection#Exercise2というMicrosoftの技術もあります。しかし、DIを使用してビューにサービスを注入することについてのフォーラムには、多くの答えがあります。

質問：ビューにいくつかのサービスを注入する正しい方法は何ですか？あるいは、私はそれをまったくやってはいけません。アプリケーションの設計に何か問題がありますか？

UPDATE：いくつかの実際のコード例データベースから

注入テキストを（今、私たちはサービスを注入するためにモデルを使用している）は、（それがCMSであるとして、彼らは、ユーザーが編集可能である必要はあり）：

データベース（実際、それは局在化）から

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

注入翻訳：

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

データベース、COUから（パラメータを注入ldはリクエストに依存する。たとえば、サイトが別のドメインを持っている場合は、Facebookアプリケーションは、ドメインごと）する必要があります：

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

現在のアプローチの問題は、このコードは、コンテストのメカニックから取ったということです。カスタムテキスト、翻訳、またはFacebookアプリケーションIDを処理することは、コンテストのビジネス範囲からはっきりとはずれています。物事の多くは、実際に

UPDATE 2（翻訳とカスタムテキストのように）見るに属しても、それは実際のないモデルのモデル事業ドメインが、取引としてモデル遺跡：以下のように答えからスニペットを変更しましたより一般的なビット：

Answer 1

いいえ、ビューにサービスを挿入しないでください...

テーマ開発者にもっと力を与えたいテーマなどのシナリオでは、1つのモデルでは不十分です。たとえば、モデルに現在の投稿が含まれている場合、テーマデザイナーはどのようにサイドバーのカテゴリのリストを尋ねることができますか？またはウィジェット用ですか？

asp.net mvcでは、拡張メソッドを使用してその機能を提供することができます。拡張メソッドは依存関係リゾルバを使用してサービスを取得します。これにより、実際にサービスをインジェクトすることなく、ビュー内に必要な機能を持たせることができます。

モデルを更新するためにビジネスレイヤを呼び出すことは、依然としてSeparation of Concernsに違反していることに注意してください。ビューで利用できるサービスには、読み取りモデルまたは一般的なユーティリティ機能のみが含まれている必要があります。

例（範囲）リクエストのHTTPあたりであるべきであるDIコンテナに構成

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

IMyViewServices寿命

Answer 2

これは本当にあなたが達成したいと思っているコントローラの量や程度に依存します。

私の世界では、ビジネスロジックのすべてを扱うサービスレイヤーと、データベースのやりとりのすべてを処理するデータレイヤーがあるため、MVCアプリケーションの「コントローラー」はできるだけ少ないです。

GETの場合、コントローラは単にビューモデルを構築してコントローラに戻し、コントローラがそれをビューに渡すサービスメソッドを呼び出します。 POSTでは、ビューはコントローラにデータをポストします。コントローラーは、検証のためにサービスレイヤーにデータを送信し、DBに保存します。サービスは、コントローラーのコンストラクターに注入されます。

私は、コード例を表示したいと思うなら、それを投稿して嬉しいです。

Answer 3

いいえ、物語の終わり。どうして？理由は次のとおりです。

あなたのビューは、そのモデルを提示するためにどのようなビューモデルを使用しているかを知る必要があります。これにはいくつかの理由がありますが、最大の問題は懸念の分離です。可能な限りあなたの意見を愚かに保つ。このような分離が途中できれいなアプリケーション構造を与えることがわかります。

ユーザーがコントロールパネルで変更できるさまざまなパラメータが、Viewsで終わる必要があります。

ここでは正確に何を意味するのかよく分かりませんが、これはビューモデルがある理由です。あなたのビジネスレイヤーはモデルを形作ります。コントローラーはそれらをビューモデルにマップし、ビュー（プレゼンテーションレイヤー）に渡します。