Кэширование ДАО Java
Я разрабатываю среднее приложение Java, и я сталкиваюсь с небольшой проблемой из-за моего отсутствия опыта.
У меня есть пользовательский ДАО, который получает объекты "Статьи" от Базы данных. Я имею Article классу и ДАО назвали метод getArticle(int id), этот метод возвращается Article. Article имеет a Category объект, и я использую ленивую загрузку.
Так, когда я запрашиваю на категорию статьи (Article a = new Article(); a.getCategory();) Article класс добирается Category от ДАО и затем возвращает его.
Я теперь думаю для кэширования его, поэтому когда я запрашиваю многократно к категории статьи, база данных только запрашивается одно время.
Мой вопрос: куда я должен поместить тот кэш? Я могу поставить его Article класс (в DTO), или я могу поместить его на класс ДАО.
Что Вы говорите?
5 ответов
Мой вопрос в том, куда мне следует поместить этот кэш? Я могу поместить его на классе Article (в DTO), или я могу поместить его в класс DAO.
Как отметили другие, это действительно похоже на повторное изобретение колеса. Но давайте все равно рассмотрим оба случая, чтобы вы лучше поняли, как работает ORM.
Если вы храните категорию в статье, то одна и та же категория будет загружаться снова и снова при обращении к разным статьям.
getCategory() {
if( category == null ) { category = <load from DAO> }
return category;
}
Если хранить ее в DAO, то все статьи с одной и той же категорией получат пользу от кэша, но вам нужно позаботиться об обновлении кэша при изменении категории.
saveCategory( Category c ) {
cache.put( c.id, c );
<save in database>
}
Проблема с этим подходом заключается в том, что (1) кэш может стать большим со временем, и (2) это внешнее обновление в базе данных никогда не будет отражено, если у вас нет механизма таймаута или способа очистить кэш.
На самом деле, ORM, такие как Hibernate, имеют три уровня кэширования:
- Сама сущность. Когда категория лениво загружается, она сохраняется в сущности статьи для последующего прямого доступа.
- Кэш первого уровня. Это кэш текущей сессии/транзакции. Одна и та же сущность не будет загружена дважды, а будет извлечена из кэша.
- Кэш второго уровня. Это кэш всех сессий/транзакций. Он соответствует варианту кэширования значения в DAO. Кэш второго уровня иногда сложнее по причинам, о которых я говорил выше.
Надеюсь, вы лучше видите недостатки/преимущества каждого типа кэша. За дополнительной информацией обратитесь к документации по популярным ORM. Эти вопросы являются общими и хорошо документированы.
Рассмотрите возможность использования Hibernate или даже более простой его формы (JPA)
Это зависит от того, используете ли вы Статья единственный класс для прямого доступа к DAO или нет.
Лично я бы реализовал кеширование в статье из-за того простого факта, что не всем, кто использует DAO, потребуется кеширование.Также с точки зрения того, что один класс делает одно и только одно, поскольку у вас уже есть отложенная загрузка в статье , не имеет смысла затем перемещать часть способа загрузки в DAO
Рассматривали ли вы возможность использования Hibernate ?
Целью DAO является абстрагируйте механизм настойчивости. Поскольку «откуда» эта категория (БД, файл на диске, сетевой сокет, кэш) является частью этого механизма сохранения, DAO должен «скрывать» ее от объекта, который ее использует.