什么时候适合使用 Html.RenderAction()？
我有点不确定何时适合使用 Html.RenderAction() 来渲染我的视图，何时不适合。我的理解是，因为它不是 ASP.NET MVC 的“官方”组件，所以使用它是不好的做法，并且它的初衷是用于任何特定控制器上下文中不存在的可重用小部件。
问题是，当我需要一个存在于与我当前渲染视图不同的控制器下的组件时，RenderAction 非常有用。我认为这是一个非常整洁的&自包含方式来渲染依赖于当前视图中不可用数据的组件。我的视图不需要提供模型，就像我使用 RenderPartial() 时那样，
这是不好的做法吗？有更好的办法吗？
I'm a little bit unsure about when it's appropriate to use Html.RenderAction() to render my Views and when not to. My understanding is that because it's not an 'official' component of ASP.NET MVC it's bad practice to use it, and its original intention was for reusable widgets that don't exist in any specific Controller context.
The thing is, RenderAction is very useful when I need a component that exists under a different Controller than the one that I'm currently rendering the View for. I think it's a very tidy & self contained way to render components that rely on data unavailable in the current View. My View doesn't need to supply the Model, as it would if I was using RenderPartial()
Is this bad practice? Is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果它能解决您的问题就没关系。
It's OK in case it solves your problem.
实际上是这样。例如，您可以创建一些小视图作为小部件，并将它们注入到您需要的任何地方。然而，处理来自这些小部件的用户输入可能会变得更加复杂，但这是另一个问题。
我能想到的另一种合法场景是使用 HTML 电子邮件模板。这是一种情况，您显然不需要将渲染的输出直接返回到浏览器，而是将其插入到电子邮件正文中。
It actually is. For instance, you could create some small view to serve as widgets and inject them wherever you need. Processing user input from those widgets however may get even complicated, but that's another issue.
One other legitimate scenario I can think of is using HTML email templates. It's one case when you clearly don't need to return the rendered output directly to the browser but rather insert it into email body.
我出于您给出的原因使用
Html.RenderAction()，这样您就不必一次又一次地向需要显示用户信息的每个视图提供相同的数据（例如） 。您可以认为它违反了 mvc 模式，因为视图现在了解控制器。但我认为这种情况下的优势大于此，并且您的应用程序将更加 DRY。我只是将它用于需要在许多不同位置重用的所有内容（例如，我在母版页的每个页面上显示的用户数据），并且我不想将该信息显式发送到每个视图。如果我没记错的话，我认为他们也将其包含在 asp.net mvc 2 中，所以它现在是框架的一部分。
I use
Html.RenderAction()for the reasons you give, so that you don't have to supply the same data over and over again to every single view that needs to display user information (for example). You can argue that it is violating the mvc pattern as the view now knows about the controller. But I think that the advantages in this scenario outweighs that and your application will be more DRY.I simply use it for everything that I need to reuse in many different places (for example user data that I display on every page from my master page) and I don't want to send that information explicitly to each view. If I'm not mistaken I think that they have included it in asp.net mvc 2 as well, so It's now part of the framework.
我发现在基于父视图模型结果的场景中使用 Html.RenderAction 的一个很好的理由。例如，父视图的模型具有必须显示在表中的 List 属性。但是，为了防止父视图中出现条件 IF/ELSE，我调用了 Html.RenderAction()。该操作在列表中执行并检查计数。如果计数为零，则返回“无结果”视图；否则，它返回一个视图，以它自己的模型的形式处理 List 中的项目。通过防止在视图中插入逻辑，这会更干净。我还可以在应用程序的其他区域重复使用“无结果”视图。
I have found a great reason to use Html.RenderAction in a scenario based upon results from the parent view's model. For example, the parent view's model had a List property that had to show in a table. However, to prevent conditional IF/ELSE in the parent view, I call Html.RenderAction(). The action takes in the List and checks the count. If the count is zero, it returns a 'no results' view; otherwise, it returns a view that processes the items in the List in the form of its own model. This is cleaner by preventing logic being inserted in the view. I can also reuse the "no results" view for other areas in my app.