BlogJava-花钱的年华-随笔分类-Spring

ActiveMQ4.1+Spring2.0的POJO JMS方案（上）

江南白衣 — Fri, 01 Dec 2006 04:28:00 GMT

[摘要]SpringSide 2.0采用了ActiveMQ 4.1-incubator-SNAPSHOT 与Spring 2.0 集成，比SS1.0M3版本有三个值得留意的特点，使得代码中几乎不见一丝JMS的侵入代码。

全文地址：http://blog.csdn.net/calvinxiu/archive/2006/12/01/1423943.aspx

江南白衣 2006-12-01 12:28 发表评论

XFire 最新生火指南（上）

江南白衣 — Fri, 24 Nov 2006 05:23:00 GMT

[摘要] XFire 是全球众多牛人在与axis系列对比后一致投票的选择。，但网上的文档与例子总是不新，大家抛开所有的文档，所有的Axis习惯，单看这份代表XFire1.2.2最简约做法的文档。

全文地址：http://blog.csdn.net/calvinxiu/archive/2006/11/24/1411678.aspx

江南白衣 2006-11-24 13:23 发表评论

幼学琼林--Spring下的单元测试要点

江南白衣 — Mon, 23 Oct 2006 01:23:00 GMT

今天复习了一下造福无数人Spring2.0 参考手册翻译--第8章测试，浓缩即精华的更新了SpringSide wiki中的--Spring下的单元测试要点。

全文地址：http://blog.csdn.net/calvinxiu/archive/2006/10/23/1346178.aspx

江南白衣 2006-10-23 09:23 发表评论

当Spring遇到Ruby

江南白衣 — Sat, 08 Apr 2006 09:17:00 GMT

摘要: 当王家卫遇到杜可风，Spring遇到Ruby。想出这个题目的Crraig Walls 绝对也是个八卦种子，宣传的是Spring 2.0m2集成动态语言的feature。阅读全文

江南白衣 2006-04-08 17:17 发表评论

Message Driven POJO

江南白衣 — Sat, 25 Mar 2006 09:04:00 GMT

摘要: 《Effecitve Enterprise Java》的一个实践。阅读全文

江南白衣 2006-03-25 17:04 发表评论

启动SpringSide--Promatic Enterprise Application KickStart项目

江南白衣 — Mon, 02 Jan 2006 09:47:00 GMT

作者：江南白衣

 SpringSide--Pragmatic Enterprise Application KickStart and Common Library Stack，这么长的一个名字下来，不用解释大家都知道是做什么的了----以Spring Framework为core，提供一个Pragmatic的企业应用开发基础和最佳实践展示。

定位：为使用Spring框架的开发者提供一个非Demo版的复杂、正式而体现最佳使用实践的参照系统。

   目标：囊括JavaEE必须面对的所有问题的合理的、合乎实践标准的解决方案，采用Plugins形式组织，使开发者可快速定位所需的参考方案并做加法到自己的系统。

    项目网站：http://www.springside.org.cn
    or http://springside.sourceforge.net

    1. Featrue List

Spring 2 - J2EE Framework.
Hibernate 3 - ORM, support EJB3/JPA1.0 in future.
Spring MVC /WebWork - Multi-Action Web framework.
JSP2.0 - View Template.
XFire - Web Service.
Acegi - Security, RBAC ana ACL.(doing)
Eclipse BIRT 2 - Report Engine.(doing)
Drools 3 - Business Rule engine.(doing)
ActiveMQ ,Jencks - JMS Message Driven POJO.
Quartz - Enterprise job scheduler.
DWR 2 , Prototype.js , TrimPath JSTemplate - Ajax
Compass - Search engine use Luecene .(doing)
Groovy - Dynamic script language.(doing)
Openi - BI web application for OLAP Report.(doing)
ServiceMix - ESB(Enterprise Service Bus) and JBI.(doing)
Commons Validator - client and server side validation.
SiteMesh web-page layout and decoration framework.
OSCache - Web cache solution.
ExtremeTable - JSP Tag Libraries.
Log4j - Logging tool.
Ant , Maven2 , JUnit, EasyMock - Build and Test tools.
UTF-8 and I18N.
Intergrate with Weblogic , Tomcat , JBoss , Geronimo.
And we are choising the Workflow solution.

    2. SpringSide与Appfuse有什么不同？
    1.SpringSide较完整的演示了企业应用的各个主题，而Appfuse只有简单的登陆界面和用户管理。

    2.SpringSide是深受Ruby on Rails影响的Pragmatic型的方案。

    3.Appfuse主要目的是展示各式mvc、orm方案与Spring的结合，有些技术属于高手玩具，而SpringSide展示的是一个国内项目的实际形态，并带中文手册与大量中文代码注释

    4. 脚本细节
  SpringSide的基本结构是JDK1.4 + Spring 2.0 + hibernate3 + Spring MVC multi-action + JSP2.0。

    使用 XFire提供WebService订书的服务端接口和 Java版/.Net版的客户端示范代码。

    店员是个兼职的学生，所以系统会为每张订单发一封通知邮件给店员。为了不影响顾客下单的速度，发信的动作由jms异步进行。

    系统还会用 Quartz定时扫描缺货的图书，用邮件通知店员。

    老板只负责看一些色彩丰富，带图的报表。Eclipse Birt2.0提供日常报表， Openi提供BI OLAP的。

    基于Lucene的 Compass做的图书全文搜索。

    基于 Drools规则引擎的订单满100元免运费，会员积分制等。

