在MVC Web應用程序中使用的常見設計模式

Question

我正在嘗試指導一些人構建Web應用程序。他們理解並使用MVC，但我對構建Web應用程序時使用的其他常見模式感興趣。

那麼，你發現什麼樣的模式很好地適合正確的MVC應用程序。也許是異步進程，計劃任務，處理電子郵件等等的東西。你希望你知道尋找或避免什麼？

不是說這個問題很重要，但我們在大多數應用程序中使用ASP.NET和Rails。

Answer 1

一旦進入MVC，探索超出「四人幫」書籍的模式並進入Martin Fowler的「Patterns of Enterprise Application Architecture」是值得的。

Registry模式可用於在整個對象層次結構中創建衆所周知的對象。基本上是使用全局數據的替代品。

許多MVC框架也採用Front Controller和Two-Step View模式。

儘管一些框架（由Rails領導）conflate模型與ActiveRecord模式，MVC中的「模型」最好設計爲Domain Model模式。我經常用advise表示Model和ActiveRecord之間的關係應該是HAS-A而不是IS-A。

同時在Portland Pattern Repository wiki上閱讀ModelViewController。關於MVC，面向對象以及補充MVC的其他模式（如Observer）有一些很好的討論。

Answer 2

我很可能會推薦某種類型的依賴注入（控制反轉）。可能是使用的最重要的補充「模式」。

Answer 3

這個問題很開放，很難給出正確的答案。我可以告訴你，觀察者模式在MVC（和web應用程序）中很重要，它將是一個很好的答案。關於所有存在的設計模式在大型web應用程序中都很常見。您將需要使用一些工廠建立複雜的對象和訪問某些部分需要一些門面。

如果你想要更多的「技巧」或好的做法而不是設計模式，我會建議你使用IoC和良好的使用Framework，而不是從頭開始。我可以建議你解釋一個好的引擎驅動你的持久層的好處（通常也可以來自框架）。

Answer 4

不要從使用開發方法的模式的角度來看它，而應更多地將它看作是如何在逐個問題的基礎上應用模式。針對該項目的架構決策提供了與其他人的體驗所使用的模式一樣多的指示。

這就是說，我發現我是提供者模型的粉絲，有多種選擇來完成單個任務，並且易於部署添加。此外，工作單元模式非常適合設置事務邊界。然而，很大程度上，架構和業務需求決定了針對任何給定的代碼更改或新開發所採取的方法。

儘管我喜歡圖案，但我總是害怕看到它們被過度使用。我親眼看到那些僅僅爲了使用它們而使用它們的人，並且它實際上使得代碼難以維護，並且與本來應該更緊密地耦合。此外，瞭解模式論證的雙方是很好的。一個好的模式知識應該與（通常被認爲是一種模式，自己的）知識結合起來。