Reputation: 150108
This article states
There are some cases where you might like to step aside and write directly to the HTTP Response stream rather than having a partial view render the results (partials/views use MvcHtmlString/StringWriter)
Use Html.RenderPartial for streaming images or other elements that are media-centric or where faster download times are highly important.
What overhead does MvcHtmlString/StringWriter
introduce? Are there downsides to using Html.RenderPartial
all of the time, if there is less overhead?
I could not find answers on MSDN:
http://msdn.microsoft.com/en-us/library/ee402902.aspx
Upvotes: 5
Views: 9605
Reputation: 662
The downside is that you have to write less readable code. with Html.Render you write (1):
@Html.Partial("ViewName", modelObj)
while with Html.RenderPartial you have to write
@{ Html.RenderPartial("ViewName", modelObj); }
or (2)
Html.RenderPartial("ViewName", modelObj);
depending on syntax context (syntax 2 you will use under syntax blocks like if or foreach, while syntax 1. This will affect the way you will write the extension methods for HtmlHelper class, and hou you will use them.
Upvotes: 3
Reputation: 385
Html.RenderPartial is faster then Html.Partial because of RenderPartial give quick response to Output.
here are some reference:-
http://devlicio.us/blogs/derik_whittaker/archive/2008/11/24/renderpartial-vs-renderaction.aspx
Upvotes: 5
Reputation: 483
The only "downside" to RenderPartial is that you have no opportunity to manipulate the result before rendering. So if you wanted to check the output you could use Html.Partial and store the result etc. To be honest, I can't think of a good reason to do that, but doesn't meant there isn't one.
So unless you need access to that "seam", no downside to calling RenderPartial.
Upvotes: 1