店面演示Ajax效果与 OSCache的Web Cache，SiteMesh的渲染效果使用。

    一些非关键业务，用 Groovy动态语言来快速开发。

    log4j系统将重要操作员日志异步写入数据库，使它们可管理。

    综合的Acegi i安全权限管理。

    utf-8, i18n的国际化项目。

   ServiceMix ，WorkFlow的故事设计中。

    5. RoadMap
    Road Map in JIRA Issue Checker ,欢迎大家提出更多Topic
    .
    6. 团队成员列表 (排名按加入顺序)

     欢迎朋友们加入。人多速度快是很重要的事情。

   参加方式有3种
   1.帮忙codereview提意见
   2.到JIRA里面领任务
   3.到JIRA 提出新任务

  真正贡献了力量的同志自然会成为开发人员.


    Team Worker：
     江南白衣，cac，@_@，wuyu，charlse, efa，yimlin
     Contributor：
     water ye ，totodo，david.turing，pesome，oofrank

     长老供奉：
      庄表伟，Robbin

     (排名按加入时间）

7. 交流区

演示站点

开发RoadMap

Spring中文论坛专区

团队开发日志

开发者QQ群：15690287 (only for Springside developer)
用户QQ群: 21601442

江南白衣 2006-01-02 17:47 发表评论

在厨房，车顶，草地上使用Spring

江南白衣 — Fri, 30 Dec 2005 02:40:00 GMT

   作者：江南白衣

    Spring再强大，也要面对降临的问题--因为Spring不是Weblogic、Tomcat般的顶层容器，Servlet和EJB对象不由它创建，所以它必须要降临到Weblogic、Tomcat所在的位面。
     初学者一般不用管那么多，照着Spring+hibernate+Struts之类的Sample就做了，但慢慢的，也许就要开始在jsp+javabean体系，土制框架，singleton类等环境下使用Spring了。
     《Professional Java Development with the Spring Framework》第3章有"Managing the Containe"一节讲这个问题。一般可以分为直接召唤系与IoC fashion两类。

     1.直接召唤系--Singleton的Application Context
      最简单的，就像在UnitTest里那样，直接构造Application Context：

ApplicationContext ctx = new ClasspathXmlApplicationContext("ApplicationContext.xml");

      在Web环境里，会使用ContextLoader构造ApplicationContext后，压进Servlet Context。
      由ContextLoaderListener或ContextLoaderServlet，在Web应用启动时完成。
      然后在Jsp/Servelet中，可以通过Servlet Context取得ApplicationContext：

ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(application);

     但像singleton类或者EJB中，就没有Servlet Context可用了。
      如果全部像UnitTest那样直接构造，速度就会很不堪。自然的，就想到把ApplicationContext做成单例。
      Spring提供了ContextSingletonBeanFactoryLocator这样的物体。
      先搞一个beanRefFactory.xml，里面写上所有的applcationContext-*.xml文件名，并把Context命名为"default-context"：

<beans>
  <bean id="default-context"  class="org.springframework.context.support.ClassPathXmlApplicationContext">
    <constructor-arg>
      <list> <value>applicationContext.xmlvalue>list>
    constructor-arg>
  bean>
beans>

然后让loactor去找它，但代码有点长：

BeanFactoryReference bfr = DefaultLocatorFactory.getInstance().useBeanFactory("default-context");
BeanFactory factory = bfr.getFactory();
MyService myService = factory.getBean("myService");
bfr.release();
// now use myService

    上面的代码实在是太灵活，太麻烦了。
    还不如自己实现一个简单的Singleton，扩展ContextLoaderListener类，在Web系统启动时压入Singleton。

    新的ContextLoaderListener类重载如下，ContextUtil中包含一个静态的ApplicationContext变量：

    public void contextInitialized(ServletContextEvent event)
    {
        super.contextInitialized(event);

        ServletContext context = event.getServletContext();
        ApplicationContext ctx = WebApplicationContextUtils.getRequiredWebApplicationContext(context);
        ContextUtil.setContext(ctx);
    }

用家可直接取用：

ApplicationContext context = ContextUtil.getContext();

2.IoC fashion
    如果所有地方都使用直接召唤系，那就反而是在打Rod的耳光了。因为他一直都反对代码与框架深耦合的。
    所以，更好的方法是写一些glue code、base class来完成Spring的降临，而不让应用代码察觉Spring Application Context的存在。
    不过，因为各个框架的结构不同，Rod也没办法讲出一个通用的整合方法，所以建议大家尽量学习已整合的各种框架，如Spring MVC、Struts的种种方式，写出自己的简单整合代码来。

    只有不确定的调用某些Singleton类，不适合过早ioc的情况，可以使用直接召唤系。

江南白衣 2005-12-30 10:40 发表评论

Spring下的Unit Test笔记

江南白衣 — Wed, 21 Sep 2005 04:09:00 GMT

   作者：江南白衣

     注重实效的TDD的确能加快，而不是拖慢开发的进度（片面的追求覆盖率的全面UnitTest不在此列）
      一，可以实现真正分层开发。
      二，不需要依赖和频繁重启Web Container。
      三，手工测试总不免改动数据库，如何把数据库恢复到测试前的状态是件伤脑筋的事情。而Unit Test可以使用自动Rollback机制，巧妙的解决了这件事情。

      Spring 下的Unit Test主要关注三个方面：
      1. bean的依赖注入
       2. 事务控制，Open Session in Test 及默认回滚
       3. 脱离WebContainer对控制层的测试

1.bean的依赖注入
能不依靠WebContainer来完成ApplicationContext的建立与POJO的依赖注入一向是Spring的得意之处。

String[] paths = { "classpath:applicationContext*.xml" };
ApplicationContext ctx =new ClassPathXmlApplicationContext(paths);
UserDAO dao = (UserDAO) ctx.getBean("userDAO");

如果你连这也觉得麻烦，那么只要你的testCase继承于Spring-mock.jar里的AbstractDependencyInjectionSpringContextTests，实现public String[] getConfigLocations()函数，并显式写一些需要注入的变量的setter函数。
注：因为是AutoWire的，变量名必须等于Spring context文件里bean的id。

2.Open Session in Test 及自动Rollback
    又是来自Spring这个神奇国度的东西，加入下面几句，就可以做到Open Session in Test ，解决Hibernate的lazy-load问题；而且接管原来的DAO里的事务控制定义，随意定义测试结束时是提交还是回滚，如果默认为回滚，则测试产生数据变动不会影响数据库内数据。
     你可以让testCase继承于AbstractTransactionalDataSourceSpringContextTests，通过setDefaultRollback(boolean)方法控制最后回滚还是提交。

    如果自己编写，代码是这样的：

   protected PlatformTransactionManager transactionManager;
   protected TransactionStatus transactionStatus;
   protected boolean defaultRollback = true;
   public void setUp()
   {
        transactionManager = (PlatformTransactionManager) ctx.getBean("transactionManager");
        transactionStatus = transactionManager.getTransaction(new DefaultTransactionDefinition());
   }
   public void tearDown()
   {
        if (defaultRollback)
            transactionManager.rollback(this.transactionStatus);
        else
           transactionManager.commit(this.transactionStatus);
    }

(注，hibernate太奸诈了，如果全部默认回滚，只会在session里干活，一点不写数据库，达不到完全的测试效果。)

3.Controller层的Unit Test

controller层靠Spring提供的MockHttpServletRequest和Response来模拟真实的servlet环境，并且spring 2.0了加了一个AbstractModelAndViewTests，提供一些检测返回值的utils函数。

    protected XmlWebApplicationContext ctx;
    protected MockHttpServletRequest request = new MockHttpServletRequest("GET", "");
    protected MockHttpServletResponse response = new MockHttpServletResponse();
    protected Controller controller = null;
    protected ModelAndView mv = null;
   public void setUp()
   {
        String[] paths = {"applicationContext*.xml","myappfuse-servlet.xml"};
        ctx = new XmlWebApplicationContext();
        ctx.setConfigLocations(paths);
        ctx.setServletContext(new MockServletContext(""));        ctx.refresh();
        controller = (CustomerController) ctx.getBean("customerController");
        //再加上前文的事务控制的代码
   }
    public void testCustomerList() throws Exception
    {
        request.setRequestURI("/customer.do");
        request.addParameter("action", "listView");
        mv = controller.handleRequest(request, response);
        assertModelAttributeAvailable(mv, "customers");
    }

4.进一步简化
一来这两个基类的名字都太长了。
二来有一些公共的context文件的定义。

所以可以再抽象了几个基类，分别是DAOTestCase，ControllerTestCase。

5. EasyMock
   MockObject是一样彻底分层开发的好东西，而且使用上没什么难度。而且已不再存在只支持接口不支持Class的限制。

//设定BookManager MockObject
        bookManagerMockControl = MockClassControl.createControl(BookManager.class);
        bookManagerMock = (BookManager) bookManagerMockControl.getMock();
        controller.setBookManager(bookManagerMock);

//录制getAllBook()和getCategorys方法的期望值
        bookManagerMock.getAllBook();
        bookManagerMockControl.setReturnValue(new ArrayList());
        bookManagerMockControl.replay();

//执行操作
        mv = controller.handleRequest(request, response);
//验证结果
        assertModelAttributeAvailable(mv, "books");

Easy Mock VS JMock:

JMock 要求TestCase继承于MockObjectTestCase太霸道了。妨碍了我继承于Spring2.0的ModelAndViewTestCase和使用MockDao,RealDao并行的继承体系。因此采用没那么霸道的easyMock。

另外，easyMock的脚本录制虽不如jmock那么优美，但胜在简短易读。jmock那句太长了。

6. 显示层测试
还有，显示层至今没有什么好的UnitTest方法，无论是不成才的httpUnit们还是笨重的GUI test工具。Appfuse一直用的那个ThoughtWork那个Selenium和J3Unit的效果不知如何，其中J3Unit号称支持prototype。

江南白衣 2005-09-21 12:09 发表评论

Spring 的微内核与FactoryBean扩展机制

江南白衣 — Tue, 30 Aug 2005 14:12:00 GMT

作者：江南白衣

              扩展Spring系列(1)--Spring 的微内核与FactoryBean扩展机制

DreamHead在《思考微内核》十分激赏 Spring的微内核与扩展机制：
“Spring的微内核在哪里呢？便是DI容器。而通过FactoryBean，我们可以定制自己的组件组装过程，对一个普通的JavaBean做手脚，像Spring AOP中常用的ProxyFactoryBean做的那样。如此，我们就不必把所有功能都做到Spring的DI容器中去，而是以一个FactoryBean来对DI容器的功能进行扩展。除了Spring自身之外，现在已经有一些项目开始利用这个特性扩展Spring，比如，Acegi Security和Spring Modules。”

这确是框架容器界应该贯彻的范式，微内核提供最少的功能，而由扩展接口去增强框架的能力。下面看看Spring怎么设计，明白之后就可以开始为Spring捐献精力了:)

