你什麼時候決定把大項目分成更小的項目？

Question

您何時/在哪裏決定將大型Visual Studio項目拆分爲更小的多個項目？如果它可以重用？當項目太大？ （但有多大太大？）

和數據庫表中的類似功能，當你做拆分項目，你，

• 組

• 組

• 其他..

Answer 1

優點：

• 更容易隔離單元測試代碼。我喜歡隔離依賴於大型外部服務器的代碼，例如與SMTP服務器通信的代碼獲取自己的程序集，與數據庫通信的代碼獲取它自己的程序集，與Web服務器通信的代碼，代碼是純粹的商業邏輯，如驗證。

優點幾個項目：

• Visual Studio中去更快
• 一些開發商只是不明白你的眼光 約瓜分責任 ，並開始把班 無處不在，所以你最終會面臨額外項目帶來的痛苦，以及將所有東西都變成 一個項目的好處 。
• 每個項目都有一個配置，當你做出一個關於項目配置決定，往往你必須做出同樣的chagne隨處可見，如設置或更改強名稱密鑰許多解決方案
  的

優點

• 您以後達到最大項目級別。
• 只有當前解決方案中的內容在每次點擊f5時都會進行編譯
• 如果項目在應用程序的生命週期中不會發生變化，爲什麼重新編譯它一遍又一遍？將其稱爲完成並將其移至自己的解決方案。許多解決方案
  • 這是給您制定出解決方案之間的依賴關係，並手動首先編譯依賴

  缺點。這導致了複雜的構建腳本。

Answer 2

我將代碼移動到新項目，如果它具有其他項目也可以使用的一般功能（理論上）。如果項目很大，因爲它代表了一個複雜的問題，那麼命名空間提供了一個很好的方式來在代碼中引入順序。在這裏，您可以爲每個SQL表格等引入（子）名稱空間等。

Answer 3

項目應該是cohesive。邏輯應該是相關的，並且實現類似的目標

這個答案將取決於您支持的產品的大小。一般來說，我們按照領域和邏輯組織我們的項目。而且我們將進一步劃分這些，你分得越多，你必須組織的越多，否則你將會遇到可怕的遞歸依賴問題。

當我選擇分手項目時，它會變得太大或者兩個區域變得太相似。

當複雜度上升時，我不會按表分割，我通常會分割功能。

可重用性是縮短代碼行的另一好時機，也是一個新項目。但要小心你引入了多少「實用程序」庫，因爲它們確實會影響可讀性/可理解性。

我不認爲在沙子上有一條線說，如果你擊中3k SLOC，你有太多。這一切都是上下文的。

Answer 4

我總是有幾個項目（因此是一個解決方案），而不是一個項目與我的所有來源。

在某些情況下，它是不可避免的，因爲您正在使用和開源庫，並希望能夠進行調試。但更務實的是，我通常會讓我的應用程序通過插件提供功能。這允許我在運行時改變行爲或提供用戶可選行爲。在非插件的情況下，它允許您更新程序的一部分而不更新所有內容。還有一些情況下，您可以明顯地提供主體，並且只在需要時才下載模塊/組件。

另一個原因是您可以創建更小的測試應用程序來運行程序集，而不是構建一個非常大的解決方案，並且可能要求用戶在到達要測試的部分之前執行幾個（並且不相關的）GUI操作。這不僅僅是一個測試問題 - 也許你的組織中只有那些不太熟悉的用戶，他們只想提出與他們有關的位。

Answer 5

當項目的總體目的保持不變時，但類的數量變得很大時，我傾向於創建文件夾和名稱空間，以便在項目中更好地組合功能。耦合到彼此的類傾向於放在相同的文件夾/名稱空間中，這樣如果我需要理解給定的類，相關的類就在解決方案資源管理器中。如果我意識到某個特定功能在目的上有很大不同，或者現有項目之間存在共同的依賴關係，我通常只創建新項目。

我通常會收到一些相對較小的框架項目，這些框架項目定義了其他項目之間鬆散耦合的接口，以及針對不同類型的具體功能的較大項目。這總是對UI至少一個項目，邏輯和數據的一個項目（通常分爲兩個項目，如果該數據層成爲在自己的權利非常大。），許多項目的