我有一个 Intranet 应用程序，它需要我们校园内各个地点的联系信息，这些地点由我们的 IT 实验室支持组织提供服务。我们有一个包含联系信息的企业目录，所以我没有将实际的联系信息保存在数据库中，而是一个不可变的标识符，用作在我们的企业目录中查找该人的键（通过 Web 服务）。我将通过一个公开的网站查找联系信息。
问题在于对基于 Web 的目录查找有用的 id 只是“某种”不可变的，而不是我将存储在数据库中的 id。使用人员的 Active Directory 登录 ID 最容易执行目录查找。我将使用的称为主记录唯一 ID。
我的问题是：将链接从 MRUID 转换为 Active Directory 登录 ID 的最合理位置在哪里？
现在我正在表示层中进行翻译，使用应用程序级缓存来减少对目录的查找。目前只有一个网站，但我希望如果有其他网站需要这样做，我会将帮助程序类迁移到共享的 Web 控件库。
我考虑将代码放在数据或业务层中，但由于缓存而选择不这样做。您缓存的方式和内容似乎更多是应用程序的功能，而不是这些其他层。
我会对我可能没有考虑过的其他意见和想法感兴趣。
当面对需要在 asp.net 网站或 web 应用程序的表示层中的东西时，但它也可能在其他 asp.net web 应用程序中有价值时，我发现创建一个具有依赖关系的特殊类库很有用在 system.web 命名空间上。
具体来说，它将利用 HttpContext.Current 与托管库的网站进行互操作。我不确定，但我通常认为这是一个业务层程序集，但假设它托管在 Web 上下文中。
我将真正的业务代码（可能在非 Web 应用程序中使用的代码）保存在第三个程序集中。
拥有一个依赖于 Web 上下文的程序集允许您使用 HttpContext.Current 来找出请求和响应对象的情况，并允许您与 asp.net 缓存 API 和相关内容进行交互。但它也使代码保持可移植性，以便在多个 Web 应用程序中使用。
通常，这个依赖于 Web 的程序集也是我的 HttpModules 和 HttpHandlers 所在的地方。
请记住，“层”是逻辑概念，而不是物理概念。将业务、DAL 甚至表示层类一起包含的程序集没有任何问题。类本身不应混淆它们的角色，但单个程序集可以包含来自设计中不同逻辑层的类。
您可以将它放在业务层中并仍然使用缓存，或者使用业务层中的企业库缓存应用程序块，或者通过在表示层的 ASP.Net 缓存中缓存业务层返回的值。
由于它来自与您的其他数据不同的位置，因此我不会将其与其他数据库代码放在同一数据访问层中。
我在工作中与其他一些开发人员讨论了这个问题，我们认为表示层是进行翻译的正确位置。考虑使用相同业务/数据访问层的不同应用程序希望以不同方式转换数据的情况。除非我们有明确定义的业务规则，规定个人身份应始终以某种形式显示，否则我认为我会将其保留在原处，并根据需要将其迁移到 Web 控件库以支持多个前端。