1、微内核的功能
1.1 DI(依赖注入)与Singleton管理
      利用POJO setter的DI机制，估计每位同学随手都能写一个简单版本，不多说了。
      Singleton管理说白了就是先到一个map中按id找找看有没有已存在的实例。

1.2 BeanName与BeanFactory注入
      除了DI注入的属性，微内核还有什么能卖给POJO呢？就是Bean在xml 定义里的id和BeanFactory自己了。
      卖的机制是让POJO 实现 BeanNameAware和BeanFactoryAware接口。BeanFactory用 if(pojo instance of BeanFactoryAware)判断到POJO需要注入BeanFactory,就调用setBeanFactory(this)将自己注入。

      这种框架中基于接口的注入和调用机制在Java下挺标准的，Spring的功能多是基于这种模式提供。遗憾就是Java不支持多重继承，作为替代的接口里不能提供默认的实现，导致每一个Pojo都要很无聊的实现一遍setBeanFactory()。

1.3 DI后的初始化函数调用
      比如属性A,B注入之后，需要同时根据A和B来对A,B进行加工或者装配一个内部属性C，这样就需要在所有属性注入后再跑一个init()函数。
      Spring提供两种方式，一种是和上面的原理一样，实现InitializingBean接口的afterPropertiesSet()函数供Spring调用。
      一种是在xml定义文件里面自行定义init函数名。
      懒得每次在xml文件里定义的就采用第1种方式，不想与spring耦合的pojo就采用第2种方式。本来就是为了扩展Spring而存在的FactoryBean多采用第一种。

   所谓微内核，就是仅提供以上三种功能的DI容器。
   但作为轻量级容器，还需要以下两种方式，向容器内的POJO 附加各种服务。

