实现机制包括动态代理和Cgilib2,其中Spring AOP默认使用的Java动态代理是必须基于接口,所以就要求基于接口了。
3.2 解决方法
那就让Spring AOP改用CGLib2
,生成目标类的子类吧,我们只要指定使用声明式事务的FactoryBean使用CGLib的方式来实现AOP,就可以不基于接口编程了。
指定的方式为设置proxyTargetClass为true。如下:
id="baseService" abstract="true">
又因为这些Service Bean都是单例,效率应该不受影响。
4.总结
对比Appfuse里面的5个类,我的Model层里只有VO作为纯数据载体,Manager类放商业方法。有人说这样太简单了,但一个应用,要划成几个JSP,一个Controller,一个Manager,一个VO,对我来说已经足够复杂,再要往上架墙叠屋,恕不奉陪,起码在我的项目范围里不需要。(但有很多项目是需要的,神佑世人)
后记:迫于世人的压力,SpringSide暂时还是把DAO和Service层分开了,但依然坚持不搞那么多接口。
另外,尽量利用IDEA的代码生成热键,为Manager类生成delegate的Dao类方法。
简化Spring(3)--Controller层 作者:江南白衣
Struts与Webwork的扇子请跳过本篇。
MVC不就是把M、V、C分开么?至唯物朴素的做法是两个
JSP一个负责View,一个负责Controller,再加一个负责Model的
Java Bean,已经可以
工作得很好,那时候一切都很简单。
而现在为了一些不是本质的功能,冒出这么多非标准的Web框架,实在让人一阵郁闷。像Ruby On Rails那样简捷开发,可用可不用,而且没有太多的限制需要学习的,比如Webwork这型还可以考虑。但像Struts那样越用框架越麻烦,或者像Tapestry那样有严重自闭倾向,额上凿着"高手专用玩具"的,用在团队里就是不负责任的行为了。
so,我的MVC方案是使用Spring MVC的Controller接口,写最普通的JavaBean作为Controller,本质就和当年拿JSP作Controller差不多,但拥有了Spring IOC的特性。
之所以用这么消极的选择标准,是因为觉得这一代MVC框架离重回RAD时代的标准还很远,注定了只是一段短暂的,过渡的技术,不值得投资太多精力和团队
学习成本。
1. 原理
Spring MVC按植物分类学属于Martin Flower〈企业应用模式〉里的静态配置型Front Controler,使用DispatchServlet截获所有*.do的请求,按照xml文件的配置,调用对应的Command对象的handleRequest(request,response)函数,同时进行依赖对象的注入。
我们的Controller层,就是实现handleRequest(request,response)函数的普通JavaBean。
2. 优势
Spring MVC与struts相比的优势:
一是它的Controller有着从松到紧的类层次结构,用户可以选择实现只有一个HandleRequest()函数的接口,也可以使用它
有很多回调函数的SimpleFormController类。
二是不需要Form Bean,也不需要T