管理解決方案/引用

Question

我想創建utils類庫（例如，日誌記錄等）。
我想在多個獨立應用程序中使用utils解決方案。

我當然使用源代碼控制...

• 這是否意味着我應該管理utils的解決方案（持有本utils的類庫） 也是單獨的解決方案爲每個應用程序？

• 我有什麼做的，使用來自ApplicationA解決方案utils的類庫

• 可以ApplicationA解決方案還包括utils的解決方案（例如，去定義作品？）

• 如果是可能，這是否意味着任何更改proggrammerA都會通過ApplicatioA解決方案應用於utils庫，還會影響使用相同utils類的ApplicationB解決方案libray

• 當我們修復utils解決方案中的錯誤時，我們該怎麼做？ 修復程序如何冒泡到ApplicationA和B.

Answer 1

這聽起來像你已經確定了可能的方法：

• 開發和管理工具庫獨立於任何特定的應用程序。

  • 優點：無需管理多個版本，在一個解決方案進行更新不會影響/中斷其他的解決方案
  • 缺點：實用工具組件基本上是一個封閉的盒子，你的應用程序正在消耗一個組成部分，與任何第三方或.NET框架程序集相同。

• 把你的實用程序庫項目放到源代碼管理中，讓每個應用程序的解決方案都包含它作爲項目引用（這是可能的，以回答你的問題）。

  • 優點：實用工具庫保持最新的所有項目，並且可以在調試過程中跨進等
  • 缺點：在一個項目中公用事業由作爲發展的一部分的變化可能會打破它的另一個。另外，這可能會增加版本控制的問題，您可能需要回滾修補程序版本的更改等。
• 爲每個項目創建工具庫的新副本
  • 優點：與構建，調試，部署或版本
  • 缺點沒有問題：在一個項目中的實用程序所做的更改不會反映在其他人，必要時必須手動複製。

在一天結束的時候，有沒有一個正確的答案;它取決於您的實用方法的穩定性，需要多長時間更換一次，以及您需要多久調試一次。

在大多數情況下，我發現爲每個項目創建一個Utilities類庫的新副本會更方便。他們最終會有所不同，但維護的方便性彌補了所有項目缺乏一致性。如果你有一套非常複雜的實用程序類來封裝你的業務的某個部分，那麼你可能想要另闢蹊徑並獨立維護它。

Answer 2

我認爲您需要了解如何分配API以供消費。你應該保持這個作爲一個單獨的項目。版本，你將如何將你釋放給公衆的東西。如果你在utils中做了一些改變，並且你在AppA中需要它，那很好，只是知道，除非你使用AppB進行測試，否則你需要使用一個分支或舊版本的util類。