2.FactoryBean扩展机制
Spring的AOP、ORM、事务管理、JMX、Quartz、Remoting、Freemarker、Velocity，都靠FacotryBean的扩展，FacotryBean几乎遍布地上：

只不过当年对这类factoryBean比较麻木不仁，不问原理的照搬照用了。

不过这原理说出来也好简单，所有FactoryBean 实现FactoryBean接口的getObject()函数。Spring容器getBean(id)时见到bean的定义是普通class时，就会构造该class的实例来获得bean，而如果发现是FacotryBean接口的实例时，就通过调用它的getObject()函数来获得bean，仅此而以.......可见，很重要的思想，可以用很简单的设计来实现。

考察一个典型的FactoryBean：
    一般会有两个变量，三个接口：
    一个setter函数注入需要改装的pojo，一个内部变量保持装配后的对象returnOjbect。
    implements三个接口：FactoryBean,InitializingBean和BeanFactoryAware 。
    各接口的意义之前都讲过了。factoryBean会在afterPropertiesSet()里把pojo改装成returnObject，需要用到beanfactory进行天马行空的动作时就靠BeanFactoryAware注入。最后在getObject()里把returnObject返回。

Rod说：IoC principles, combined with the factory bean, afford a powerful means to abstract the act of obtaining or accessing services and resources

