2014-09-04 103 views
0

我有一個MVC ASP.NET項目,我目前使用靜態ViewModelHelper類,它有幾個方法(1爲每個視圖模型),在某些參數和模型對象,並生成查看模型對象讓我從我的控制器返回到我的視圖。它們目前都是靜態的,整個類都是無狀態的,當我想實例化一個視圖模型的實例時,我只是使用它,因爲一些數據需要相當複雜的邏輯。尋找替代靜態幫手類

這些方法在View Model類中的構造函數會更好嗎?我的理解是最好不要在視圖模型中有任何邏輯,但我可能是錯的。或者有可能是我應該在這裏用來幫助我創建這些視圖模型的設計模式?

+0

ViewModels絕對可以包含邏輯。您可能會對POCO這個術語以及POCO通常沒有任何邏輯的事實感到困惑 - 但ViewModel絕對是這樣做的。在_Views_中使用邏輯並不是一個好主意......但絕對在爲視圖提供服務的模型中。 – 2014-09-04 00:50:05

回答

1

這是您的項目的架構和設計問題,您的ViewModel應該是什麼樣子以及它們應該在何處/如何初始化。現在看來,你的ViewModel是DTO,你可以用工廠方法初始化它們。這很好,但我建議實際上接受抽象工廠模式,並確保工廠實現不會因無關的責任而過載。這是一個「實用」類的繼承問題,應該讓每個開發人員都謹慎起來。另一方面,與視圖有關的初始化邏輯,例如,填充選擇列表,可以很好地位於ViewModels本身。在這種情況下,你應該警惕重複。

另一種可能的方法是使用構建器模式。

無論哪種方式可以是一個乾淨的解決方案,如果你專門使用它,而不是混合和匹配。只要你保持乾淨,當然。 ;)

雖然沒有看到相當複雜的邏輯,但我建議你檢查爲什麼初始化邏輯是複雜的開始。如果它真的必須。也許有些商業邏輯在那裏偷偷溜走?

0

您的ViewModels應該只是DTO,只有屬性的類。沒有邏輯。將邏輯放在其他類(服務或完整的商業邏輯,取決於),並讓他們填充ViewModel。

我知道這個答案看起來相對於實質設計考慮非常短,但這是它的核心。對於推理等,請看看一些完整的ASP.NET MVC解決方案,如https://prodinner.codeplex.com/

+2

我不得不不同意「無邏輯」作爲統一規則。當然不是硬性和快速的商業邏輯 - 但絕對有一些邏輯應該進入ViewModel。例如,我們有ViewModel,它根據ViewModel滿足的條件決定DOM元素應該具有哪些CSS類。他們不是企業關心的問題,他們是這個觀點的關注點......但是這個邏輯在視圖裏面沒有任何地方。 – 2014-09-04 00:55:59

+0

在某種程度上,這是正確的。 – 2014-09-04 00:58:43

+0

ViewModel確實具有與UI相關的邏輯,比如當我點擊一個按鈕,顯示某種東西的顏色或者如何將DTO呈現給UI時。格式化的雙值。 ViewModel不應該包含的邏輯就是業務邏輯,比如計算DTO中的數據的方式。 – 2017-12-12 15:07:06