依赖注入和服务启动/关闭

时间:2013-03-22 19:19:34

标签: scala dependency-injection

我的应用程序中的某些软件组件需要启动和关闭活动。

问题1:在Scala中启动和停止此类“服务”的最佳做法是什么?

我在我的应用程序中使用依赖注入(DI),目前的理解是DI 声明软件组件之间的依赖关系,但应该是side-effect free(即,DI机制不应该启动/停止服务本身)。因此DI与服务激活正交。

然而,似乎存在重叠:假设我的应用程序包含NotificationService,而SchedulingService又使用{{1}}。所以我将调度服务实现注入我的通知服务实现,手动启动和停止这些服务。但是,DI框架具有所有手头的信息,以了解哪些服务需要实例化(从而启动/停止),哪些服务取决于哪些服务(以及因此需要启动/停止服务的顺序)。因此它可以提供启动/停止它们的方法,为我节省一些样板代码!

问题2:他们是否曾试图扩展DI(例如,Guice)以记录注入的服务并提供启动/停止服务的方法?

1 个答案:

答案 0 :(得分:1)

在问题1中,依赖注入策略在Java中已经很好地建立,并且这些策略通常可以直接转换为Scala。但是,我认为Scala可以更好:它的主要构造函数非常适合基于构造函数的依赖注入,通常被认为是各种方法中最不混乱的(其他方法是setter注入,注释注入等)。

在最近的一个项目中,我们最初使用过的是Spring,但是改为使用 less is more 策略,完全放弃了Spring。

  • 我们在测试驱动的DI面向对象的方式中使用Scala,几乎没有XML(当然,对于webapp来说,剩下的web.xml是必需的。)
  • 单个Bootstrap类以正确的顺序配置了所有资源和服务,并进行了必要的依赖注入。
  • Bootstrap当然是从web.xml开始的。
  • 所有内容都经过单元测试以外的Bootstrap,而是通过集成测试进行测试。

给定一组组件,连接几个备用配置只需编写不同的Bootstraps。纯粹在Scala中执行此操作会带来IDE中代码透明性和重构支持的相当大的好处,并且相对较少。

关于问题2,我没有具体答案。但我可以推荐 less is more 方法;如果不需要框架,问题可能就不那么重要了。