2011-01-14 19 views
3

私はasp.net mvcを使用するためのベストプラクティスをチェックしようとしましたが、かなりの数の人がViewDataを使用すべきではないと言います。私はこれをpostとそれはそれのように見える読んだ。ViewDataを使用しないでください。

私がViewDataを使用すると考えることのできる理由の1つは、ビューに1つの値を渡したい場合です。複数の値の場合、ViewModelsを使用する方が良いと思われます。しかし、それらがフレームワークの一部として含まれている場合、いくつかの利点と利点があるはずです。

ViewDataを使用する必要があるのはどのような場合ですか?誤用されないようにViewDataを使用する際のベストプラクティスは何ですか?

答えて

3

最初から強く型付けされたビューモデルを使用することをお勧めします。 私はこれを行うことによって "マジックストリング"の欠如を好む。

すべてののルールはありませんが、通常はこれが最初のアプローチです。スコット区(ソースへのリンク:nerddinnerbook)から

優し

D

+0

魔法の文字列自体は、定数の文字列を持つことで回避できます。 – Baz1nga

0

引用文字列ベースの辞書を使用

、 ミスので、 ができませんエラーにつながる可能性がコンパイル時に捕捉される。 また、型なしのViewData辞書 では、ビューテンプレートでC#などの強い型の 言語を使用する場合は、 "as"演算子または キャストを使用する必要があります。

0

厳密に型指定されたモデルまたはModelViewと組み合わせて強く型付けされたViewPagesを使用することは、ASP.NET MVCの完璧な実践です。

あなたは、ビューページに追加データを転送するためのViewDataを使用することができますが、私はのviewmodelsをpreffer

理由:

  • 魔法の文字列
  • をリファクタリングしない
  • IntellySenceサポート
  • 簡単ランタイムエラー対

    1. コンパイル時のエラー
    2. データバインディングでフォームを構築するためのHtmlヘルパー
  • 0

    いくつかのベースコントローラまたはフィルタを使用して現在のリクエストにデータを追加する必要がある場合、私は自分自身がViewDataを使用することがよくあります。通常、マスターページにはサーバーから取得する必要がある動的コンテンツがあり、ビューから返されたモデルを変更するか、親ViewModelで返されたすべてのモデルをラップするのではなく、追加データをViewDataに配置するだけです。

    私のビューで文字列を使用しないようにするために、コントローラクラスなどにconstフィールドを置き、ビュー内のフィールドを呼び出すことがよくあります。

    public abstract partial class BaseController : Controller 
    { 
        public const string MessagesViewDataKey = "Base.Messages"; 
    
        protected override void OnActionExecuted(ActionExecutedContext filterContext) { 
         if (filterContext != null && filterContext.Controller != null && !filterContext.IsChildAction) { 
          filterContext.Controller.ViewData[MessagesViewDataKey] = Messenger.MessageQueues; 
         } 
    
         base.OnActionExecuted(filterContext); 
        } 
    } 
    
    // site.master 
    <% if (ViewData[BaseController.MessagesViewDataKey] != null) 
          Html.RenderPartial("DisplayTemplates/MessageList", ViewData[BaseController.MessagesViewDataKey]); %> 
    
    0

    私はそれらを使用して好きではないが、私はすべてのページ上のユーザーへのメッセージのいくつかの種類を表示したい状況でそれらが有用であることが分かってきました。たとえば、ユーザーにメッセージを表示するユーザーコントロールがあります。私のマスターページにもあります。 ViewData["messages"]TempData["messages"]をチェックし、それらのいずれかがヌルでない場合は、存在するメッセージを表示します。それらが両方ともヌルの場合、それはしません。

    これにより、すべてのモデルをMessagesプロパティを持つ基本クラスから継承する必要がなくなり、より柔軟に対応できます。

    関連する問題