Как мне кэшировать свои бизнес-объекты, чтобы избежать обращений к базе данных? - PullRequest
Новая
       25

Как мне кэшировать свои бизнес-объекты, чтобы избежать обращений к базе данных?

0 голосов
/ 02 сентября 2010

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

Это приложение является веб-приложением ASP.net 3.5 с типичным пользовательским интерфейсом.-> Бизнес -> шаблон DAL.

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

В настоящее время не существует единой точки реализации этих объектов, как реализация фабрики или что-то в этих строках.Реализация объекта просто разбросана повсюду.

Один вариант, о котором я думал, - это инкапсулировать всю логику инсталяции на фабриках - и встроить логику на фабриках для кэширования объектов и возврата соответственно.

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

Однако оба вышеупомянутых варианта являются достаточно инвазивными и могут повлечь за собой серьезную, если не полную модернизацию, затрагивающую весь бизнес-уровень, что вызывает у меня серьезную озабоченность, поскольку НЕТ (читай zilch, nada, zero,большой -O) автоматизированные модульные тесты для любой части кода.

Я хотел бы узнать следующее:

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

  2. При отсутствии 1, есть ли какие-либо более простые для реализации предложения, которые могут иметь людипо сравнению с двумя вариантами выше?

И нет, уйти из компании - это не выход - и не только пока!: -)

Ответы [ 2 ]

3 голосов
/ 02 сентября 2010

Найдите худших нарушителей с помощью профилирования и запомните их звонки.

ответ на комментарий

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

Вот дешевый пример: 

define square_root(n):
   if cache[n] does not exist then
      cache[n] = compute_root(n)

   return cache[n]

Это означает, что при первом вызове square_root(1729) потребуется время для вычисления корня. Все последующие вызовы square_root(1729) потребуют только поиск в кэше. Если этот вызов больше не будет выполнен, вы потеряете время и пространство для кэширования.

Таким образом, для запоминания square_root требуется только уникальный результат для n. Полезна ли оптимизация - это фактор фактического использования.

0 голосов
/ 02 сентября 2010

Кэширование запекается в ASP.Net, и в .Net 4.0 (я знаю, вы еще не переключились) такое же кэширование может использоваться где угодно, внутри или снаружи классов ASP.Net.

Вам все еще нужно будет контролировать объект. Я предлагаю структуру внедрения зависимости. Мне нравится autofac, это позволит вам просто запросить новые объекты у какого-либо поставщика, внедренного в зависимость, и решить, как вы собираетесь обрабатывать кэширование в этом поставщике.

Вы пришли к нам с одной проблемой, а я дал вам 3 (научитесь использовать и внедрять инфраструктуру внедрения зависимостей, научитесь использовать кэширование asp.net, используйте стратегию кэширования для решения проблем с производительностью), но это, вероятно, ваша самая гибкая и поддерживаемая ставка.

...