適當的項目組織和架構，用於在Visual Studio / .NET項目中共享代碼

Question

我正在尋找有關如何在多個Visual Studio項目之間最佳共享代碼的建議。 我正在為一個基本主題而苦苦掙扎，並試圖獲得一些克服它的想法。

我的解決方案有：

• 幾個網絡應用項目
• 幾個獨立的流程項目，例如Windows服務和/或控制台應用程序和/或Azure WebJobs

所有項目共有的功能示例是，例如，需要調用某些通用的Web服務，或者需要從Amazon S3進行讀寫。

我要努力解決的問題是：顯然，實現通用功能的代碼應該自己分解，例如在單獨的類庫項目中。 例如，要與S3對話，代碼需要知道我的Amazon憑證，S3終端節點等-所有這些內容通常都存儲在應用程序配置文件中。 但是我不喜歡將配置文件放在類庫項目中的想法，因為它會將特定的實現綁定到它們。 但是為了不這樣做，我必須從調用項目中傳遞此信息。 因此，例如，Web應用程序的web.config和控制台應用程序的app.config文件包含此連接信息。 調用S3代碼時，我假設會將此配置信息傳遞到共享代碼中。

但是，這對我來說似乎令人討厭*，我不確定為什么。 在我看來，我仍然感覺像是將S3代碼（例如）“綁定”到特定的配置方法，如果那是有道理的。 我不確定我的感覺是否是一種錯誤的偏見。

*例如，我可能要傳遞任意數量的配置數據：

• 連接字符串
• Web服務憑證
• API端點
• 應用程序的配置設置中的任意數據（某些調用者會需要，但其他調用者則不需要，因此很多時候這些數據將變得毫無用處，但我必須做一些傳入的工作）

因此，每次我在主應用程序中添加一個config變量時，都必須修改通用代碼的構造函數。 事物會不斷地運動。

你能給我建議嗎？

Answer 1

我喜歡使用Configuration對象作為參數，這樣即使您添加/刪除屬性，簽名也不會改變。 例如....

public class AmazonConfigSettings {
    public string AWSkey { get; set; }
    public string ApiEndpoint { get; set; }
    ......
}

這樣，您的簽名就始終可以像：

public MySharedClass(AmazonConfigSettings config) { .... } 

即使（完全）Amazon徹底檢查了其網絡服務設置。