【譯】組織好你的Asp.Net MVC解決方案

最近，Twitter上發起了一個一個關於“你最愛的Asp.net MVC項目組織方式”,我自己研究了一些組織專案檔的方法。而我現在一直喜歡用的方式是一個幾句靈活性的方式，此外，這個方式還非常簡單。

     如，整個解決方案裡只有兩個項目,首先讓我們來看UI項目,UI項目只包含了那些和Website相關的檔案並且不包含任何後台代碼,這包括:

•     沒有Controller
•     沒有Model
•     沒有Global.asa.cs
•     不包含任何後台代碼

     為什麼不包含後台代碼？因為UI項目只包含那些和UI相關的檔案，而我的UI項目和部署項目相匹配，這包括

•     Views
•     Css
•     Images
•     Global.asax
•     Web.Config
•     引用Core項目

     因為我的UI項目和部署結構相匹配，所以弄清楚開發是怎樣工作的將會變得容易.反之，將Model和Controller混合起來將會使得開發中將各部分分開變得困難。所以我的組織方法會將代碼和內容這兩部分分開。

     我們的代碼部分怎麼辦呢？放到另一個項目中，我喜歡稱之為”Core”,當然名字你可以隨便起，所有的代碼檔案都會放到這個項目中，包括持久層Model,View Model,Controller,repositories,ORM相關檔案以及任何和後台代碼相關的部分。

組織好你的代碼

    對於組織好的代碼，我喜歡用簡單的方式，如果可以的話，我寧願不編譯UI項目--這僅僅是一個用於存放內容的檔案夾，而這個檔案夾下的bin目錄裡只有來自於”Core”項目的dll。

    另外，我喜歡用檔案夾來組織代碼。利用項目的方式組織代碼是可以的，但是這種缺乏靈活性的做法會將你禁錮在很難改變的層和結構當中。我已經在大型項目中因為錯誤的組織代碼而犯過許多錯誤,而最後我發現最好的做法並不是大興土木，因為我曾經呆過的一個Team裡動輒就是上百個項目，但是只有不到一半的項目被實際部署.所以要牢記，編譯所需的時間很大程度上取決於你的解決方案中項目的多寡。在一個含有1000個檔案的項目和100個檔案放入10個項目中比較，前者所需的編譯時間要大大的小於後者。至少在我見過的項目中是這樣。

    而另一個實際的問題是當你需要重新組織你現有的代碼時，你會發現對於包含N個項目的解決方案來說，發現你被禁錮在各個不同項目的結構中會讓你捶胸頓足。此外，這種方式在Ctrl+F5進行調試時，超慢的速度更會讓你欲哭無淚。而這種方式在你的代碼被源碼管理軟體管理時，更會顯出不足，僅僅將一個檔案從一個項目中移到另一個項目中就會讓你的記錄暴漲。在我最近的一個項目中，情況已經發展到甚至我們連一個簡單的源碼控制指令都無法執行從而導致我們所有的源碼控制記錄全部丟失，最後我們不得不重新手動建立整個項目。移動檔案夾要比在項目中移動檔案讓人愜意很多…

    如果你想將你的代碼進行很好的組織和分層，使用項目的方式或許有些協助，因為這強制讓你遵循你自己一開始設定的規則，但是一旦你開始這樣做，你設立了”Common”項目，”Configuration”項目”,”mapping”項目等,在後面的開發中最好考慮將這些代碼迴歸到同一個項目當中.

    所以，為什麼不考慮將所有代碼放入一個Core項目，所有UI放入一個項目，從而能給你極大的靈活性和最快的編譯速度呢？無論你準備何種構架來組織你的代碼，請確保不要將後台代碼放入UI項目中，這樣才能避免將代碼和內容的關注點分離結構混為一談。

-----------------------------------------------------

原文連結:http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/12/08/organizing-asp-net-mvc-solutions.aspx