3. Bean Post-Processor扩展机制
     如果说FactoryBean 是一种Factory、Wrapper式的扩展，Bean Post-Processor就是另一种AOP、visitor式的机制，所以也多用于spring的AOP架构。
      Post-Processor的原理就是BeanFactory在前文里的调用afterPropertiesSet()/init-method前后，调用在工厂里注册了的post-processor的postProcessBeforeInitialization()和postProcessAfterInitialization()。
      那怎么注册登记呢？又分请不请礼仪公司两类。如果是ApplicationContext，你把继承BeanPostProcessor 的bean往xml里一搁就行了,application context自会打理。如果是BeanFacotry，就要显式的注册，代码大概像：

XmlBeanFactory factory = new XmlBeanFactory("C:/beans.xml");
BeanPostLogger logger = new BeanPostLogger();
factory.addBeanPostProcessor(logger);

Rod说："Post-processors add the ability to customize bean and container behavior in a flexible, externalized fashion. "
对比Factory Bean那段，可见两种机制在他心目中的不同作用。

系列文章:
Spring 的微内核与FactoryBean扩展机制
扩展Spring(2)--Spring对各种数据访问框架的集成机制

江南白衣 2005-08-30 22:12 发表评论

扩展Spring(2)--Spring对各种数据访问框架的集成机制

江南白衣 — Fri, 26 Aug 2005 10:24:00 GMT

           扩展Spring(2) ---Spring对各种数据访问框架的集成机制

     何为数据框架集成。
   数据访问框架原本好好的，Spring都干了什么呢？
   一是用template类封装了数据框架那些资源获取和异常事务处理的废话代码，而且按照自己的意见给出一些增强函数。
   二是将其纳入了Spring的声明式事务管理中。

    对比Spring对Hibernate、JDBC的集成，还有Spring Modules对O/R Broker的集成，发现Spring的DAO框架主要有六个类：
    1.Template
      著名的Template类，用callback机制封装了除业务代码外的所有必要但废话的代码，重新封装了数据框架的API，并再附送一些增强版。

    2.TransactionManager
      实现PlatformTransactionManager接口，数据访问框架就能与Spring的事务机制(TransactionTemplate或AOP声明式事务)结合。

    重要的类仅以上两个，以下的类都只有少量标准代码，完全可以忽略。
    3.DAOSupport
       实际DAO类的基类，负责保持template变量。如果你觉得它破坏了你的类层次结构，完全可以不用。
    4.Accessor
     template类的基类，defining common properties like DataSource and exception translator，也没大用。
    5.Operations
     template所实现的接口，定义template支持的数据访问函数和增强函数，template有多个实现时才有用。
    6.Exception Translate的相关类和函数
     异常翻译，Spring DAO很重视的一个功能。

Template类的代码
   因为Hibernate本身很复杂，所以HibernateTemplate也不适合畏高晕车的人士如我观看。JDBC简单很多，但JDBCTemplate又忙着增强JDBC的功能，多出好多代码。所以我选O/R broker的集成代码来看，代码一共才280行。
注：如果不熟O/R broker，可以简单的认为broker=connection, executable = statement ，其余一切同Jdbc。

1.1主干函数 Execute(BrokerCallback action)
      step1. 获得Connection-- connecton = datasource.getConn();
      step2. 准备Statement -- statement = new Statement(connection);
      step3. 执行Action的回调函数doInBroker(Statement)。这个doInBroker()方法由客户定义，会拿着传入的statement，执行种种操作。

