我們有一個由同一臺服務器上的多個不同應用程序（客戶端）使用的功能塊。它最適合建模爲服務，具有後端數據庫，並且在任何時候都只有一個版本的功能和數據庫在使用。基於服務器的重用 - DLL，GAC或REST？
到現在爲止，我們已經使用了簡單的DLL重用，並且使用它的所有功能，配置文件和依賴項。因爲現在必須在幾個地方進行任何更改，所以在創建新版本的功能或新客戶端要使用該功能時，此方法非常痛苦。
我們想知道是否有更好的方法來做到這一點，並提出了兩種可能的選擇。
將DLL（和依賴關係）放入GAC中。問題是如何配置組件。由於客戶對配置沒有興趣，我們傾向於將配置文件存儲在服務器上的硬編碼路徑中。
將功能發佈爲內部（基於REST的）服務。訪問它可以限制在使用防火牆的內部客戶端。
正如我們所看到的，＃1的優點似乎是性能和可能的安全性，而＃2可以被認爲更容易設置。
我們在這裏失去了什麼重要嗎？以前有沒有人遇到類似的情況，想分享一些見解？
這是一個我多次苦苦掙扎的問題，其實沒有任何最好的答案。我個人的看法是，你需要保持從選項1走了幾個原因：
至於選項2一個替代方案是使用WCF（假設你的環境能支持它）。使用WCF你可以使用TCP傳輸使用二進制serilization（並可能有一個共享內存傳輸）。這兩種方法都將有助於縮小性能差距（儘管選項1將總是優於基於服務的方法）。
通過使用選項2，您還可以減輕重新測試所有客戶的需求，因爲您可以開發自動化測試來驗證您的合同沒有中斷。這將允許你發佈到一個地方，運行快速自動化測試，並知道你不打破客戶。
雖這麼說，你可以使用選項1和一組良好的單元測試完成同樣的事情，但根據我的經驗選項2將是從長遠來看更容易。
選項2，您還可以向外擴展，未來的服務，如果你需要更多的CPU資源。
就我個人而言，我認爲選項1更容易設置，因爲您不必處理配置防火牆，處理身份驗證，設置服務等......它也將更容易調試（分發應用程序介紹新的故障類型，例如託管服務的站點崩潰，客戶端開始出現故障）。
最後一個建議是，您使用代理/門面模式來從服務的實際位置暴露客戶端。這將讓您隨着時間的推移而不必修改客戶端代碼。
我想說，使用選項1會更簡單，更容易，尤其是因爲您將不得不花費額外的時間來限制REST的可用性。 （雙關打算！）
喬希指出WCF作爲一個選項，這肯定是我會這樣做的方式。
這個問題正是SOA應該解決的問題！
正如喬希所說的，不幸的是，這類問題的答案往往「取決於」。
我是GAC的忠實粉絲，但您應該只將代碼放在那裏，您可以確信它幾乎完美地工作，並且不需要經常更新。只要一段代碼「正在開發」，只需將其與每個使用它的應用程序一起發佈即可。