Html.Partial vs Html.RenderPartial&Html.Action vs Html.RenderAction


回答:


1237

Html.Partial文字列を返します。内部的にHtml.RenderPartial呼び出しWriteて戻りますvoid

基本的な使用法は次のとおりです。

// Razor syntax
@Html.Partial("ViewName")
@{ Html.RenderPartial("ViewName");  }

// WebView syntax
<%: Html.Partial("ViewName") %>
<% Html.RenderPartial("ViewName"); %>

上記のスニペットでは、両方の呼び出しで同じ結果が得られます。

の出力をHtml.Partial変数に格納したり、メソッドから返すことはできますが、ではできませHtml.RenderPartial

結果は、Response実行/評価中にストリームに書き込まれます。

これもに適用されますHtml.ActionHtml.RenderAction


71
なぜどちらを使うのか知っていますか?
Jason

156
パフォーマンスに関しては、RenderPartialを使用することをお勧めします。ここで回答があります。stackoverflow.com/ questions / 2729815 /
Vlad Iliescu

13
結果を変数に格納することについて少しありがとう。これが、レンダリングの対応部分よりも部分的またはアクションを使用する理由です。
David Kassa 2013年

8
Html.Partial()Razorでより流暢な構文を持つように作成されました。@Vladが言ったように、Html.RenderPartial()より効率的です。
Tsahi Asher 2014

2
_LoginPartialのMVCプロジェクトテンプレートで使用される理由を説明する@Tsahi。ありがとう。
regularmike 14

86

@ Html.Partialは、親ページにコピーされたHTMLコードと考えてください。@ Html.RenderPartialは、親ページに組み込まれた.ascxユーザーコントロールと考えてください。.ascxユーザーコントロールには、はるかに多くのオーバーヘッドがあります。

'@ Html.Partial'は、親とインラインで構築されるHTMLエンコードされた文字列を返します。親のモデルにアクセスします。

'@ Html.RenderPartial'は、.ascxユーザーコントロールに相当するものを返します。ページのViewDataDictionaryの独自のコピーを取得し、RenderPartialのViewDataに加えられた変更は、親のViewDataには影響しません。

リフレクションを使用すると、次のことがわかります。

public static MvcHtmlString Partial(this HtmlHelper htmlHelper, string partialViewName, object model, ViewDataDictionary viewData)
{
    MvcHtmlString mvcHtmlString;
    using (StringWriter stringWriter = new StringWriter(CultureInfo.CurrentCulture))
    {
        htmlHelper.RenderPartialInternal(partialViewName, viewData, model, stringWriter, ViewEngines.Engines);
        mvcHtmlString = MvcHtmlString.Create(stringWriter.ToString());
    }
    return mvcHtmlString;
}

public static void RenderPartial(this HtmlHelper htmlHelper, string partialViewName)
{
    htmlHelper.RenderPartialInternal(partialViewName, htmlHelper.ViewData, null, htmlHelper.ViewContext.Writer, ViewEngines.Engines);
}

3
Html.PartialはHtml.RenderPartialよりもパフォーマンスが良いと言っていますか?
numaroth 2014年

15
はい、いいえ。Html.Partialはインラインでレンダリングされるため、リソースを集中的に使用する必要はありませんが、時間がかかります。Html.RenderPartialは個別にレンダリングされるため、より高速ですが、リソースを集中的に使用します。大量のバーストトラフィックがある場合は、Html.Partialを使用してリソースの使用量を減らします。トラフィック量の変更が少ない場合は、Html.RenderPartialを使用してください。
Brett Jones

4
私の意見では、それは逆です。RenderPartialは、出力ストリームに直接書き込むので、明らかにパフォーマンスが向上します。部分的に同じメソッドを内部的に呼び出しますが、MvcHtmlStringとして返され、最後に出力ストリームに書き込まれるStringWriterに書き込みます。したがって、より多くのメモリを割り当てます。
slfan 2017年

2
@BrettJones「リソース集約型」とはどういう意味ですか?Partialバッファへのレンダリングが非同期でレンダリングされることを意味しないからといって-まったく反対です-どのようにしてRenderPartial「より多くのリソースを消費する」と主張できるかわかりません。
2017

57

これが私が見つけたものです:

RenderActionを使用するビューに送信するモデルがなく、変数に格納する必要のない大量のHTMLを戻す場合は、します。

ビューに送信するモデルがなく、変数に格納する必要があるテキストを少し戻す場合は、Actionを使用します。

RenderPartialを使用するビューに送信するモデルがあり、変数に格納する必要のない多くのHTMLがある場合は、します。

部分的に使用ビューに送信するモデルがあり、変数に格納する必要のあるテキストが少しある場合は、します。

RenderActionRenderPartialの方が高速です。


2
回答(なぜですか)が最良の回答です。これが私にとって最良の回答です。
YEH 2017年