try
{
action.doInBroker(statement );
}
catch()
{
//翻译异常
}

   1.2 template的API函数
         虽然理论上大家可以直接使用execute()，在匿名内部类里调用数据访问框架的任何API。但java的匿名内部类不比闭包，代码难看无比，所以除了Robbin还没见到其他兄弟提倡直接用execute方法的。
        因此，template也对数据框架的API进行了wrap，封装了用execute(StatementCallback action)来执行这些API的函数，如下段就是wrap 了O/R Broker的execute(String statementID.....)方法：

public int execute(final String statementID, final String[] paramNames, final Object[] values) throws DataAccessException {
    return executeWithIntResult(new BrokerCallback() {
      public Object doInBroker(Executable executable) throws BrokerException {
        applyNamedParamsToExecutable(executable, paramNames, values);
        return new Integer(executable.execute(statementID));
      }
    });
  }

    另外还提供一些增强型、便利型的API(如selectOne() ,selectMany())，在参数、返回值上极尽变化。

TransactionManager的代码
   比较复杂，一下说不清。但JDBC的DatasourceTransactionManager和Hibernate的HibernateTransactionManager的代码都很相近，说明这个TransactionManager其实也比较固定埋头狂抄就是了。

    有兴趣的同学，可以响应某大老号召，实现ofbiz与spring的集成:)

系列文章:
Spring 的微内核与FactoryBean扩展机制
扩展Spring(2)--Spring对各种数据访问框架的集成机制

江南白衣 2005-08-26 18:24 发表评论

简化Spring(4)--View层

江南白衣 — Wed, 24 Aug 2005 06:22:00 GMT

    作者：江南白衣

    人生像个舞台，请良家少女离开。
    同样的，Freemarker和Velocity爱好者请跳过本篇。与弃用webwork而单用Spring MVC Controller接口的理由一样，Freemarker本来是一样好东西，还跨界支持jsp 的taglib，而且得到了WebWork的全力支持，但为了它的非标准化，用户数量与IDE的缺乏，在View层我们还是使用了保守但人人会用，IDE友好的JSP2.0 配合JSTL。

    对于B/S结构的企业应用软件来说，基本的页面不外两种，一种是填Form的，一种是DataGrid 数据列表管理的，再配合一些css, js, ajax的效果，就是View层要关注的东西了。

1. JSP 2.0的EL代替
JSP2.0可以直接把EL写在html部分，而不必动用节点后，老实说，JSP2.0+JSTL达到的页面效果，已不比Velocity相差多少了。

<p>{goods.name}p>
代替
<p><c:out value="{goods.name}"/>p>

(除了EL里面不能调用goods的函数，sun那帮老顽固始终坚持JSTL只能用于数据显示，不能进行数据操作，所以不能调用bean的get/set外的方法)

2. 最懒的form 数据绑定

Spring少得可怜的几个tag基本上是鸡肋，完全可以不要。而Spring开发中的那些Simple Form tag又还没有发布。Spring的Tag主要用来把VO的值绑到input框上。但是，和Struts一样，需要逐个Input框绑定，而且语法极度冗长，遇到select框还要自己进行处理.....典型的Spring Sample页面让人一阵头晕.

而jodd的form tag给了我们懒人一个懒得多的方法，只要在

两头用包住，里面的所有input框，select框，checkBox...统统自动被绑定了，这么简单的事情，真不明白struts,spring为什么不用，为了不必要的灵活性么?

<form>
<jodd:form bean="human">
<input type="text" name="name">
<input type="radiobox" name="sex" value="man">
<select name="age">
<option value="20">20option>
<option value="30">30option>
select>
jodd:form>
form>

不过，jodd有个致命弱点是不能绑定内嵌对象的值。比如Order(订单)对象里有个Customer(顾客)对象，jodd就不能像 struts,spring一样用如下语法绑定:

这是因为它的beanUtils比Jakata Common弱，用了一个错误的思路的缘故。动用beanUtils修改一下就可以了，修改后的源码可以在这里下载。

3. DataGrid数据列表

DisplayTag和ValueList都属于这种形式的Tag Library。但最近出现的Extreme Table是真正的killer，他本身功能强大不说，而且从一开始就想着如何让别人进行扩展重载，比如Extend Attributes机制就是DisplayTag这样的让千人一面者不会预留。

4.css, javascript, ajax
天下纷扰，没有什么特别想讲想推荐的，爱谁谁吧。Buffalo, DWR, Scriptaculous, Prototype, AjaxTags, AjaxAnywhere, Rico, Dojo, JSON-RPC，看着名字就头痛。

相关文章
简化Spring(1)--配置文件
 简化Spring(2)--Model层
 简化Spring(3)--Controller层
 简化Spring(4)--View层

江南白衣 2005-08-24 14:22 发表评论

简化Spring(3)--Controller层

