1. 采用到的开源项目漫谈
Spring 迷人的依赖注入特性， 使其已经稳稳的占据在 JavaEE 项目引用开源项目列表中的上层位置。
秉承低耦合高内聚的遵旨， Spring 提倡的对象工厂解耦类关系的思想已深入到每个攻城狮的心中。
SpringMVC 做为 Spring 的干儿子，最让我沉醉的是她强大的扩展能力，深邃的像大海一样。
前端无论是 freemarker/velocity/jsp...，后端 DAO 层无论是传统的 ORM 还是新近上位的领域模型。
她的态度始终如一，给你360度最贴心的呵护，有一人对你如此，此生足矣。
官网地址：http://projects.spring.io/spring-framework/
项目中关于 SpringMVC + Spring 的依赖：
<!--spring mvc-->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.3.3.RELEASE</version>
</dependency>
<!-- Spring-orm -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>4.3.3.RELEASE</version>
</dependency>
<!-- Spring AOP 动态代理 -->
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>1.8.9</version>
</dependency>
这上面我想说的是 AspectJ 这个东东， AspectJ 是最早、功能比较强大的 AOP 实现之一。
在 Java 领域，AspectJ 中的很多语法结构基本上已成为 AOP 领域的标准。
Spring 也有自己的 Spring-AOP，Spring-AOP 采用运行时生成代理类，底层可以选用 JDK 或者 CGLIB 动态代理。
通俗点，AspectJ 在编译时增强要切入的类，而 Spring-AOP 是在运行时通过代理类增强切入的类，效率和性能可想而知。
所以 Spring 在 2.0 的时候就已经开始支持 AspectJ ，现在到 4.X 的时代已经很完美的和 AspectJ 结合到一起。
有兴趣的可以在接着读读：https://www.oschina.net/translate/comparative_analysis_between_spring_aop_and_aspectj?cmp
Druid 出自阿里巴巴技术团队之手，个人认为是比较好的数据库连接池之一，尤其是监控部分是我的最爱。
官方 github 地址：https://github.com/alibaba/druid/wiki/常见问题
项目中的 web.xml 配置监控配置和监控界面：
<!--Druid 数据库连接池监控-->
<servlet>
<servlet-name>DruidStatView</servlet-name>
<servlet-class>com.alibaba.druid.support.http.StatViewServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>DruidStatView</servlet-name>
<url-pattern>/druid/*</url-pattern>
</servlet-mapping>
JPA 作为 Sun 公司引入的 ORM 规范，就像是 JDBC 之于各种数据库驱动 Jar，
不要去在意使用了什么样的数据库，用 JDBC 提供的规范方法去撸代码即可。
JPA 制定持久层规范，相同与抽象接口，有 ORM 框架撸具体的实现层。
Sun 想实现 ORM 技术统一，可能不远的将来，你不用在纠结选择什么样子的 ORM 框架。
而现有热门的 ORM 框架会渐渐失去光泽，这毕竟是个漫长的过程，让我们拭目以待。
2. 方案整体一览
方案中所有的类都位于 SpringContext 中，由 Spring 统一进行管理。
让 Spring 统一管理的前提是你要告诉有这样一个类需要它管理，目前我接触到的告诉途径有两种。
传统的 xml 配置和注解方式，xml 配置和注解方式各有优劣，比如 xml 配置的优点：
a. 如果你公司项目在引用另外一个公司的 jar，这时候，唯一可行方式为 xml 配置。
b. 如果类之间的依赖关系变动频繁，xml 配置是比较优秀的，改动代码和改动配置文件，无论是技术上还是风险上，xml 都稳赢注解。
注解声明的方式优点：代码和声明在一起，开发的时候不用切来切去，比 xml 配置声明要简单明了的多。
现在很多主流的框架都引入了注解，但也无法摈弃 xml 配置声明的方式。
在这个方案中我使用干净简单注解的方式，controller 包下使用注解@controller,dao-impl 包下使用@Repository,service 包下使用@service。
控制层注入服务实例，服务层注入数据访问层对象，持久层对象由 JAP 进行注解，页面通过控制层来传输和获取数据。
web.xml:
View Code
maven pom.xml:
View Code
3. DAO 层的种种设计思路
Controller 和 Service 层非常容易理解，这里不赘述了。
DAO 层 中 BasePo 希望将一些共有的属性抽象在父类当中(属性由具体项目需求决定)。
BasePO
BaseDaoImpl 希望将一些公共的数据访问方法实现在父类当中（我这里的方法可能有点少，可以由具体项目增加）。
BaseDaoImpl
使用 JAP 注解编写业务使用到的持久层对象（主流的开发工具都支持由数据库反向生成持久层对象）。
@Entity
@Table(name = "t_user")
public class User extends BasePO {
@Column(nullable = false)
String name;
@Column(nullable = false)
String pwd;
....getter/setter
}
配置启动时扫描 POJO 的动作，至于是新建还是更新都有配置选项，可以自己查阅相关文档。
<!-- 配置hibernate session工厂,需添加 spring-orm -->
<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="hibernateProperties">
<props>
<prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">${hibernate.show_sql}</prop>
<prop key="hibernate.format_sql">${hibernate.format_sql}</prop>
</props>
</property>
<!-- 自动扫描注解方式配置的hibernate类文件 -->
<property name="packagesToScan">
<list>
<value>com.rambo.sdh.pojo</value>
</list>
</property>
</bean>
操纵数据库最主要的事务管理，采用 AOP 声明方式，在执行含有数据变动的方法前后进行拦截。
采用 AOP 声明方式进行拦截的好处，不用去关注数据库事务的开启和关闭，将重心放到业务逻辑上面。
<!-- 配置事务管理器 -->
<bean name="transactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<!-- 1)基于 <tx> 和 <aop> 命名空间的声明式事务管理：transaction-manager指定事务管理器为transactionManager- -->
<tx:advice id="transactionAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="add*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="save*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="update*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="edit*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="modify*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="delete*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="remove*" propagation="REQUIRED" rollback-for="Exception"/>
<tx:method name="get*" propagation="NOT_SUPPORTED" read-only="true"/>
<tx:method name="find*" propagation="NOT_SUPPORTED" read-only="true"/>
<tx:method name="list*" propagation="NOT_SUPPORTED" read-only="true"/>
</tx:attributes>
</tx:advice>
<aop:config>
<aop:pointcut id="transactionPointcut" expression="execution(* com.rambo.sdh.*.dao.impl.*.*(..))"/>
<aop:advisor pointcut-ref="transactionPointcut" advice-ref="transactionAdvice"/>
</aop:config>
<!--2)基于 @Transactional 的方式将声明式事务管理：激活启用事务相关处理 Bean 配置-->
<tx:annotation-driven transaction-manager="transactionManager"/>
方式一在包 com.rambo.sdh.*.dao.*Impl.* 下所执行的已 add/save/update.....开头的方法。
方法在执行前后都会被 HibernateTransactionManager 拦截，进行事务的开启和关闭。
方式二在你想进行事务管理的接口、接口方法、类以及类方法上添加 @Transactional 注解。
当然还有一些其他的事情，有兴趣可以 debug 源码去一探究竟。
貌似说的也差不多了，该方案为 JavaEE 后端解决方案，前端用你想用的渲染技术即可。
项目开源 GIT 地址已在最上面给出，如果有兴趣的可以检出到本地跑一跑，该方案中小公司其实都挺适合，上手和开发速度快。
本文转自Orson博客园博客，原文链接：http://www.cnblogs.com/java-class/p/5951738.html，如需转载请自行联系原作者
