我在.net c＃應用程序中工作，該應用程序包含2個客戶端和服務器解決方案。在服務器側有已用於分離以下建築層80+項目，在單獨的項目中組織代碼vs單獨的命名空間
我此外，幾乎每一層都有測試項目。現在，解決方案的構建時間需要2到3分鐘，並且許多開發人員（包括我:)）都覺得我們需要解決這個問題。
因此，提出的解決方案是通過合併projects.In我的看法，以減少項目數量，它可能是一個很好的解決方案，以減少建造時間，我們可以實現我們想要的。
提出的解決方案是，我們合併我們的項目分爲3個區域，如一個庫，用於生產代碼，一個庫，用於測試代碼，一個用於部署項目（WCF主機等），通過分離邏輯上劃分在同一個項目中的層命名空間。
然而，我的擔心是
是否有任何其他的方式來分層解決？
我想你應該把你的解決方案分成邏輯層。
當你把傭工，其中的一部分。在其中一個最低級別上爲其制定解決方案。
例
軟件的一個農場。你需要跟蹤你的動物，蔬菜。你需要一個餵養動物的模塊和一個將動物和蔬菜賣給消費者市場的模塊。 Everyting爲銷售你的產品
這可能在以下解決方案
後端
每個後端的模塊，可以有它自己的數據訪問層，DTO，WCF服務。 ..
此解決方案將只包含業務邏輯，數據訪問......。並且可以有多個前端解決方案連接到這些後端解決方案。
前端
這是你的項目一個很大的變化，這將產生一定影響。確保你認爲這是真的，如果你不想改變它。
多個解決方案將會增加您的整體構建時間，每晚構建都很重要，因此每個開發人員都可以始終使用最新的二進制文件，而無需在本地計算機上構建所有解決方案。
注意，你仍然可以使用你的圖層在不同的解決方案：
爲了使這項工作在一起，不要弄亂二進制文件。您可以映射驅動器I.E. X：在哪裏有文件夾二進制文件，哪裏有每個解決方案的文件夾。其中每個解決方案都複製後構建事件中的程序集。 （腳本，所以它適用於每臺機器）
如果您擁有良好的網絡基礎架構，還可以將其複製到服務器上。因此，當您在TFS中構建所有解決方案時，可以將其複製到所有開發人員可以訪問的位置。
如果你建立在TFS中，確保你的構建順序是正確的，首先是最低層，最後一層是最高層。
但是，當你分解你的解決方案時，在解決方案中你可能不需要它們在每個解決方案中。
我最近讀了一篇關於Onion Architecture的文章，也許你也可以看看。 （它特定於ASP.NET MVC）。您可以查看CQRS。
我絕對不會合並這些項目......我想你會很快結束在每一層的意大利麪代碼，因爲開發人員採取捷徑（不管他們是否意味着）他們不應該服用。
我會更傾向於層由分離到單獨的解決方案......並用二進制的引用，而不是整個層次項目引用。雖然這可以破壞分支，但要小心。
我見過的構建時間通過使項目建設於一個共同的地方跌落 - 顯然這可以防止VS重建項目時，它並不需要 - 但我不知道這是真的還是假的。
一些想法在這裏：http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx
最後....是三分鐘爲一個完整的構建或只是單元測試一個項目？關注哪個是最大的問題。如果單元測試需要很長時間，那麼您的依賴關係就會出現問題。如果完整的解決方案需要很長時間，請獲得構建服務器，並專注於縮短您的單元測試開發時間。
希望可以幫到
爲什麼80多個項目在你的應用程序中只有6層？
您可能會回答說他們涵蓋了大量的功能區域，但您是否首先需要在一個解決方案中使用所有這些功能區域？
我建議反思架構司與項目和功能司與解決方案。不同的解決方案可以重用相同的項目這樣，每個可重用的體系結構層都有一個項目，並且有多個Domain項目與功能區域相同。
yup ..好點。我們有數據合同，運營合同在許多層次的獨立項目中。然而，我們在解決方案中也有許多外部系統項目，現在我相信我們應該將它們從解決方案中刪除，如果適用的話，還可以使用 – marvelTracker
我以前處理過這樣一個問題的一個低影響的方式是創建一系列解決方案文件，其中只包括其中一個項目及其測試項目（也可能是項目的依賴項）。然後，讓自己得到像NCrunch這樣的工具，並在這些解決方案中完成大部分編碼工作，可能使用TDD。這將爲您提供閃電般快速的反饋迴路，並且堅決採用分層解耦方法。當我過去完成這些工作時，我發現我實際上只是每天運行整個應用程序幾次，而且我嚴重依賴紅綠重構，這很好。
如果你願意，你甚至不需要控制這些小小的解決方案文件 - 開發人員可以創建自己的文件，而且它們可以被邊界拋棄。
當然，這絕不是萬能的，當你想運行應用程序時，不會解決編譯時間過長的問題，但它絕對有助於同時減少反饋時間，同時促進良好的設計/開發實踐，它具有極低風險和快速安裝的優勢。
Cool。你已經記得我以前的項目之一，我們做了同樣的事情。每個開發人員都有他們自己的解決方案文件，並保留在本地。但是，由於其他項目的衝突，我們經歷了很多構建失敗。 – marvelTracker
我不確定製作更少的項目會使構建速度更快，代碼量也會相同。我不認爲VS浪費太多時間來組裝項目。 –
爲什麼不把你的解決方案分成幾個？ – Guillaume