江南白衣 — Tue, 23 Aug 2005 06:53:00 GMT

    作者：江南白衣

    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，也不需要Tapestry那所谓面向对象的页面对象，对于深怕类膨胀，改一个东西要动N个地方的人最适合不过。

三是不需要强XML配置文件，宣告式编程是好的，但如果强制成框架，什么都要在xml里面宣告，写的时候繁琐，看的时候也要代码配置两边看才能明白就比较麻烦了。

那Webwork呢?没有实战过，不过因为对MVC框架所求就不多，单用Spring MVC的Controller已经可以满足需求，就不多搞一套Webwork来给团队设坎，还有给日后维护，spring,ww2之间的版本升级添麻烦了。真有什么需要添加的，Spring MVC源代码量很少，很容易掌控和扩展。

3.化简

3.1. 直接implement Controller，实现handleRequest()函数

首先，simple form controller非我所好，一点都不simple。所以有时我会直接implement Controller接口。这个接口的唯一函数是供Front Controller调用的handleRequest(request,response)。
如果需要application对象，比如想用application.getRealPath()时，就要extends webApplicationObjectSupport。

3.2.每个Controler负责一组相关的action

我是坚决支持一个Controler负责多个action的，一个Controler一个action就像一个function一个类一样无聊。所以我用最传统的方式，用URL参数如msg="insert"把一组相关action交给一个Controler控制。ROR与制作中的Groovy On Rails都是这种模式，Spring也有MultiActionController支持。
以上三者都是把URL参数直接反射为Controller的函数，而Stripes的设计可用annotation标注url action到响应函数的映射。

3.3.xml宣告式编程的取舍

我的取舍很简单，反正Spring没有任何强制，我只在可能需要不重新编译而改变某些东西的时候，才把东西放在xml里动态注入。jsp路径之类的就统统收回到controller里面定义.

3.4.Data Binder

Data Binder是Controller的必有环节，对于Spring提供的DataBinder，照理完全可用，唯一不爽是对象如果有内嵌对象，如订单对象里面包含了Customer对象，Spring需要你先自行创建了Customer对象并把它赋给了Order对象，才可能实现order.customer.customer_no这样的绑定。我偷懒，又拿Jakarta BeanUtils出来自己做了一个Binder。

3.5.提取基类

      最后还是忍不住提取了一个基类，负责MultiAction和其他一些简便的方法。Sprnig的MultiActionController做得太死，规定所有函数的第1,2个参数必须是request和response，不懂动态的，温柔的进行参数注入。


     经过化简再化简，已经是很简单一个Java Bean ，任谁都可以轻松上手，即使某年某月技术的大潮把现在所有MVC框架都淹没了，也不至于没人识得维护。

相关文章
简化Spring(1)--配置文件
简化Spring(2)--Model层
简化Spring(3)--Controller层
简化Spring(4)--View层

江南白衣 2005-08-23 14:53 发表评论

简化Spring(2)--Model层

