關于項目框架設計的一點學習
這兩天又在接觸一個新項目，對于如何設計一個項目的框架有了點概念，關于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側重業務邏輯。