• 使用Jdon框架6.0开发应用将变得异常简单，甚至无需XML配置文件，只需要两步：第一步：将存在依赖关联关系的两个类用@Service或@Component(两者性质一致)标注： @Service("helloService")public
  • 一晃眼搞了7、8年的企业应用管理和研究，各种技术、思想翻来覆去折腾了很久，最近总算是有点持拨云见目的感觉了，于是放出点大标题和各位论论道。 主要观点其实在一年半前，已经在jdon首发的文章“坚持发扬EJB、Spring的光辉思想，将组件化进行到底！”(可参
  • 今天被问及了一个问题：请说说AOP和SOA。 我的理解是他们全部起源于“封装”的思想，注重于业务功能和实现的分离，所以从根本上说他们没有什么区别。他们现实中区别在于分别注重于解决不同层面的问题，可以说是“封装”这个接口的不同实现。继续说起来其实IOC/DA icon
  • 我刚看struts2。在看源码。 看到struts2通过FilterDiepatcher委派，在FilterDispatcher里的有这么一段代码。 /** * Modify ActionMapper instance. * @param mapper New ins icon
  • 接触依赖注入有一段时间了，对于它的好处基本上都是这样说：“bean自己不再负责对象的依赖关系，从而降低对象之间的耦合。同时让开发者把精力放在业务逻辑的编写上。” 但我总怀疑是否真的降低了耦合，因为我们在获取想要的bean的时候还是一样的通过一个唯一的标识，对于既有的设计而言，这样做只是把存在 icon
  • 明明没有循环引用的，为什么总报这个错？ icon
  • 今天看POJOs IN ACTION书中有类似这样一段话“传统的J2EE应用程序使用JNDI作为一个组件访问另外一个组件的依据，比如JNDI访问EJB组件，JNDI访问Datasource获取服务器上的数据库连接池中的连接，但是JNDI的弱点在于它把应用程序和应用服务器耦合在一起，难于测试和维护。而 icon
  • 从IOC容器中取出一个JavaBean之后，是该用类对象来引用还是用接口对象来引用？不实现任何接口的类能用IOC管理吗？ icon
  • 对于spring中的IOC，大家都知道这个仅仅是对属性的依赖注入，也就是这种方式解决了类与类之间的依赖问题。现在大家的讨论好像都集中在域模型的是否充血的问题上，就是说是否给模型加上行为（业务方法）。这样我就想有没有一种方式可以实现方法的依赖注入的问题，这样是否就可以更大的解耦了呢？初 icon
  • 工厂模式的意义在于隐藏对象的创建细节，让客户端只知道如何使用而不用关心其创建，这个也算是类的职责分配问题，和现实生活中一样我们使用一个东西未必要自己创造它，目前的IOC也有类似的意思，相当于拿来主义，那么是不是有了IOC对于工厂这种方式就可以被弱化，甚至不用去使用，请BANQ给予指点！谢谢！ icon
  • 引用大哥的话：你只要使用一个IOC容器:Spring/Jdon/Hivemind，只要你提供setXXX操作，至于如何实现就不必你关心，Ioc容器自动照顾，一步到位啦。想知道ioc容器内部是怎么实现自动照顾的 icon
  • 示例中有如下一段代码p icon
  • 发现了一个IOC实现，推荐给那些想探索IOC技术的爱好者． 文档 icon
  • bang您好: 现在由于我公司的快速发展,活多了,因为减少项目的开发周期短,所以我们现在需要开发一些共用的组件,实现项目的可配置化.因为之前您提到过这方面的,想希望你给意见.谢谢.....非常感谢　 icon
  • 原始人：在A中引用BImpl的方法： class A { private IB b = new BImpl(); public void doPrint() { b.printHello(); }} icon
  • 我使用setter injection 实现dependency injection, 我现在的问题是，如何在不知道TagBeanImpl内部，有什么样静态引用的前提下， "自动地” 将这些静态引用赋值（注射进去）？ 谢谢！！！ 就好像用java的反射机制 icon
  • TestBO testBO; String s;//a public void setTestBO(TestBO testBO){ this.testBO=testBO; s="s";//b } testBO是要被注 icon
  • 我看jdon里面配置service的时候依赖一些component的时候，并没有指明依赖那个component呢，如： class="com.jdon.jivejdon.service.imp.account.Ac icon