江南白衣 — Mon, 22 Aug 2005 06:55:00 GMT

    作者：江南白衣

    因为Spring自带的sample离我们的实际项目很远，所以官方一点的model层模式展现就靠Appfuse了。
    但Appfuse的model层总共有一个DAO接口、一个DAOImpl类、一个Service接口、一个ServiceImpl类、一个DataObject.....大概只有受惯了虐待的人才会欣然接受吧。
    另外，Domain-Driven逢初一、十五也会被拿出来讨论一遍。

    其实无论什么模式，都不过是一种人为的划分、抽象和封装。只要在团队里理解一致，自我感觉优雅就行了。
     我的建议是，一开始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。如下：

     又因为这些Service Bean都是单例，效率应该不受影响。

    4.总结
    对比Appfuse里面的5个类，我的Model层里只有VO作为纯数据载体，Manager类放商业方法。有人说这样太简单了，但一个应用，要划成几个JSP，一个Controller，一个Manager，一个VO，对我来说已经足够复杂，再要往上架墙叠屋，恕不奉陪，起码在我的项目范围里不需要。(但有很多项目是需要的，神佑世人）

    后记：迫于世人的压力，SpringSide暂时还是把DAO和Service层分开了，但依然坚持不搞那么多接口。
另外，尽量利用IDEA的代码生成热键，为Manager类生成delegate的Dao类方法。

相关文章
简化Spring(1)--配置文件
简化Spring(2)--Model层
简化Spring(3)--Controller层
简化Spring(4)--View层

江南白衣 2005-08-22 14:55 发表评论

简化Spring(1)--配置文件

江南白衣 — Sun, 21 Aug 2005 12:59:00 GMT

作者：江南白衣

序

    人人都爱Spring加Hibernate。
    但Spring MVC+hibernate的Sample如Appfuse的代码却算不得最简洁优美好读，如果在自己的项目中继续发挥我们最擅长的依样画葫芦大法，美好愿望未必会实现。
     所以，Pramatic精神不灭。这个系列就是探寻最适合自己的Spring+Hibernate模式。

                              I-配置文件简化

     我厌倦一切配置文件繁重的框架。
     最好的情况是，框架提供极端灵活复杂的配置方式，但只在你需要的时候。

     Spring提供了三种可能来简化XML。随着国内用户水平的提高，这些基本的简化技巧大家都已掌握。
     大家可以直接看第3，第4点--Spring 1.2, Spring 2.0的后继改进。

1.1.autowire="byName" /"byType"

     假设Controller有一个属性名为customerDAO，Spring就会在配置文件里查找有没有名字为CustomerDAO的bean, 自动为Controller注入。
     如果bean有两个属性，一个想默认注入，一个想自定义，只要设定了autowire，然后显式的声明那个想自定义的，就可以达到要求。这就应了需求，在需要特别配置的时候就提供配置，否则给我一个默认注入。

     还有一个更懒的地方，在最最根部的节点写一句default-autovwrie="byName"，可以让文件里的所有bean 都默认autowrie。
    不过Rod认为开发期可以这样，但Production Server上不应该使用Autowire。而我觉得那些自定义一次的地方比如TranscationManager应该详细定义，而Dao,Controller这种大量重复定义的bean就可以偷点懒了。

1.2.节点之间抽象公共定义和 Inner Bean

    这太方便懒人了，想不到两个独立的XML节点都可以玩继承和派生，子节点拥有父节点的全部属性。
    最好用的地方就是那个Transtion Proxy的定义。先定义一个又长又冗的父类，然后用子类去继承它。

    另外，还有一个Inner Bean的机制，可以把DAO写成Proxy的内部类。为什么要写成内部类?为了让Proxy冒名顶替它去让Controller Autowire。(详见后面的示例)

1.3. 宽松的配置, To XML or Not to XML
    据说Spring比Struts的配置宽松了很多，这就给人把东西从配置文件中撤回原码中的机会。
    不赞成什么都往配置文件里晒，造成了Rich Information的配置文件，修改或者查看的时候，要同时打开配置文件和原码才能清楚一切。
    而我希望配置文件就集中做一些整体的配置，还有框架必须的、无需管理的冗余代码。而一些细节的变化不大的配置和逻辑，就尽量别往里塞了。因此，Success/Fail View 的配置，不建议放在里面。

2.简化后的配置文件

1.Controller只剩下一句

2.DAO也只剩一句

3.Service类只剩下5行

  <bean id="customerManager" parent="baseTxService">
        <property name="target">
            <bean class="org.springside.bookstore.service.CustomerManager"/>
        property>
    bean>

3.Spring 1.2后xml语法简化

最主要的简化是把属性值和引用bean从子节点变回了属性值，对不喜欢autowire的兄弟比较有用。
当然，如果value要CDATA的时候还是要用子节点。另外，list的值可以用空格隔开也比较实用。

1.属性值

<property name="foo">
<value>fooValuevalue>
property>
简化为
<property name="foo" value="fooValue"/>

2.引用 bean

<property name="foo">
<ref bean="fooBean">
property>
简化为
<property name="foo" ref="fooBean"/>

3. list可以简化为空格分开的字符串

<property name="myFriendList">
  <list>
     <value>gigixvalue>
        <value>wuyuvalue>
  list>
property>
简化为
<property name="myFriendList" value="gigix wuyu"/>

4.Spring 2.0来了
   如果没什么外力刺激，spring xml 可能就这样不会变了。但现在xml成了过街老鼠，被ror的默认配置和JDK5的annotation逼得不行，当然就要继续求变。
   比如有好事者认为，节点名必须以bean打头，附加一个属性id来表示bean名；属性值必须搞一个property子节点，子节点上有个属性name来表示属性名，是给机器看的很不直观的东西。

给人看的东西应该就写成

Spring 2.0正用schema实现类似的语法，具体请看它的JPetStore sample。

5.使用Spring自带的DTD使编辑器Smart.

如果没有用Eclipse的Spring插件，那至少也要使用spring自带的dtd使XML编辑器smart一些，能够自动为你生成属性,判断节点/属性名称有没有拼错等。

6.还有更变态的简化配置方法
比如autoproxy，不过我觉得更简化就不可控了，所以没有采用。

相关文章
简化Spring(1)--配置文件
 简化Spring(2)--Model层
 简化Spring(3)--Controller层
 简化Spring(4)--View层

江南白衣 2005-08-21 20:59 发表评论