玩框架java依赖注入 – 何时使用单例

前端之家收集整理的这篇文章主要介绍了玩框架java依赖注入 – 何时使用单例前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我试图找出如何在Play Framework 2.4中使用依赖注入.我熟悉一般原则,但并不真正理解对设计的影响.我的一般推理是,控制器类中的静态方法太像使用全局变量,并且很容易导致线程安全等问题,而且通常会鼓励糟糕的设计.因为Play现在鼓励切换到依赖注入,我也应该切换.

令我感到困惑的是在这种背景下的良好做法.当我阅读Play官方文档时,它会简要介绍依赖注入,然后及时提到@Singleton注释.并且可用的示例(http://www.typesafe.com/activator/template/play-guice)也讨论了单个“WelcomeTextGenerator”类.

所以我想知道,我应该使用单例对象,因为这些例子似乎意味着什么?如果是这种情况,与旧的静态方法方法相比有什么优势?是否存在应该是单例的特定对象类型(例如,控制器?),是否存在不将对象标记为单例的性能影响?

解决方法

So I am wondering,should I be using singleton objects as the examples seem to imply? If this is the case,what is the advantage compared to the old static methods approach?

依赖注入是一种将应用程序连接在一起的技术.您编写的组件并不直接相互依赖.而是将组件注入彼此.这样,您只需交换应用程序的整个部分,而无需触及任何一行代码.在编写单元测试时,依赖注入特别有用.

与静态方法相比,您可以使用所有那些花哨的OOP内容.问题基本上是“静态方法有哪些缺点?”

Are there specific object types (e.g.,controllers?) that should be singletons,and are there performance implications to not marking objects as singletons?

Play或更具体地说,只要默认情况下注入依赖项,Guice就会创建一个新对象.将它们标记为@Singleton将只创建一个对象,并在所有注入中重复使用完全相同的对象.换句话说:单身人士保存一些对象创建垃圾收集,但需要同步来初始化对象.

根据您的经验来解决使用@Singleton时的问题(source):

>有状态对象,例如配置或计数器
>构造或查找成本高昂的对象
>绑定资源的对象,例如数据库连接池.

Guice提供了非常全面的documentation顺便提一下.我强烈建议浏览一段时间.

猜你在找的Java相关文章