Какой правильный уровень для получения атрибутов каталога для отображения?

Question

У меня есть приложение для внутренней сети, которое нуждается в контактной информации для различных мест в нашем кампусе, которые обслуживаются нашей организацией поддержки лаборатории ИТ. У нас есть корпоративный каталог, который содержит контактную информацию, поэтому я храню не фактическую контактную информацию в базе данных, а неизменный идентификатор, который служит ключом для поиска человека в нашем корпоративном каталоге (через веб-сервис). Я буду искать контактную информацию через общедоступный веб-сайт.

Проблема заключается в том, что идентификатор, который полезен для поиска в веб-каталогах, является «своего рода» неизменяемым и не является идентификатором, который я буду хранить в базе данных. Поиск в каталоге проще всего выполнить с помощью идентификатора пользователя Active Directory. То, что я буду использовать, называется уникальным идентификатором основных записей.

Мой вопрос: где наиболее разумное место для перевода MRUID в идентификатор входа Active Directory для ссылки?

Прямо сейчас я делаю перевод на уровне представления с кэшированием на уровне приложения, чтобы уменьшить количество обращений к каталогу. В настоящее время существует только один веб-сайт, но я ожидаю, что если есть другие веб-сайты, которым необходимо это сделать, я перенесу класс помощника в общую библиотеку веб-элементов управления.

Я подумал о том, чтобы поместить код на уровень данных или бизнес-уровень, но решил не делать этого из-за кэширования. Как и что вы кешируете, скорее всего, является функцией приложения, а не этих других слоев.

Меня интересовали бы другие мнения и идеи, которые я, возможно, не учел.

Answer 1

Когда сталкивается с чем-то, что должно быть на уровне представления веб-сайта asp.net или веб-приложения, но оно также может иметь значение в других веб-приложениях asp.net, я считаю полезным создать специальную библиотеку классов, которая зависит от пространства имен system.web.

В частности, он будет использовать HttpContext.Current для взаимодействия с веб-сайтом, на котором размещена библиотека. Я не уверен, но я обычно думаю об этом как о сборке бизнес-уровня, но предполагающей, что она размещена в веб-контексте.

Я храню свой настоящий бизнес-код (код, который может использоваться в не-веб-приложении) в третьей сборке.

Наличие сборки, которая зависит от веб-контекста, позволяет вам использовать HttpContext.Current, чтобы выяснить, что происходит с объектами запросов и ответов, а также позволяет взаимодействовать с API-интерфейсом кэша asp.net и связанными с ним материалами. Но он также сохраняет код переносимым для использования в нескольких веб-приложениях.

Как правило, эта веб-зависимая сборка также используется для моих HttpModules и HttpHandlers.

Имейте в виду, что "слои" - это логические понятия, а не физические. Нет ничего плохого в сборке, содержащей вместе классы бизнес, DAL и даже уровень представления. Сами классы не должны смешивать свои роли, но одна сборка может содержать классы из разных логических слоев в вашем проекте.

Answer 2

Я обсуждал эту проблему с некоторыми другими разработчиками на работе, и мы решили, что презентационный уровень был подходящим местом для выполнения перевода. Рассмотрим случай, когда разные приложения, использующие одни и те же уровни доступа к бизнесу / данным, хотят переводить данные по-разному. Если у нас нет четко определенного бизнес-правила, которое гласит, что отдельные идентификационные данные всегда должны отображаться в определенной форме, я думаю, что я оставлю их там, где они есть, и перенесу их в библиотеку веб-элементов управления, если это необходимо для поддержки нескольких внешних интерфейсов.

Answer 3

Вы можете поместить его на свой бизнес-уровень и по-прежнему использовать кэширование, либо используя библиотеку Enterprise Caching Application Block на бизнес-уровне, либо кэшируя значение, возвращаемое бизнес-уровнем в ASP.Net кеш в слое презентации.

Поскольку он поступает из другого места в другие ваши данные, я бы не поместил его в тот же слой доступа к данным, что и другой код базы данных.