幫助程序是我們的「自定義服務器控件」

Question

我的理解是，Helper方法確實是您可以執行硬核心邏輯的地方，我們可以在ASP.NET中說自定義控件嗎？例如，我爲使用傳統ASP.NET的.com工作。我們網站的性質非常複雜，所以我們重複使用併爲數千種產品渲染不同的表單。每個產品都可以有不同的配置形式。我們有一個非常完善的RenderForm.cs自定義服務器控件，它執行所有的邏輯。根據數據庫中一個表中的一些配置設置，它表示沒問題，對於產品1123它讀取設置（我們的用戶配置我們的內部管理系統）並採用它並吐出動態表單（使用文字控制和不）到這個時代。

所以我現在正在考慮MVC。是的，這一切都是在視圖中完成的。部分是好的。您仍然需要在某些.cs中擁有一些自定義邏輯，這些邏輯並不是全部嵌入您的視圖中。這將是愚蠢的認爲你不會有一些會吐出一些HTML的類..就像一些非常困難的核心廣泛的幫助方法。

所以我的問題是，你現在做你的自定義服務器控件類型的邏輯的幫助器方法或類嗎？它基本上是一種相同的概念，因爲您需要一個地方將您的「硬核」HTML渲染邏輯放在控制器以外的某個類中。您的控制器不負責渲染。所以我猜，helper方法就是所謂的自定義服務器控件，這與我在經典的ASP.NET中使用的方法相似，比喻來說。我只需要一個是或現在是共識，輔助方法是做我的所有硬核可重複使用邏輯的地方，吐出html到頁面，我可以在自己的視圖中嵌入自定義控件？看起來像。

「幫助器基本上是靜態類，旨在包含用戶界面邏輯，否則會混淆您的用戶界面。將它們視爲UI實用程序。」 link text

Answer 1

是的，這是正確的。如果你做得對，你將從MVC爲你提供的HTML助手開始，並且你將逐步建立你自己的助手，爲你的特定項目做更多甚至更多的助手。您可以達到您的視圖只有幾行代碼的地步，即「爲產品1123渲染整個視圖」。助手將成爲您自己項目特定渲染器的「語言」，並且您將以非常乾燥（不重複自己）的方式應用配置，驗證和其他一切。這是驚人的。

更新：當然，只有演示文稿的東西應該在你的幫手。目標是在您的觀點中保持乾爽。你仍然需要小心的把你的ViewModel放入ViewModels中。

Answer 2

我會說「不」......或者說「只有你必須去的地方」。通常情況下，您可以改爲執行Controller（或服務）中的邏輯，並最終將所有需要的數據傳遞迴ViewData中的View。 Somtimes這將意味着來自一個ControllerAction的多個視圖，更少的情況將意味着視圖中的邏輯，偶爾它意味着HtmlHelpers。

當你決定使用助手時，應該考慮到這意味着生成的標記不會在你的標記中出現。如果你有（或者以後僱用）設計師，那可能是一個問題。或者，如果您需要對佈局進行小修改，那麼您首先要去哪裏？你的觀點還是你的助手？

[編輯]也應該問問自己：我的代碼在哪裏更容易單元測試？在剛返回View Data的Service類中，或者在構建HTML的整個塊並將它們返回爲String的類中？如果您使用的是TagBuilder，您應該可能會這麼做，那麼TagBuilder實現的任何更改（甚至是更改空白處理）都會在Helper上中斷測試，而不會更改代碼。

我不是說「不要使用助手」，我是說「不要濫用助手」。