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