Кешування на рівні бізнесу проти кешування на рівні даних

Я завжди працював над проектами, де кешування здійснювалося на DAL, в основному саме тоді, коли ви збираєтесь здійснити виклик до бази даних, він перевіряє, чи є дані вже в кеші, і якщо вони є, він просто не робить дзвінок натомість повертає ці дані.

Я нещодавно читав про кешування на рівні бізнесу, тому в основному кешував усі бізнес-об’єкти. Одна з переваг, яку я бачу відразу, - це набагато кращі часи реакції.

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

Це, мабуть, занадто широко для остаточної відповіді. Особисто я вважаю, що шар доступу до даних є кращим місцем для кешування, просто тому, що він повинен бути дуже простим - записи надходять і виходять, і все.

Бізнес-рівень реалізує безліч додаткових правил більш високої складності, тому краще, якщо він також не повинен керувати проблемами щодо доступності для кожного об'єкта, на додаток до проблем з узгодженістю декількох об'єктів у тому ж класі (або навіть того ж методу) - це було б бути кричущим порушенням СРП.

(Звичайно, я зрозумів це лише після того, як мої класи обслуговування зросли до некерованої складності, коли вони намагалися одночасно кешувати і конфігурувати. Немає кращого викладача, ніж досвід, але ціна впевнено крута.)

Доступ до даних та шари збереження / зберігання є непереборно природними місцями для кешування. Вони роблять введення-виведення, роблячи їх зручним, легким місцем для вставки кешування. Смію сказати, що майже кожному шару DAL або стійкості, коли він буде дозрівати, буде надана функція кешування - якщо він не створений таким чином з самого початку.

Проблема - умисел . Шари DAL та стійкості мають відношення до відносно низькорівневих конструкцій - наприклад, записів, таблиць, рядків та блоків. Вони не бачать "бізнес" або об'єкти на рівні додатків, або не мають великого розуміння того, як вони використовуються на вищих рівнях. Коли вони бачать, як зачитують чи записують кілька рядків чи десяток блоків, не ясно, що вони представляють. "Обліковий запис Джонса, який ми зараз аналізуємо", не сильно відрізняється від "деяких базових довідкових ставок оподаткування, які додаток потребує лише один раз, і до яких він більше не посилатиметься". На цьому рівні дані - це дані - це дані.

Кешування на шарі DAL / стійкості ризикує мати «холодні» податкові довідкові дані, які сидять там, безглуздо займаючи кеш-пам'ять 12,2 МБ та переміщуючи деяку інформацію облікового запису, яка насправді буде інтенсивно використовуватися всього за хвилину. Навіть найкращі менеджери кешу мають справу з обмеженими знаннями про структури даних та з'єднання вищого рівня, і мало розуміють, які операції незабаром, і вони повертаються до алгоритмів здогадки .

Навпаки, кешування на рівні додатків або бізнес-шарів не настільки охайне. Він вимагає вставляти кеш-операції або підказки посеред іншої логіки бізнесу, що робить бізнес-код складнішим. Але компроміс полягає в тому, що, маючи більше знань про структурування даних на макрорівні та які операції надходять, у нього є набагато краща можливість наблизити оптимальну ефективність кешування ("ясновидиця" або "мінімум Беладі").

Незалежно від того, чи є вкладення відповідальності за кеш-пам'ять у код бізнесу / додатка сенсом, це виклик судження, і залежатиме від програм. У багатьох випадках, хоча відомо, що шари DAL / наполегливість не зможуть зрозуміти це «абсолютно правильно», компроміс полягає в тому, що вони можуть зробити досить хорошу роботу, що вони роблять це в архітектурно «чистому» та набагато більш інтенсивно випробуваному способі , а ловля низького рівня дозволяє уникнути збільшення складності коду бізнесу / програми.

Низька складність заохочує більшу коректність та надійність та швидший час виходу на ринок. Це часто вважається великим компромісом - менш ідеальне кешування, але краща якість, більш своєчасний бізнес-код.

Кешування на DAL - це просто і просто

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

Курси в бізнесі гнучкі

Кешування в бізнесі надає розробникам гнучкість визначити, чи буде корисне використання конкретного об'єкта від кешування. Залежно від структури додаткового сервісу додатків або автоматизованих процесів можуть змінюватися дані, кешовані в інших частинах. За допомогою кешування в бізнесі розробник може визначити, чи матиме певний бізнес-об’єкт можливі несвіжі дані та набувати результативності, чи мати найсучасніший стан бізнес-об’єкта за рахунок продуктивності.