Dao和Service设计的一点疑问.

  个人以为,在三层体系中Persistent和View之间,就应该是Business,我所提及的Service应该归到Business吧,DAO在我看来,只是Business和Persistent之间一个接口,论归属,我以为应该在Persistent.

To 梅:
    在我的一些设计中,这种把一些通用的操作抽象出来的处理,还是从appfuse借鉴过来的呢,不过appfuse具体的应用,我就不了解了,我抽象那些通用处理,只是为了减少一些DAO的代码量(DAO都是我自己手工去写的)和处理一些比较特别的通用的操作而已.
    对于appfuse的用法,我认为至少在命名上是更有意义的,其次可能也比较好定位错误吧.

我也是用的appfuse结构，我感觉都从DAO继承的话可以减少代码量，其实有关Object的方法是可以使的，Appfuse没有用可能跟版本有关，其实对于比较简单的业务数据处理，完全可以不用增加XxxDAO，只用DAO/BaseDAOHibernate/Manager/BaseManager就可以了。这样配置文件都不用修改，直接在Action中使用，只要将Object用对应的Model替换就行了

http://forum.iteye.com/viewtopic.php?t=8224

回梅的问题，可能跟你说的有点不一样，但是对于一些继承问题都作出了很好的解释。

另外我觉得appfuse的service设计得有点败笔，这里的每一个manager只考虑到使用一个DAO的情况，而且设立了一个基类来提供DAO属性，以供注入。但是实际情况中我们经常遇到一个manager需要多个DAO提供数据访问的情况。

能举个实际的例子么？ 我都是 一个manager一个DAO

这不能算是败笔吧，只能说appfuse目前提供的示例有些简单，没有用到一个service里面注入多个dao的复杂一点的逻辑而已。appfuse既然定位在展示，自然从分层扩展的角度做出了service--->dao的分层。若实际项目中真如你所说的逻辑大部分的方法都是service方法:dao方法＝1：1的话，我宁愿舍弃这层service,这样的对dao的简单代理，又有何用呢，换来的可能是永远都用不到的所谓扩展性。分出service层来，我觉得也只有在一个service注入了多个dao或者是一个service方法中揉合了多个Dao方法时才显示出其价值，这时再利用spring加在service层的声明式事务处理，才使整个结构清晰，service才能体现出做为service的价值。

能否举例说明一下一个Service注入多个DAO的情况，再数据库的操作过程中，当涉及到多个表的关联操作时，对于简单的应用基本上有Hibernate的关联就够了，因此我也很想了解多个DAO的注入问题。

这是spring's samples的一段配置

	<bean id="petStore" parent="baseTransactionProxy">
		<property name="target">
			<bean class="org.springframework.samples.jpetstore.domain.logic.PetStoreImpl">
				<property name="accountDao"><ref bean="accountDao"/></property>
				<property name="categoryDao"><ref bean="categoryDao"/></property>
				<property name="productDao"><ref bean="productDao"/></property>
				<property name="itemDao"><ref bean="itemDao"/></property>
				<property name="orderDao"><ref bean="orderDao"/></property>
			</bean>
		</property>
		<!-- Uncomment the following in order to enable mail sending aspect -->
		<!--
		<property name="postInterceptors">
			<list>
				<ref local="emailAdvisor"/>
			</list>
		</property>
 		-->
	</bean>

详细请参考，spring's jpetstore 的示例