Кэширование на бизнес-уровне против Кэширования на уровне данных

Я всегда работал над проектами, в которых кеширование выполнялось на DAL, в основном именно тогда, когда вы собираетесь выполнить вызов в базу данных, он проверяет, есть ли данные в кэше, и если он есть, он просто не выполняет вызов и вместо этого возвращает эти данные.

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

Когда бы вы предпочли одно другому? и Является ли кэширование на бизнес-уровне обычной практикой?

c# design design-patterns caching

— Эмма
источник

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

— JDT

Нет, это не так, и после прочтения ответов, я думаю, что я буду придерживаться только кэширования в DAL. Приветствия.

— Эмма

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

— AK_

Ответы:

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

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

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

— Килиан Фот
источник

почему кеширование должно быть сложным? это может быть сделано с АОП и парой аннотаций. Это все еще нарушение SRP? почему это не когда сделано в DAL? также IMHE Я никогда не видел, чтобы классы обслуживания были «слишком сложными» для кэширования; независимо от сложности, сервис можно рассматривать как черный ящик, а его результат можно кэшировать

— user1075613

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

Проблема в намерениях . Уровни DAL и персистентности имеют дело с относительно низкоуровневыми конструкциями - например, с записями, таблицами, строками и блоками. Они не видят «бизнес» или объекты уровня приложения, или не имеют большого понимания того, как они используются на более высоких уровнях. Когда они видят несколько строк или дюжину читаемых или записываемых блоков, не ясно, что они представляют. «Учетная запись Jones, которую мы сейчас анализируем», не сильно отличается от «некоторых базовых справочных данных по ставке налогообложения, которые нужны приложению только один раз и к которым оно больше не будет ссылаться». На этом уровне данные есть данные есть данные.

Кэширование на уровне DAL / персистентности может привести к тому, что «холодные» справочные данные о налогах окажутся там, бесполезно занимая 12,2 МБ кеша и вытесняя некоторую информацию об учетной записи, которая, фактически, будет интенсивно использоваться в течение минуты. Даже самые лучшие менеджеры кэша имеют дело со скудными знаниями о структурах данных и соединениях более высокого уровня, и мало понимают, какие операции будут происходить в ближайшее время, поэтому они прибегают к алгоритмам угадывания .

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

То, имеет ли смысл вставлять ответственность за управление кэшем в код бизнеса / приложения, зависит от решения и будет зависеть от приложений. Во многих случаях, хотя известно, что слои DAL / постоянство не получат его «совершенно правильно», компромисс заключается в том, что они могут сделать довольно хорошую работу, что они делают это «архитектурно» чистым и гораздо более интенсивно тестируемым способом и этот низкоуровневый перехват позволяет избежать усложнения кода бизнес / приложения.

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

— Джонатан Юнис
источник

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

— Эмма

Одна проблема с моделью «слоев» состоит в том, что эффективные механизмы кэширования часто должны использовать информацию, которая недоступна на одном уровне. Что бы вы думали, если бы бизнес-уровень передавал «подсказки» уровню данных о его общем «плане»? Уровень данных мог изначально игнорировать большинство таких подсказок, но если бы было обнаружено узкое место, можно было бы добавить некоторую логику, которая, при наличии определенных подсказок, изменила бы стратегии кэширования для конкретного бизнеса.

— суперкат

Отличная мысль, @supercat. Я собирался упомянуть стратегию хинтинга / прагмы, но ответ был уже долгим. Но ты совершенно прав. Подсказки бизнес-уровня нижним уровням о том, как расставить приоритеты в кэшах или «что зафиксировать», - довольно распространенный / полезный способ получить кэширование более высокого уровня, не заставляя бизнес-код делать все это, или слишком увлекаться управлением собственным хранилищем иерархия.

— Джонатан Юнис

@JonathanEunice: Хорошая вещь о подсказках в том, что на начальном этапе коду не нужно ничего делать с ними. У многих систем есть несколько очевидных узких мест, которые доминируют в их производительности, но может быть трудно предсказать, какие из них будут достаточно плохими, чтобы иметь значение. Добавление небольшого количества уродливой логики кэширования в нескольких критических точках может быть лучше, чем разбрасывание большого количества логики кэширования в местах, которые действительно не имеют значения.

— суперкат

В точку. Особенно, если у вас «довольно хорошее» низкоуровневое кэширование уже на уровне постоянства / доступа. Вам может потребоваться лишь небольшая дополнительная информация о приоритетах, чтобы перейти от «довольно хорошо» к «действительно хорошо».

— Джонатан Юнис

Кэширование на DAL просто и просто

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

Кеширование в бизнесе гибкое

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

— JDT
источник