Spring的运行时dependency injection

我目前的项目是利用Spring,我们的架构师决定让Spring管理服务,存储库和Factory对象,但不管理域对象。 我们正在密切关注域驱动设计。 不对域对象使用spring的原因主要是spring只允许静态dependency injection。 静态dependency injection的意思是在xml配置中指定依赖关系并且它们被“冻结”。

我可能错了,但我目前的理解是,即使我的域只利用接口与对象进行通信,但spring的xml配置迫使我指定具体的依赖。 因此,必须在部署时解决所有具体的依赖关系。 有时,这是不可行的。 我们的大多数用例都基于根据运行时数据或从最终用户接收的消息注入特定类型。

我们的大部分设计都遵循命令模式。 因此,当我们收到命令时,我们想构建我们的域模型,并根据从命令接收的数据,我们将特定的类型集注入到我们的聚合根对象中。 因此,由于缺乏spring基于运行时数据构建域模型的能力,我们不得不使用静态工厂方法,构建器和工厂模式。

有人可以建议spring是否有上述情况的问题?

我可以使用AOP注入依赖项,但后来我没有利用spring的基础架构。

我建议你阅读Spring文档中有关使用AspectJdependency injectionSpring对象的部分 。

有趣的是,你说“我可以使用AOP注入依赖关系,但后来我没有利用spring的基础设施,”考虑到AOP是Spring基础架构的核心部分。 两人走得很好。

上面的链接允许您让Spring的AOP透明地将依赖项注入到创建的域对象中,而无需直接引用Spring基础结构(例如使用new运算符)。 它非常聪明,但确实需要一些深层次的类加载修补。

Spring的dependency injection/配置仅用于配置低级技术基础架构,例如数据源,事务管理,远程处理,servlet挂载点等。

您使用spring在技术API和服务之间进行路由,在这些服务中,您只需编写普通的Java代码。 保持Spring远离您的域模型和服务实现是一件好事。 首先,您不希望将应用程序的业务逻辑绑定到一个框架,或者让低级技术问题“泄漏”到您的应用程序域模型中。 Java中的Java代码比Spring的XML配置更容易修改,因此在java中保留业务逻辑可以让您更快地交付新function并更轻松地维护应用程序。 Java比spring的XML格式更具表现力,因此如果您坚持使用普通Java,您可以更清晰地模拟域概念。

Spring的dependency injection(以及一般的dependency injection)基本上用于将服务,存储库和工厂等连接在一起。它不应该直接处理需要动态响应命令等的事情,其中​​包括域的大部分内容对象。 相反,它允许您连接要用于执行这些操作的对象,从而控制这些操作的完成方式。