Thinking in sky

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

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

     摘要: 目前的Web Application大多采用流行的基于B/S模式的三层架构开发，这里的三层架构指的就是Web层、业务层和数据访问层。采用分层的开发方式有很多好处，下面只简单地来说两点：

　1：分层开发使不同的开发人员关注他们擅长的特定层面，有助于开发优质的系统。因为很少有程序员可以精通从JS，CSS，DHTML到struts再到 hibernate直至最后的数据库设计这一整套开发流程所要使用到的所有技术。大家各司其职，全力关注自己擅长的层面，这要比一个人或一个小组负责某一模块从页面到最底层的开发方式要好的多。

　2：.分层分离了逻辑，使得系统结构层次明晰，系统变得灵活和易于维护。开发人员应该尽量使系统的各层之间保持相对独立的松耦合状态，这是实现分层的必要条件，也是构建良构系统的重要保证。

  阅读全文

     摘要: Struts与Webwork的扇子请跳过本篇。

MVC不就是把M、V、C分开么？至唯物朴素的做法是两个JSP一个负责View，一个负责Controller，再加一个负责Model的Java Bean，已经可以工作得很好，那时候一切都很简单。
而现在为了一些不是本质的功能，冒出这么多非标准的Web框架，实在让人一阵郁闷。像Ruby On Rails那样简捷开发，可用可不用，而且没有太多的限制需要学习的，比如Webwork这型还可以考虑。但像Struts那样越用框架越麻烦，或者像Tapestry那样有严重自闭倾向，额上凿着"高手专用玩具"的，用在团队里就是不负责任的行为了。

  阅读全文

     摘要: 因为Spring自带的sample离我们的实际项目很远，所以官方一点的model层模式展现就靠Appfuse了。

但Appfuse的model层总共有一个DAO接口、一个DAOImpl类、一个Service接口、一个ServiceImpl类、一个DataObject.....大概只有受惯了虐待的人才会欣然接受吧。
另外，Domain-Driven逢初一、十五也会被拿出来讨论一遍。

其实无论什么模式，都不过是一种人为的划分、抽象和封装。只要在团队里理解一致，自我感觉优雅就行了。
我的建议是，一开始DO和Manager一生一旦包演全场，DO作为纯数据载体，而Manager类放置商业方法，用 getHibernateTemplate()直接访问数据库，不强制基于接口编程。当某天系统复杂到你直觉上需要将DAO层和Service层分开时，再分开就好了。
  阅读全文

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

I-配置文件简化

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

Spring提供了三种可能来简化XML。随着国内用户水平的提高，这些基本的简化技巧大家都已掌握。

  阅读全文

     摘要: 在初始化一个类，生成一个实例的时候，newInstance()方法和new关键字除了一个是方 法，一个是关键字外，最主要有什么区别？它们的区别在于创建对象的方式不一样，前者是使用类加载机制，后者是创建一个新类。那么为什么会有两种创建对象方 式？这主要考虑到软件的可伸缩、可扩展和可重用等软件设计思想。   阅读全文