55

違いは、最初は1を返し、MvcHtmlString2番目(Render..)は応答に直接出力することです。


MvcHtmlStringも応答に追加されませんか?
Shad

21

私によると、Html.RenderPartial @Html.RenderPartial()よりも実行が速い@Html.Partial()ため、出力にすばやく応答できます。

を使用する@Html.Partial()と、ウェブサイトの読み込みに比べて読み込みに時間がかかるため @Html.RenderPartial()


21

@Html.Partialそして@Html.RenderPartial、あなたのパーシャルビューモデルは、親モデルの対応があるときに使用されている、我々はこれをコールする任意のアクションメソッドを作成する必要はありません。

@Html.Actionそして@Html.RenderAction、あなたの部分図のモデルは、親モデルから独立しているときに、ページ上の任意のウィジェットタイプのコンテンツを表示する場合、基本的にはそれが使用され、使用されています。ビューからメソッドを呼び出しているときに、ビュー結果の一部を返すアクションメソッドを作成する必要があります。


3
良い答えです
。Partialover

15

質問の詳細:

「Html.RenderPartial()が部分ビューの名前だけで呼び出されると、ASP.NET MVCは、呼び出しビューテンプレートが使用する同じModelオブジェクトとViewData辞書オブジェクトを部分ビューに渡します。」

Professional ASP.NET MVC 1.0の「NerdDinner」


9

戻り値の型がHtml.RenderActionありvoid、それが直接の戻り値の型は、ビューで応答をレンダリングしている手段Html.Actionである MvcHtmlStringあなたは、コントローラにそのレンダービューをキャッチし、次の方法を使用して、それを修正することができます

protected string RenderPartialViewToString(string viewName, object model)
    {
        if (string.IsNullOrEmpty(viewName))
            viewName = ControllerContext.RouteData.GetRequiredString("action");

        ViewData.Model = model;

        using (StringWriter sw = new StringWriter())
        {
            ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
            ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
            viewResult.View.Render(viewContext, sw);
            return sw.GetStringBuilder().ToString();
        }
    }

これはビューのHTML文字列を返します。

これはにも適用さHtml.PartialれますHtml.RenderPartial


Html.RenderPartialでこれを行うにはどうすればよいですか?
xatz 2015年

1
Html.RenderPartialは使用できません。その戻り値の型がvoidです
Namrata Jain

9

PartialまたはRenderPartial:アクションメソッドを作成する必要はありません。部分ビューに表示するデータが現在のページのモデルにすでに存在する場合に使用します。

ActionまたはRenderAction:子アクションメソッドが必要です。ビューに表示するデータに独立したモデルがある場合に使用します。


8

違い:

  1. 戻り型がRenderPartialあるvoid場合など、PartialリターンMvcHtmlString

  2. Razorビューでの呼び出しPartial()RenderPartial()メソッドの構文

    @ Html.Partial( "PartialViewName")
    @ {Html.RenderPartial( "PartialViewName"); }

  3. Webフォームビューでの呼び出しPartial()RenderPartial()メソッドの構文

[%:Html.Partial( "PartialViewName")%]
[%Html.RenderPartial( "PartialViewName"); %]

以下はに関連した2つの共通インタビューの質問ですPartial()RenderPartial() するときは、使用するPartial()以上RenderPartial()、その逆も?

主な違いはRenderPartial()void を返し、出力は出力ストリームに直接書き込まれるということです。Partial()メソッドがを返すMvcHtmlStringので、変数に割り当て、必要に応じて操作できます。したがって、操作のために出力を変数に割り当てる必要がある場合は、Partial()を使用します。それ以外の場合は、RenderPartial()を使用します。

どちらがパフォーマンスに優れていますか?

パフォーマンスの観点からは、出力ストリームに直接レンダリングする方が優れています。RenderPartial()まったく同じことを行い、パフォーマンスよりも優れていますPartial()


5

Html.Partial:戻りMvcHtmlString、遅い

Html.RenderPartial:出力ストリームに直接レンダリング/書き込みを行い、戻ります。voidこれは、Html.Partial


3

「部分的」の場合は、常に次のように使用します。

(Ajax呼び出しの場合のように)コントローラーを経由する必要があるページに含める必要があるものがある場合は、「Html.RenderPartial」を使用します。

コントローラー自体にリンクされていない「静的」インクルードがあり、たとえば「共有」フォルダーにある場合は、「HTML.partial」を使用します


2

@Html.PartialHTMLエンコードされた文字列でビューを返し、同じビューTextWriterオブジェクトを使用します。 @Html.RenderPartialこのメソッドは戻りvoidます。 @Html.RenderPartialより速い@Html.Partial

の構文PartialView

 [HttpGet] 
 public ActionResult AnyActionMethod
 {
     return PartialView();
 }
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.