.NET解決方案 - 許多項目與一個項目

Question

我們目前有一個快速增長的C＃代碼庫。 目前我們有大約10個項目，分為通常類別，common / util東西，網絡層，數據庫，ui組件/控件等。

我們遇到偶爾的循環依賴，其中項目x依賴於y中的某些東西，反之亦然。 我們正在考慮將項目簡化為一個，只使用結構文件夾/命名空間進行管理。 我們有一個Java項目，當然只使用文件夾/包進行組織，所以我們不確定有多個項目帶來的好處（如果有的話）。 我們的項目都不需要特殊的項目屬性，除了主要運行項目，我們可以將它們分開（並且非常薄）。

有沒有人有任何先前的經驗，為什么一個項目比多個項目更好/更差，並可以建議最好的方法？ 而且循環依賴的任何問題在這兩種方法中都很有用。

任何輸入贊賞。

Answer 1

如果您的項目具有循環依賴性，則表明代碼設計存在問題，而不是解決方案/項目模型。

Answer 2

根據我的經驗，如果您願意，在多個項目中創建單個可執行文件的代碼分離可能很有用

• 在不同的部分使用不同的編程語言，
• 開發也被其他應用程序使用的庫，或
• 在概念上分離多個層（即，讓Visual Studio確保沒有項目Lib到項目App的直接引用）。

就個人而言，我的大多數決定都是基於第二點。 我認為應用程序的一部分可能是我在其他應用程序中可能需要的更通用的庫嗎？ 把它放在一個單獨的項目中。 否則，正如您所指出的，擁有一個項目通常會使開發變得更容易。

關於循環依賴：推薦的解決方法是將引用的東西的接口放入第三個項目。 例如，如果有兩個應用程序都通過遠程處理共享某些對象，則將共享對象的接口放在庫項目中，以確保它們對兩個應用程序都可用。

如果不知道應用程序的確切設計，就很難給出更具體的建議。

Answer 3

在項目之間建立依賴關系時，總是將其視為“較低”，將另一個視為“較高”

更高級別的項目（例如Web界面）應該僅依賴於較低的項目。 較低的項目（例如實用程序）不應該依賴於更高的東西，例如Web界面。 如果發生這種情況，則意味着您的更高級別的項目確實應該在較低的項目中，反之亦然。

Answer 4

一般來說，擁有多個VS項目（在VS解決方案中）在這些情況下才有意義

• 您可以在另一個項目（類庫）中重用生成的DLL
• 您希望將分層​​架構中的內容分開，您可以在其中刪除DAO dll並將其與另一個進行交換
• 只有不同的前端項目（即ASP.net MVC應用程序）需要部署在不同的物理位置，但使用相同的BL，DAL。

如果你說你有循環依賴的問題，那么你的代碼設計就會遇到問題。 也許您可以將多個項目使用的邏輯放在一個類庫中，該類庫被設計為在許多項目中重用。

一般來說，如果你真的不需要，我會說你不應該添加更多的項目。 分裂成項目意味着增加更多的復雜性，所以當你這樣做時，你應該從中獲得合理的好處。

Answer 5

我們注意到隨着項目數量的增長，Visual Studio的性能會顯着下降。 從“調試”切換到“發布”配置這樣簡單的事情，對於包含大約12個C＃項目的解決方案，可能需要15秒。

另外，作為Reed關於構建時間的評論的反對點，我看到構建時間增長，因為Visual Studio似乎花費了大量時間在項目開銷上。 實際的編譯時間似乎很快，但是從命中構建到能夠運行的總時間非常重要。

我的建議是將項目數量保持在最低限度。 如果你有充分的理由需要多個項目，那么必要時使用它們，但更喜歡將它們放在一起。 如有必要，您還可以重構將項目拆分為兩個。

Answer 6

將解決方案分成不同的項目（以及組件）有幾個原因，主要歸結為可重新使用和責任分離 。

現在，你的目標應該是使一個程序集（也稱為項目）對解決方案中的其他程序集具有最小的依賴性，否則你可能擁有更少程序集中的所有內容。 例如，如果您的UI組件對您的數據訪問代碼有很強的依賴性，則可能存在問題。

實際上，這歸結為針對通用接口的編程。

注意但是：

當我說“否則你可能擁有更少的裝配中的所有東西”時，我並不一定暗示這是錯誤的做法。 為了實現真正的關注點分離，您需要編寫更多代碼，並且必須更多地考慮您的設計。 所有這些額外的工作對你來說可能不是很有益，所以仔細考慮一下。

Answer 7

您可能會發現以下Martin文章值得： 設計原則和設計模式（PDF）（Java） 。

C＃中的修訂版本特別適用於C＃中的敏捷原則，模式和實踐 。

兩者都表達了不同的指導方針，可以幫助您確定屬於哪里。 然而，正如所指出的，循環依賴性表明存在設計問題或者某個組件屬於不同組件。

Answer 8

多個項目允許在多個應用程序中更好地重用特定類型。 它還可以縮短構建時間，因為不需要為所有代碼更改重建某些項目。

單個項目使生活更輕松，因為您不必擔心依賴性。 只是意識到輕松是有代價的 - 它也使得更容易讓糟糕的設計決策蔓延到代碼庫中。 循環依賴關系，無論是在一個項目還是多個項目中，通常都是設計缺陷，而不是要求。

Answer 9

在我工作的地方，我們選擇了一種方法，其目標是每個解決方案都有一個項目。 所有代碼庫項目還具有測試工具應用程序和/或單元測試應用程序。

只要代碼庫通過測試，發布版本（當然使用Xml文檔文件）就會轉移到“Live”文件夾中。

任何需要這些其他項目功能的項目都必須從“實時”文件夾中引用它們。

優點非常明顯。 任何項目總是訪問已知的工作代碼。 永遠不可能引用正在進行的工作裝配。 每個程序集都會對代碼進行測試，從而更容易理解bug的來源。 更小的解決方案更易於管理。

希望這可以幫助！

鰳

Answer 10

從單個項目開始。 將代碼庫拆分為更多項目的唯一好處就是縮短構建時間。

當我有一些可重用的功能，我真的想要從主項目中分離出來時，我會為它開始全新的解決方案。