是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代碼氣味

回答

相關問題