Это вопрос о том, следует ли нам вообще использовать «настоящий» АОП (под «настоящим» я подразумеваю количественное определение и забвение , так что вы можете включить аспекты глобально и на 100%прозрачно для системы).Мое мнение состоит в том, чтобы избежать 100% прозрачных решений каждый раз, когда вы можете.Если вы находитесь на этапе разработки, будет лучше спроектировать вашу систему так, чтобы вам не приходилось выполнять трюки, такие как ткачество AOP на промежуточном уровне кода.
С другой стороны, это будеточень беспокоиться о том, чтобы писать вопросы о кэшировании для каждого компонента / интерфейса, который вам нужен, независимо от того, как вы это сделаете.Самый очевидный способ, который мне пришёл в голову, - это создать кеширующий класс Decorator для каждого кешируемого класса - одна вещь повторяется много раз.
Итак, путь, по которому я попытаюсь пойти, - это составить представление об АОП с использованием некоторого расширения IoC, основанного на динамическом проксировании.При извлечении объекта из IoC контейнер может проверить свою конфигурацию, если кэш будет применен для данного типа, и если это так, создать основанный на интерфейсе динамический прокси с кэшированием.Это решение не заставляет вас писать много похожего кода и менее запутанно, чем «настоящий» AOP, благодаря своей видимости в исходном коде.Есть несколько реализаций, подобных этой, но вы не указали ни одного языка, поэтому я не могу предложить ни одного.