关于类层之间的疑惑

DAO可以是单列的，为什么？因为对于通常运用,sessionfactory是单列的，dao中有一个final sessionfactory，为什么不能是单列？？

DAO根本就不关并发的事，为什么？ 因为一般DAO中几乎没有“共享对象”（除非你自己在dao定义了些静态变量），除了sessionfactory,datasource；
并发仅与连接池相关对象有关(datasource)。

new 是典型的面向实现而不是面向抽象，是直接依赖而非反转依赖。如果你用new，那就意味着你的这一行代码已经死死的依赖于了你new的这个实现类，事实中，这个依赖可能是对你刚刚new的这个类的任何一个“兄弟姐妹”类，但你已经更丢行了和其它“兄弟姐妹”类打交道的可能

其实又如何呢，都是理论上的东西~~没有IOC前，并一样写程序？

面向接口编程在很多场合的确很有用，因为可以和其它“兄弟姐妹”类打交道，
但在action==>service==>dao这样的模式下，一个dao接口往往就一个接口实现，一个service接口也是一个接口实现，这种方式是不是会产生很多冗余的类接口呢？所以这种模式的是存在改进的。

说的是设计上的问题吧，如果IOC注入比如改userservice为userservice2，还是要改配置，用接口+工厂模式也是差不多吧，但是用new的话每次调用dao层，都会独立的一个userDao实例，但是用spring IOC或者工厂一般都是用单例来实现注入，这样内存开销就小了。但并发多了是不是不安全了，要是userDao层是非pojo类，比如有个属性是I，你第一次把I值改了，下一次还是同一个实例，这个I值可能就不是原来的I值，线程安全嘛？再安全和性能上怎么取舍，还有，new是不是一定开销很大内存呢？

我举个形象的例子吧，我们设想做一个电饭锅和插座，如果我们直接在Service里new一个Dao，就相关于我们在把电饭锅和插座的参数接口给固定死了，这个插座只能被这个锅使用。而且出厂时已经使用螺丝拧死了，如果插座坏了，只能换一同一型号的，而且还得拆开螺丝。

不知能说明白不？

new太多对象也许会有频繁gc可能，但是说开销大到哪里应该也不至于.ioc主要还是方便维护和方便测试,想想替换配置文件是不是比直接修改代码安全和方便的多.

接口，我们大多数项目都有一个IDAO一个DAOImpl，一个IService一个ServiceImpl。不知有几个项目，一个IDao，真有多个接口实现。

如果不是什么特别的项目，还是直接就是DaoObject和ServiceObject，不要再做接口了，不然累死你。

至于说单实例，如果你是无状态的你就放心用了。

无状态用单例实现肯定性能要好是不？大致是一个什么概念，比如有千万级的并发量，这个同时调用，用new的话，内存空间就很恐怖了，是不是可以这么理解，而单例，这个并发没问题？

我做过一个项目，每个业务层接口有几十上百个实现类，整个项目业务层接口不超过十个。