最近的工作內容相對來說比較單調，寫着毫無業務邏輯的CURD，本文算是一個吐槽吧，亦可以當作瞎扯。
項目組結構爲：一個leader，我和另外一哥們。我的pattern 和我工作經驗相當，看起來應該是合作起來比較理想吧。工作內容是重構一個官網後臺，以及運營平臺的部分整合過來（主要是用戶信息，充值、查詢等信息）。項目性質：無大併發，數據量略大（已分表，分庫處理），99%爲CURD,毫無業務邏輯。
前期技術選型討論，我主張：Hibernate + servlet + jsp，架構上採用2層架構，直接servlet + Dao,Domain實現。我的pattern的建議 Spring + Hibernate + SpringMVC + Apachel tiles(頁面框架式佈局） + jGrid組件，分層上仍採用傳統的Controller + Service +Dao,Domain。
先說說我的選型理由和預期作法：
- 業務性質全是CURD，採用Hibernate可以大大的提開效率，減輕工作量。
- 還是業務邏輯性質決定，無業務邏輯，故僅採用2層設計，省去傳統的Service層。
- jsp + servlet的交互方式簡單，不會增加額外的技術複雜度。
- 爲了處理多數據源，可以自己寫一個Hibernate工具類，可以採用Annotaion + ThreadLocal的方式進行處理，解決多數據源的問題。
- 在表單提交，表單項較多時，可以寫一個工具類，完成參數到實體的轉換。
最後討論的結果是，我的方案被摒棄。採用了我pattern的方案，leader交所有的設計交給他。好吧，我就重建了我這個模塊的實體，測試。經過3個周的工作，至目前爲止，整體框架纔算穩定。
首先在spring版本上，採用3.2，要springMvc 注入 dao Service時出了問題，因爲採用了2個Context, 在Service層加上事務時，springMVC注入的處理，3.2的處理與3.1上還是有所不同的。這算是一個盲目採用新版本所帶來的問題。
其次，Dao,Service設計上，採用 接口----實現的方式來做。 在這個問題上，我堅決的提出反對，我最反感爲了接口而接口，往往喜歡用這種方式的人，都是爲了說擴展性，那麼我想問一下，在你所經歷的項目中，有多少項目上線之後，後續對Dao,Service進行了整體擴展的？ 倘若沒有，那麼爲何要設計這個接口？部分方法的的擴展，完全可以通過重載等方式進行。那這麼多接口，除了徒增了工作量，複雜性，還帶來了什麼？有人說，帶來了標準化。 那我想問：標準是什麼？標準是人定的，採用接口---實現就是標準？那在沒有多態的地方直接用實現類，就不是標準了？ 只要一個項目裏面統一風格，難道不標準麼？有人說在分層開發中，即dao,service,controller分別爲不同的人開發時，採用接口--實現類的方式有優勢，我承認，這種場景這種方式是有一定的好處，但是用類就做不到麼？定義空方法給上層程序員用就不行了麼？在這裏，我再一次被強力否決，leader與pattern都強力否決了我，理由也就上面的這些之類的云云。
最後，就是頁面表格組件，因爲他選型，所以這個JGrid組件，我沒有去深入瞭解，都是他向我解釋怎麼用。表格的數據來源方式，一定要通ajax方式，導致我們在controller中，必須先寫個跳轉到頁面的方法，跳轉到列表頁面，然後定義一個獲取數據的方法，能ajax調用來加載數據。 其實這點我是懷疑態度的，我覺得做爲一個組件，這種方式顯然顯得有些傻B，就算不支持，也可以自己修改擴展達到。結果又被否決，首先他告訴我，我期望的方式達不到，其次否決修改組件來擴展的方式，避免以後升級的問題。 這個理由，我又再一次不同意，一個表格組件，你老是升級他幹什麼？
如果一個技術你掌握不了，那就不是玩技術，而是被技術玩。至於公司的組件這些類，應該是趁空閒，或者是專人進行編寫，或是找開源的進行自己擴展，以符合自己的需要。
我分配的幾個模塊的後臺，早就寫好了，也用junit測過了。這周才能開始與jgrid進行數據交互，被告知這周要完成所有功能。好吧，加班吧，爲你們的架構買單。
