简化Spring(2) Model层[Java编程]

因为Spring自带的sample离我们的实际项目很远,所以官方一点的model层情势展示就靠Appfuse了.

但Appfuse的model层总共有一个DAO接口、一个DAOImpl类、一个Service接口、一个ServiceImpl类、一个DataObject.....大约只有受惯了凌虐的人才会欣然承受吧.

别的,Domain-Driven逢初1、十五也会被拿出来谈论一遍.

其实无论什么情势,都不过是一种人为的划分、抽象和封装.只要在团队里理解一致,自我感受文雅就行了.

我的倡议是,一开始DO和Manager一生一旦包演全场,DO作为纯数据载体,而Manager类安排商业办法,用getHibernateTemplate()直接拜候数据库,不强迫基于接口编程.当某天系统复杂到你直觉上需求将DAO层和Service层脱离时,再脱离就行了.

1.DataObject类

好听点也可以叫Domain Object.Domain Driven　Development固然诱人,但因为Java下的ORM框架都是基于Data Mapper情势的,没有Ruby On Rails中那种Active Recorder的情势.所以,还是压下了这个希望,Data Object纯粹作一个数据载体,而把数据库拜候与商业逻辑操作统一放到Manager类中.

2.Manager类

我的Manager类是Appfuse中DAO类与Service类的结合体,因为:

2.1 不想利用纯DAO

以往的DAO是为了透明差别数据库间的差别,而目前Hibernate已经做的很好.所以目前纯DAO的更大作用是为了将来可以切换到别的ORM筹划比方iBatis,但一个Pragmaic的程序员明显不会无聊到为了这个机会不大的来由,目前就去做一个纯DAO层,项目又不是Appfuse那样为了demo各种ORM筹划而存在.

2.2 也不想利用Service层来为Dao解耦

在JPetStore里有一个很薄的Service层,Fascade了一堆DAO类,把这些DAO类的全部办法都僵硬的反复了一遍.理论上一个Manager类可以管理数个Dao类,可以避免Dao之间直接耦合.但既然有Manager的情形下,商业逻辑都是写在Manager类的,那模样Manager仿佛还是调用另一个Manager对比妥当,调用裸Dao大概存在忽视了某些逻辑.所以,耦合又从Dao层升到Service层了.

所以,除非你做的是超薄的不带逻辑的Service层,不然没有解耦的意义.

何况,对一个不是死搬书的Designer来说,组件边界之内的类之间的耦归并非耦合.

3.去除不必要的基于接口编程

众所周知,Spring是倡导基于接口编程的.

但有些Manager类,比方SaleOrderManager ,只有5%的机会再有另一个Impl实现.95%时间里这两兄弟站一同,就像C++里的.h和.cpp,徒增保护的烦琐(常常要同步两个文件的函数声明),和代码浏览跳转时的不便(比方从Controler类跟踪到Service类时,只能跳转到接口类的呼应函数,还要再按一次复杂的热键才跳转到实现类)

连Martin Flower都说,强迫每个类都别离接口和实现是过犹不及.只在有多个独立实现,大概需求消除对实现类的依靠时,才需求别离接口.

3.1 DAO被强迫用接口的缘由

Spring IOC本身是不会强迫基于接口的,但DAO类普通要利用Spring的声明式事件机制,而声明式的事件机制是利用Spring AOP来实现的.Spring AOP的实现机制包含动态代理和Cgilib2,此中Spring AOP默许利用的Java动态代理是必须基于接口,所以就要求基于接口了.

3.2 办理办法

那就让Spring AOP改用CGLib2,生成目标类的子类吧,我们只要指定利用声明式事件的FactoryBean利用CGLib的方法来实现AOP,便可以不基于接口编程了.

指定的方法为设置proxyTargetClass为true.以下:

<bean class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
id="baseService"　 abstract="true">
　 <property name="transactionManager" ref="transactionManager"/>
　 <property name="proxyTargetClass" value="true"/>

</bean>

又因为这些Service Bean都是单例,效率应当不受影响.

4.总结

比较Appfuse里面的5个类,我的Model层里只有VO作为纯数据载体,Manager类放商业办法.有人说这样太简单了,但一个利用,要划成几个JSP,一个Controller,一个Manager,一个VO,对我来说已经充足复杂,再要往上架墙叠屋,恕不奉陪,最少在我的项目范围里不需求.(但有很多项目是需求的,神佑众人）

后记:迫于众人的压力,SpringSide暂时还是把DAO和Service层脱离了,但仍然保持不搞那么多接口.

别的,尽大概操纵IDEA的代码生成热键,为Manager类生成delegate的Dao类办法.