获取目录属性以供显示的正确层是什么？
我有一个 Intranet 应用程序，需要我们校园内由 IT 实验室支持组织提供服务的各个地点的联系信息。 我们有一个包含联系信息的企业目录，因此我不会将实际的联系信息保留在数据库中，而是保留一个不可变的标识符，作为在我们的企业目录中查找人员的密钥（通过 Web 服务）。 我将通过公开网站查找联系信息。
问题在于，对基于 Web 的目录查找有用的 id 只是“某种程度上”不可变的，而不是我将存储在数据库中的 id。 使用人员的 Active Directory 登录 ID 可以最轻松地执行目录查找。 我将使用的称为主记录唯一 ID。
我的问题是：将链接的 MRUID 转换为 Active Directory 登录 ID 的最合理位置在哪里？
现在我正在表示层中进行翻译，并使用应用程序级缓存来减少对目录的查找。 目前只有一个网站，但我希望如果有其他网站需要执行此操作，我会将帮助程序类迁移到共享 Web 控件库。
我考虑过将代码放在数据层或业务层中，但由于缓存而选择不这样做。 缓存的方式和内容似乎更多是应用程序的功能，而不是其他层的功能。
我会对我可能没有考虑过的其他意见和想法感兴趣。
I have an intranet application that needs contact information for various locations on our campus that are served by our IT lab support organization. We have an enterprise directory that contains contact information so I'm not keeping the actual contact information in the database, but rather an immutable identifier that serves as a key to look the person up in our enterprise directory (via a web service). I'll be looking contact information up via a publicly available web site.
The problem comes in that the id that is useful to the web-based directory lookup is only "sort of" immutable and is not the id that I will store in the database. Directory lookups are most easily performed using the person's Active Directory login id. What I will be using is called the Master Records Unique ID.
My question is: where is the most reasonable place to do the translation from MRUID to Active Directory login id for the link?
Right now I'm doing the translation in the presentation layer, with application-level caching to reduce look ups to the directory. Currently there is only a single web site, but I would expect that if there are other web sites that need to do this, I would migrate the helper class to a shared web controls library.
I considered putting the code in the data or business layer, but opted not to because of the caching. How and what you cache seems to be more a function of the application rather than these other layers.
I'd be interested in other opinions and ideas that I may not have considered.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当遇到需要位于 ASP.NET 网站或 Web 应用程序的表示层中，但它也可能在其他 ASP.NET Web 应用程序中有价值的东西时，我发现创建一个具有依赖项的特殊类库很有用在 system.web 命名空间上。
具体来说，它将利用 HttpContext.Current 与托管该库的网站进行互操作。 我不确定，但我通常认为这是一个业务层程序集，但假设它托管在 Web 上下文中。
我将真正的业务代码（可能在非 Web 应用程序中使用的代码）保留在第三个程序集中。
拥有依赖于 Web 上下文的程序集允许您使用 HttpContext.Current 来了解请求和响应对象发生了什么，并允许您与 asp.net 缓存 API 和相关内容进行交互。 但它也使代码可移植，以便在多个 Web 应用程序中使用。
一般来说，这个依赖于 Web 的程序集也是我的 HttpModule 和 HttpHandler 所在的位置。
请记住，“层”是逻辑概念，而不是物理概念。 包含业务、DAL、甚至表示层类在一起的程序集没有任何问题。 类本身不应该混淆它们的角色，但是单个程序集可以包含来自设计中不同逻辑层的类。
When faced with something that needs to be in the presentation layer of an asp.net web site or web application, but it also may have value in other asp.net web applications I find it useful to create a special class library that has a dependency on the system.web namespace.
Specifically, it will make use of HttpContext.Current to interoperate with the web site that is hosting the library. I'm not sure, but I generally think of this as a business layer assembly, but one that assumes it is hosted in a web context.
I keep my true business code (code that might be used in a non-web application) in a third assembly.
Having an assembly that depends on the web context allows you to use HttpContext.Current to find out what is going on with request and response objects as well as allowing you to interact with the asp.net cache API and related stuff. But it also keeps the code portable for use in more than one web application too.
Generally this web-dependent assembly is also where my HttpModules and HttpHandlers live too.
Keep in mind though that "layers" are logical concepts, not physical ones. There is nothing wrong with an assembly that contains business, DAL, and even presentation layer classes together. The classes themselves shouldn't mix up their roles, but a single assembly can contain classes from different logical layer in your design.
您可以将其放置在业务层中并仍然使用缓存，可以使用企业库 在业务层中缓存应用程序块，或者通过在表示层的 ASP.Net 缓存中缓存业务层返回的值。
由于它来自与其他数据不同的位置，因此我不会将其放在与其他数据库代码相同的数据访问层中。
You could place it in your business layer and still use caching, either using the Enterprise Library Caching Application Block in the business layer, or by caching the value returned by the business layer in the ASP.Net cache in your presentation layer.
As it's coming from a different location to your other data I wouldn't put it in the same data access layer as the other database code.
我在工作中与其他一些开发人员讨论了这个问题，我们认为表示层是进行翻译的正确位置。 考虑使用相同业务/数据访问层的不同应用程序希望以不同方式转换数据的情况。 除非我们有明确定义的业务规则，规定个人身份应始终以某种形式显示，否则我想我会将其保留在原处，并根据需要将其迁移到 Web 控件库以支持多个前端。
I discussed this issue with some other developers at work and we decided that the presentation layer was the right place to do the translation. Consider the case where different applications that use the same business/data access layers want to translate the data in different ways. Unless we have a clearly defined business rule that states that individual identities shall always be displayed in a certain form, I think I'll leave it where it is and migrate it to a web controls library as needed to support multiple front-ends.