关于项目框架设计的一点学习
这两天又在接触一个新项目，对于如何设计一个项目的框架有了点概念，关于web项目（对于oa系统来说）的主体感觉比较需要设计的几部分为：
1． 页面模板定义：关于view层展示，无论对于top（顶层菜单）+left（左边树状菜单）+right（主体内容）结构还是left+right结构，都需要首先定制一些模板，如struts中可使用tiles定义。
2． 分页标签：自定义一个比较通用的分页标签或者使用一些框架中自带的（如struts-menu或者JSF中的t:dataScroller），不过比较好的做法是基于其源码编写自己的分页标签。
3． DB 设计：可使用Power Deisign等设计数据库表结构，产生相关的表。
4． 代码自动生成：编写代码生成脚本如build.xml文件的编写（根据DB生成代码，也可以忽略3，先建model，再从model生成代码和数据库schema），生成Struts、Spring、Hibernate相关文件。
关于代码的整体架构如下：
action 层：处理从view层传递过来的数据。
service 层：封装业务逻辑，一般同时在spring中声明事务代理。
dao 层：进行事务中的原子操作，同时在spring中注入相应的sessionFactory。
Spring + Struts 取得spring的bean的两种常用方法：
1. DelegatingActionProxy ：将所有action标签中type属性设为org.springframework.web.struts.DelegatingActionProxy 也就是将action委托给了spring，同时在 action-servlets.xml 中配置一个于action标签path属性对应的bean(也就是bean的name值等于action的path值)，如：
struts-config.xml 中，以struts的plugin的方式,让spring接管struts的action：
< action name = "portalForm" parameter = "method" path = "/portalAction" type = "org.springframework.web.struts.DelegatingActionProxy" scope = "request" >
< forward name = "portalEdit" path = " pages/portalEdit.jsp" />
< forward name = "portalList" path = " pages/portalList.jsp " />
</ action >
< plug-in className = "org.springframework.web.struts.ContextLoaderPlugIn" >
< set-property property = "contextConfigLocation"
value = "/WEB-INF/action-servlets.xml" />
</ plug-in >
action-servlets.xml （配置文件格式和spring配置一样）中：
< beans >
< bean name = "/portalAction"
class = "com.cn.lively.action.PortalMainAction" >
< property name = "portalService" >
< ref bean = "portalService" />
</ property >
</ bean >
</ beans >
2. WebApplicationContextUtils.getRequiredWebApplicationContext ：在action中获得spring的bean，
public Object getService (String name) {
ApplicationContext wac = WebApplicationContextUtils.getRequiredWebApplicationContext(servlet.getServletContext());
return wac .getBean(name);
}
这种方式没有在struts里边加入spring的plugin，实际上是使用了依赖查找来获得对象，并且在servlet代码中硬编码了应用对象的bean名字。
附：
感觉一个国内小型项目（周期半年左右）的开发，完美的团队大概四个人左右就够了，
A ：前期框架设计 + 开发过程中不断改进完美整个框架，角色——架构师
B ：前期需求调研 + 开发过程中负责技术难度比较大的模块开发，角色——程序员
C ：前期需求调研负责人 + 开发过程中负责业务逻辑复杂的模块开发，角色——项目负责人
D ：前期需求调研 + 开发过程中负责模块开发，角色——程序员
同时B、C负责共同解决开发中出现的技术和业务问题，C负责控制项目进度，
项目后期，B、C、D进行交叉测试，A负责review代码。
如果公司已经比较成熟的框架（即基本系统管理模块 + 代码自动生成），那么角色A可以省略，只需要B、C、D三个人即可进行项目开发，其中角色B在开发中担当一部分A的角色。
甚至可以只由B、C两个人进行开发，把角色D的工作分担到B、C身上，B侧重技术，C侧重业务逻辑。