我已經看到很多關於如何使用這些模式的文章和參考資料（請牢記這一點），使用ASP.NET MVC 3和EF開展嚴肅的項目。哪種模式適合我的項目？
該項目不是那麼大（13表），它基本上是一個CRUD維護：有一些用戶的組織;用戶可以屬於一個組，並可以創建一些工作區和模板...沒有什麼複雜的。重點是，這將是一個項目系列的第一個，我想創建一個基地工作。
我的問題是：
哪個以前的模式是最好的？這是否取決於項目規模？
我的車型將是這些：
你認爲他們是爲我的項目足夠好，是否合適？
我感謝您的所有意見。
ASP.NET MVC是在考慮依賴注入的情況下構建的。
如果您希望讓您的代碼鬆散耦合並且在將來更容易更改，您必須遵循諸如依賴注入，Repository（用於阻止抽象）和UoW（用於事務抽象）等模式。
所以我的回答是，你應該首先了解他們，然後決定是否遵循最佳實踐。即使對於簡單的項目，應用這些模式也是很好的，因爲它經常變得越來越大。在MVC中很容易做到這一點，爲什麼要避免它？
有許多資源需要了解。你可以只是谷歌它。
我想以更一般的方式回答這個問題。創造一些未來可以使用的東西比看起來要困難。以上所有模式都可以爲您提供基礎架構，以提供一些基本框架。
但我強烈建議你看看S.O.L.I.D校長（DI是其中的一部分），以瞭解優秀代碼的一些特質。無論涉及的技術如何，這些都是適用的。
你無法預知產品\架構的未來需求，但下面的這些原則，你可以更好地準備應對未來的任何修改軟件
你可能想看看S#arp Lite其中有如何許多很好的例子實現你想要的東西，並且可以作爲快速構建某些東西的非常好的基礎。
嚴重應用程序並不意味着一見鍾情。
過早設計應用程序可能是一個真正的災難，尤其是如果您沒有掌握所涉及的所有技術。
我的建議是keep it simple。創建一個滿足要求的基本應用程序（讓事情完成，讓老闆高興），然後在你的學習路徑中添加新的概念。
這並不意味着我宣傳不好的代碼，沒辦法！保持你的代碼清潔，組織良好等。但不要因爲害怕做錯事而被殺害。
開發人員回顧幾周前的應用程序是正常的，然後意識到他做了一些糟糕的事情。這就是我們的進步！
最後但並非最不重要，有樂趣！
ASP.NET website提供有用的資源來學習框架和所有相關指導。有幾個應用程序樣本是逐步創建的。
沒有提到的模式是互斥的。你應該根據你正在努力完成的事情來使用那些有意義的模式，而不是試圖讓你的應用程序設計成爲別人應該如何工作的想法。有時候試圖彎曲你的場景以適應特定的設計模式/實踐是你能做的最糟糕的事情。
想要確保良好的單元測試覆蓋率/確保TDD /確保鬆耦合？然後依賴注入是你的朋友，就像工作單元模式一樣。這對於創建可維護的，可擴展的應用程序來說絕對是一個好主意，但對於小規模應用程序來說，它可能太過分了。
需要針對數據源的集中式緩存策略嗎？然後使用存儲庫模式。或者像NHibernate這樣的ORM，可能會爲你做。
退房NerdDinner，這是一個很好的開始。更高級的，請查看codecampserver。 –