我們有兩個客戶端應用程序（一個Web應用程序和一個代理應用程序）訪問同一服務上的方法，但需求略有不同。我的團隊希望通過將ApplicationType參數傳遞給每個方法來控制服務方面的行爲 - 這實質上是一個包含調用客戶端應用程序名稱的枚舉 - 然後將其用作數據庫查找的關鍵字，以便將服務配置爲客戶特定的選項。切換服務層中的客戶端邏輯是錯誤的嗎？
有些事情會讓我感到不安，因爲我認爲服務不應該真的需要知道哪個客戶端調用它。我被告知這樣做比通過方法調用動態傳遞選項更容易。
客戶端應用程序告訴服務他們是誰有什麼錯誤？或者，傳遞配置密鑰與一組參數化選項之間真的沒有區別嗎？
我可以看到的一個直接問題是，如果我們將服務打開到由第三方運行的另一個客戶端，我們必須在本地維護它們的配置設置。目前我們擁有兩個客戶端應用程序，所以這不是什麼問題。
你會怎麼做？
在一個分層的解決方案中，您應該始終將您的圖層視爲洋蔥般的圖層，並且依賴性應該始終向內，永不向外。
因此，您的GUI /應用層應該依賴於businesslogic層，businesslogic層應該依賴於數據訪問層和類似的。除非您對客戶端（web，win，wpf，cli）進行分類，或者將其推廣到客戶端配置文件（客戶端應用程序可以配置），否則我絕不會傳入調用應用程序的名稱，因爲這會使業務邏輯層意識到並依賴於外層。
我們在談論什麼樣的差異取決於應用程序的類型？如果你在這裏詳細闡述一些不同之處，也許有人可以就解決這個問題的其他方法提出一些有用的建議。
但我肯定會尋找其他方式，然後再沿着你描述的路線走。
從設計的角度來看，這與擁有不同配置文件的用戶沒有區別。從安全角度來看，我希望你的應用程序正在做一些事情來標識自己，以免一個應用程序的用戶找到一種方法來調用其他應用程序邏輯作爲黑客。 （圖像同時被黑手黨和銀行使用的人力資源應用程序，一個客戶會對共享應用程序主機上的其他客戶的應用程序進行黑客攻擊）
在.net中，設計並沒有這種感覺因爲證書存在於線程中（即，當您設置IIPrincipal時，該信息將在線程上傳遞 - 它與每個方法調用一起傳遞，但不作爲參數傳遞）。
也許您在找什麼更優雅設計的條款是ApplicationIdentity屬性。你必須寫一個自定義的，我現在不知道框架中的一個。
難道你不能創建兩個不同的服務，每個應用程序一個嗎？這兩個服務將共享大量的代碼，或者根據調用的外部服務調用具有不同參數化的單個內部服務。
這是一個很難討論的話題，沒有一個可靠的例子。
你對這種感覺是對的。發送客戶端類型來改變行爲是不正確的。記錄日誌並不是一個壞主意......但就是這樣。
這裏是我會做什麼：
想想你的代碼中的函數請求。你不會放置一個改變函數行爲的魔術參數。你會創建多個不同的函數。無論誰使用該功能，都會決定哪個人打電話。
那麼爲什麼客戶類型錯了？客戶類型本身沒有具體含義。它有很多含義，它們可能會隨着時間而改變。這只是信息性的，這就是爲什麼記錄方便的原因。操作環境確實具有特定的含義。
這是一個需要考慮的場景：如果開發的新客戶端類型與原始請求的兼容性稍有不同，會怎樣？現在你有兩個請求。 2個客戶端使用請求A和1個客戶端使用請求B.如果您將客戶端類型傳遞給每個請求，則服務器需要爲每種可能的客戶端類型工作。很難測試和維護！