什么是正确的层获取目录属性的显示？

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控制库以根据需要支持多个前端。