У меня следующая ситуация:
Три конкретных класса обслуживания реализуют интерфейс службы: один - для сохранения, другой - для уведомлений, третий - для добавления точек к конкретным действиям (геймификации). Интерфейс имеет примерно следующую структуру:
public interface IPhotoService {
void upload();
Photo get(Long id);
void like(Long id);
//etc...
}
Я не хотел смешивать три типа логики в одном сервисе (или, что еще хуже, в классе контроллера), потому что я хочу иметь возможность изменить их (или закрыть их) без каких-либо проблем. Проблема возникает, когда мне приходится вводить конкретную службу в контроллер для использования. Обычно я создаю четвертый класс с именем примерно ApplicationNamePhotoService, который реализует тот же интерфейс и работает как оболочка (посредник) между остальными тремя службами, которая получает входные данные от контроллера и соответственно вызывает каждую службу. Хотя это и рабочий подход, который создает много стандартного кода.
Это правильный подход? В настоящее время я не знаю о лучшем, хотя я буду очень признателен за то, чтобы узнать, можно ли декларативно (в контексте) объявить последовательность выполнения и добавить в контроллер экземпляр обертки, созданный на лету.
Кроме того, было бы неплохо кэшировать некоторые вещи между тремя сервисами. Например, все используют DAO, то есть иногда делают одни и те же вызовы БД снова и снова. Если бы вся логика была в одном месте, чего можно было бы избежать, но сейчас ... Я знаю, что возможно включить некоторое кэширование на основе запросов или сеансов. Можете ли вы предложить мне пример кода? Кстати, я использую Hibernate для персистентной части. Уже предусмотрено какое-то кэширование (возможно, если они находятся в одной транзакции или чем-то еще - с этой я полностью потерялся)