什麼是正確的層獲取目錄屬性的顯示？

Question

我有一個Intranet應用程序，需要我們的IT實驗室支持組織提供的校園各個位置的聯繫信息。我們有一個包含聯繫信息的企業目錄，因此我沒有將實際的聯繫信息保存在數據庫中，而是一個不可變的標識符，用作在企業目錄中查看人員的關鍵（通過Web服務）。我會通過公開的網站查找聯繫信息。

問題在於，對基於Web的目錄查找有用的id只是「排序」不可變的，而不是我將存儲在數據庫中的id。目錄查找最容易使用該用戶的Active Directory登錄標識執行。我將使用的稱爲主記錄唯一ID。

我的問題是：哪裏是最合理的地方做翻譯從MRUID到活動目錄登錄ID的鏈接？

現在我正在表現層中進行翻譯，使用應用程序級緩存來減少查找目錄。目前只有一個網站，但我希望如果有其他網站需要這樣做，我會將助手類遷移到共享網絡控件庫。

我認爲把代碼放在數據或業務層，但選擇不要因爲緩存。緩存的方式和方式似乎更多地是應用程序的功能，而不是其他層。

我會對我可能沒有考慮過的其他意見和想法感興趣。

Answer 1

當面臨需要在asp.net網站或web應用程序的表示層中的東西，但它也可能在其他asp.net web應用程序中有價值時，我發現創建一個特殊的類庫它依賴於system.web命名空間。

具體來說，它將利用HttpContext.Current與託管該庫的網站進行互操作。我不確定，但我通常認爲這是一個業務層組件，但假設它是在Web上下文中託管的。

我在第三個程序集中保留了我的真實商業代碼（可能用於非web應用程序的代碼）。

擁有一個依賴於Web上下文的程序集允許您使用HttpContext.Current來查找請求和響應對象的情況，以及允許您與asp.net緩存API和相關內容進行交互。但它也使代碼可移植以用於多個Web應用程序。

通常這個網絡相關的程序集也是我的HttpModules和HttpHandlers所居住的地方。

請記住，「層」是邏輯概念，而不是物理概念。包含業務，DAL甚至表示層類的程序集沒有任何問題。這些類本身不應混淆它們的角色，但單個程序集可以包含來自設計中不同邏輯層的類。

Answer 2

您可以將它放在業務層中，並使用業務層中的企業庫Caching Application Block，或者將業務層返回的值緩存到表示層中的ASP.Net緩存中，然後使用緩存。

由於它來自與其他數據不同的位置，因此我不會將它放在與其他數據庫代碼相同的數據訪問層中。

Answer 3

我與其他一些開發人員在工作中討論過這個問題，我們決定表示層是翻譯的正確位置。考慮使用相同業務/數據訪問層的不同應用程序想要以不同方式翻譯數據的情況。除非我們有一個明確定義的業務規則，規定個人身份應始終以某種形式顯示，否則我認爲我會離開它並將其遷移到Web控制庫以根據需要支持多個前端。