一个关于用spring注入的数据库链接引用问题
我用spring和hibernate结合，在建立Data Object和hbm.xml的同时，也对每张表建立了一个spring DAO。 

请教几个问题： 
1、这种做法（每张表建立一个DAO）合不合理？是不是一个好的使用习惯？如果不是，正规的SSH开发通常如何做？ 

2、在业务层，我一个业务逻辑类（如userBiz），需要访问很多表，也就是使用很多DAO,我必须在applicationContext.xml的相应bean里面配置很多DAO的注入？如果我有十个业务逻辑类，那么这十个业务逻辑类相应的bean都要配置那么多注入？我的action需要调用业务逻辑类来完成系统功能，那么action也需要配置相应的bean，把业务逻辑类注入action？因为我的业务逻辑类不注入DAO，只是用new的方法来调用DAO的话，数据库是没法链接的，最后提示null值。同理，action里面不注入业务逻辑类，只是new的话，最后在链接数据库时也会显示null，获取不到链接对象。 

必须从DAO开始，一层一层的注入，才能正确访问数据库？那个....好像有点傻....最后applicationContext.xml会非常庞大的，而且这么一层层的配置，注入，应该是非常消耗资源的吧？好像有些关键地方我搞错了？ 

3、如果用jsp直接调用业务逻辑类相应方法获取数据，因为jsp是无法像action那样配置applicationContext.xml来注入的，最后在连接数据库时仍然提示null.......必须注入，才有数据源....是不是我搞错了某些地方了？ 

4、发现如果在业务逻辑层注入static类型的DAO,其他地方就不需要注入业务逻辑类，只需要new一个业务逻辑类，就能正确访问数据库。如 
static UserDAO dao = null; 

public void setDao(UserDAO dao) { 
this.dao = dao; 
} 
这样的使用方法好么？声明static类型，会不会占用内存不放？数据链接会不会得不到释放？如果new很多次业务逻辑类，会不会造成很多内存和数据链接得不到释放？

------解决方案--------------------
1和2：如果采用通用的DAO组件(例如利用泛型封装)，就可以大大减少DAO层代码，和Spring容器中的bean数量。而且程序员的精力可以全部集中到逻辑层。

3：jsp是可以取得Spring容器的bean(如果这个bean是操作数据库的，则必定可以连接到数据库)，但这不适合分层分治思想，因JSP适合做数据展现。至于如果取得Spring容器，给予两种方法：
一种是在application作用域中取得：
WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(application);
另一种是(接上面的对象，也可以重新定义)：if(ctx == null) ctx = (WebApplicationContext)new ClassPathXmlApplicationContext("spring配置.xml");

ctx.getBean("xxxx")返回的DAO或Service层的bean是可以连接到数据库的。

4：在Spring框架下习惯提new、static之类的关键词，呵呵，最好请假到外面去郊游，真正体验下春天(Spring)。
------解决方案--------------------
不建议用往jsp中注入数据，因为jsp是用来显示数据的，你直接用c标签或是jsp标签调用那些dao方法就行了吗