Архитектура WebApplication. Рекомендации по сохранению HTTPContext на уровне презентации.

Question

Большинство рекомендаций по архитектуре приложений настоятельно рекомендуют, чтобы только Presentation Layer имел доступ к HTTPContext (для обеспечения слабой связи, уменьшения зависимостей, повышения тестируемости и т. Д.).

Итак, как люди относятся к кешированию и сеансу? Для определения того, какие элементы нуждаются в кэшировании, чтобы максимально повысить производительность приложений, необходимы очень специфические знания DataAccess и Business Logic. Однако и веб-приложение ASP.Net доступ к ним обеспечивается через HTTPContext.

Одним из вариантов может быть создание CacheFactory и SessionFactory, а также интерфейса ICache и ISession, а затем каким-то образом использовать принцип DI для передачи ISession и ICache каждому методу в BLL и впоследствии DA Layer, который в этом нуждается.

Это действительно то, что в итоге делают разработчики? Есть ли другой, более простой способ справиться с этим?

Спасибо за любой совет.

Answer 1

Лично, если я занимаюсь разработкой только для ASP.NET (веб) и знаю, что библиотеки классов будут ориентированы только на веб, у меня нет проблем со ссылкой на System.Web или любую другую сборку по мере необходимости. Иногда практичность должна быть на первом месте.

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

Главное, чтобы вы четко понимали, что рекомендует лучшая практика. На этом этапе вы можете принимать рациональные решения о том, что должно применяться к каждому проекту или ситуации. Это не всегда подходит как перчатка.

Answer 2

По моему опыту, кэширование выполняется на определенном слое - и то, что вы кэшируете, применяется в рамках этого слоя, поэтому:

• Вы можете кэшировать данные в DAL, чтобы DAL возвращал их из памяти, а не снова нажимая на БД; поэтому здесь мы кешируем «необработанные» данные на уровне данных.
• BL может кэшировать аналогичные данные (скажем, POCO) - другими словами, «логические» данные, к которым применен BL; поэтому здесь мы кешируем данные BL на уровне BL.
• Ваш пользовательский интерфейс может кэшировать (как вы уже догадались) информацию, которая создается на уровне пользовательского интерфейса - например, представление данных в виде веб-страницы, XML и т. Д.

Когда вы смотрите на кэширование, как архитектор / разработчик системы вы принимаете решения о том, что стоит кэшировать, как правило, это будет обусловлено необходимостью баланса:

• Производительность должна поражать конкретную цель.
• Какие варианты времени (и стоимости) у вас есть.

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

Еще одна вещь, которую следует учитывать, - чем больше вы можете кэшировать ближе к потребителю, тем меньше должна быть общая обработка; другими словами, если вы можете кэшировать на уровне пользовательского интерфейса, то слои BL и DAL даже не заглянут в него (вам не нужно будет добавлять туда кэширование).

Сейчас я хочу спросить вас, чего именно вы пытаетесь достичь.

Хотя все, что я сказал, является правдой (насколько мне известно), все это основано на предположении, что мы предоставляем «вертикальные» фрагменты функциональности системы (например, «создание счета», «добавление продукта»). " так далее); есть еще одна модель, которую вы можете применить - модель сквозных проблем.

Подумайте о чем-то вроде ведения журнала - каждая часть вашей системы (UI / BL / DAL) должна иметь возможность регистрировать системные события; мой любимый инструмент для этого - MS Enterprise Libraries (MSEntLibs). Когда я работаю с ними, я считаю их «черным ящиком» - самостоятельным блоком. Я (по выбору) понятия не имею, как они устроены - важно то, что они изолированы и имеют зависимости, которыми относительно легко управлять.

MSEntLibs может вести журнал в базе данных, но если я вызываю метод ведения журнала MSEntLibs (для входа в БД) прямо из моего пользовательского интерфейса (и пропускаю мой BL), мне все равно.

Так что в зависимости от того, что вы пытаетесь сделать, правильный ответ будет либо:

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