我正在使用错误构建的spring应用程序。而不是使用IOC,需要引用的对象从上下文中提取引用:
BeanFactory b = SingletonBeanFactoryLocator.getInstance().
useBeanFactory("factory").getFactory();
Bean foo = (FOO)beanFactory.getBean("foo");
撇开非IOC设计,这会产生什么其他不利影响?例如,这是否具有任何特定的性能影响?有没有办法可以导致创建其他上下文或对象引用?这可能导致其他任何令人不愉快的事情吗?
答案 0 :(得分:1)
直接想到的一个可能的问题是,如果在函数方法中使用该代码而不是某些初始化方法,则会重新获取bean,这很可能会减慢速度。
这也不是真正可维护的,如果更改了bean的名称,则必须手动更新所有对它的引用,否则什么都不会起作用。这当然扩展到依赖于其他bean的bean,甚至那些bean也依赖于其他bean,类似于DataSource作为bean,用于非事务性数据库查询的公共JDBC模板,它被注入到通用容器类中,其他类获取此类对象。
答案 1 :(得分:1)
我认为唯一真正的“性能问题”是对getBean()的额外调用;如果这被称为非常多次,它可能会产生影响。同样重要的是要考虑在这种情况下其他操作的成本是多少:如果您正在执行诸如查询数据库或与另一个网络建立高延迟连接之类的事情,那么它可能不会很重要。但是,如果在GUI编程中屏幕刷新的情况下发生这种情况,那么它可能会非常昂贵。
无论是从容器中注入还是从容器中取出对象,Spring给你的任何其他功能(AOP,作用域bean等)的行为都是一样的。
答案 2 :(得分:1)
我想到了一句古老的短语“你可以用任何语言编写fortran”。使用spring作为服务定位器听起来就像你错过了大多数让春天变得美好的东西。 Spring也不是一个漂亮的服务定位器。这也使得进行单元测试变得更加困难,因为你松开了一些非常好的松耦合。 (你用这种方式收紧了耦合)
IMO这些论点足以成为转换的理由。我甚至不会开始谈论性能,其他人已经指出,除非你处于紧张的循环中,否则这种性能并不可能。
从好的方面来说,你可能很容易转换为弹簧注释,这可能是你的代码的原作者没有做“正确”弹簧的原因;他不喜欢所有的xml。使用注释,您不需要所有xml。