是html.renderaction代码气味

我最近开始了一个新的工作，我已经被抛入一个正在开发的ASP.Net MVC应用程序中的bug修复角色。我非常喜欢在2004/2005年使用MVC方法开发Web应用程序，并在Maverick.Net上构建了一些大量的生产应用程序，但这是我第一次使用ASP.Net MVC框架进行其他任何操作。是html.renderaction代码气味

我发现自己在bug修复方面做了很多事情，其中一件事是追踪html.renderaction调用后的控制器链。在过去，当我编写MVC应用程序时，单个控制器将负责完整地生成模型。如果每个控制器都有共同的部分或功能，则它们将被分类，移入数据访问层。在我看来，在这种情况下，我怀疑其他人，有html.renderaction会鼓励一些严重的代码化，并且真的打败了CMV CMV阶段以来的目的，因为它现在变成CMVCMVCMV等。

Is html.renderaction真的是鼓励清洁代码的最佳方式，它对我来说似乎有点臭？

来源

2010-07-07 sipwiz

我只需要在一个相当大的项目中使用RenderAction几次（150个视图）来渲染完全独立的东西（例如登录信息和快速搜索框）。这绝对是一件坏事。 – queen3 2010-07-07 12:46:14

经过一段时间的工作和ASP.NET MVC框架的工作后，我得出的结论是，RenderAction不应该用于生产代码（也许有一个例外，但我没有来穿过它），而是使用RenderPartial并为其提供模型。

这样一来，只有一个控制器阶段使维护更容易，另外单个控制器阶段可以确保任何昂贵的操作，例如数据库交互尽可能高效，如果处理分散在多个控制器阶段。通过使用RenderPartial多块视图逻辑，可以用来坚持DRY原则，该原则保持了RenderAction的主要优势，但没有两大缺点。

坏：

Html.RenderAction("ViewName", "PersonName", new { id = Model.Person.ID });

好：

Html.RenderPartial("ViewName", Model.Person.Name);

来源

2010-08-30 00:13:48 sipwiz

“bug修复正在追踪通过html.renderaction调用的控制器链。”哦，天啊。这听起来很可怕。

很确定这是臭的。 RenderAction仅适用于那些“高级小部件”场景。

来源

2010-07-07 13:15:51 jfar

-3

我认为最好尽量不要使用所有这些助手，集成的或自定义的，尽可能多的。这就像是一个方便的捷径，可以迅速解决设计中的问题，但是你真正在做的是制造混乱。

来源

2010-07-07 13:23:08 Marko

-1那是超过一般化。帮手在很多情况下都很有价值。 – 2010-07-08 10:03:15

嗯，也许是真的，但你同意小心使用它们是明智的吗？ ;）欢呼 – Marko 2010-07-08 13:06:04

这是一个老问题，但仍适用于今天的代码。应该使用的时间是呈现与当前信息无关的局部视图。例如，如果您有导航每页都呈现，但由模型填充。当他们不相关时，把模型放在每个其他模型上都是坏的魔咒。

+---------+ +-----+ 
|   | |  | 
| content | | nav | 
|   | |  | 
+---------+ +-----+

，如果你通过这组角色到的RenderAction（）方法可以缓存的导航，然后用甜甜圈洞缓存。

来源

2015-05-22 19:03:09

是html.renderaction代码气味

回答

相关问题