Инъекция зависимостей во время выполнения с помощью Spring

Question

Мой текущий проект использует Spring, и наш архитектор решил разрешить Spring управлять объектами Services, Repositories и Factory, но НЕ объектами домена. Мы внимательно следим за дизайном, ориентированным на предметную область. Причина, по которой не используется пружина для доменных объектов, заключается в том, что пружина допускает только статическое внедрение зависимостей. Под внедрением статических зависимостей я подразумеваю, что зависимости указываются в конфигурации xml и они «замораживаются».

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

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

Может кто-нибудь посоветовать, если у пружины проблема с вышеуказанным сценарием?

Я мог бы использовать AOP для внедрения зависимостей, но тогда я не использую инфраструктуру Spring.

Answer 1

Я предлагаю вам прочитать раздел в документации Spring, касающийся Использование AspectJ для добавления объектов домена в Spring с зависимостью .

Интересно, что вы сказали: «Я мог бы использовать AOP для внедрения зависимостей, но тогда я не использую инфраструктуру Spring», учитывая, что AOP является основной частью инфраструктуры Spring. Вместе они очень хорошо сочетаются.

Приведенная выше ссылка позволяет прозрачно внедрять зависимости Spring AOP в объекты домена, которые создаются без прямой ссылки на инфраструктуру Spring (например, с помощью оператора new). Это очень умно, но требует некоторой глубокой обработки загрузки классов.

Answer 2

Внедрение / конфигурирование зависимостей Spring предназначено только для настройки низкоуровневой технической инфраструктуры, такой как источники данных, управление транзакциями, удаленное взаимодействие, точки монтирования сервлета и т. Д.

Вы используете Spring для маршрутизации между техническими API и вашими сервисами, а внутри этих сервисов вы просто пишете нормальный Java-код. Держать Spring подальше от вашей доменной модели и реализации сервисов - это хорошо. Для начала, вы не хотите связывать бизнес-логику вашего приложения с одной структурой или позволять низкоуровневым техническим проблемам проникать в модель предметной области вашего приложения. Java-код гораздо проще изменить в IDE, чем XML-конфигурацию Spring, поэтому хранение бизнес-логики в java позволяет быстрее предоставлять новые функции и проще поддерживать приложение. Java гораздо более выразителен, чем XML-формат Spring, поэтому вы можете более четко моделировать доменные концепции, если будете придерживаться простой Java.

Answer 3

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