從 傳統的專案開發轉到移動網際網路開發已經半年有餘，經歷了許多，剛剛轉行時期的壓力山大，漸進掌握訣竅的得心應手。本人出於出版行業，現在這個行業面臨著擁抱網際網路的浪潮，如果不積極的擁抱網際網路，傳統的出版行業遲早要逐漸消亡。

需求：

現在需要一個平臺級別的管理 內容提供者，和內容運營者的 系統。

做了很多專案之後，我個人認為，很牛的專案都是貼近使用者需求，做出來的，而不是設計出來的。因為使用者的需求是萬變的，我們在最初做需求調研的時候，可以儘可能多的挖掘使用者的需求，不放過蛛絲馬跡。但是儘管如此， 隨著專案的進行，需求還是可能像雪花一樣紛飛而至。

由於需要管理 內容提供商，內容運營上，專案的許可權模型初期採用

使用者 —角色--  選單 模型，進行控制。開源的本人比較熟悉shrio，此開源的專案使用起來比較方便。

dao層，mybatis 可以適應讀寫分離，和簡單的效能調優等，

spring MVC 框架 現在差不多是市場的主流，最好用的還是它的AOP和IOC特點。

前臺介面，真心感謝bootstrap 這個優秀的前端框架 

由於考慮到後期開發中的需求的頻繁變動，移動端介面，與伺服器端專案採用分開開發的模式。

移動端介面開發目前經常使用的是採用JSON模式傳輸資料

或者未來可能為主流的resful 模式，此模式可以充分利用URL地址，將一些與業務邏輯無關的引數通過URL地址進行處理。增加專案的規範化。

或者採用webservice 

由於具體的需求是後期 介面需要對外，根據不通的許可權提供不通的服務，

此時初期介面許可權驗證採用了

和伺服器端 類似的 client   + role  + 選單URL 格式

伺服器端可以針對 每個 具體的呼叫介面的App分配一個clientId 和secret

APP在請求介面的時候，需要 根據具體的規則 例如 

clientId + 時間戳 + secret 然後進行MD5後封裝到請求頭後，伺服器端對請求進行系統級別的許可權鑑定。

系統級別的鑑定通過後，然後再通過介面許可權列表進行許可權鑑定。

APP開發的時候，需要雙方約定好，返回的狀態位

例如封裝物件 

responseBean {

String msg;//返回訊息

string Object data;//封裝返回的資料

Integer status;//封裝返回的狀態

}

具體的狀態可以定義個全域性的常量類，以便於後期的調整

Gloable{

public static final Integer SUCCESS=0;//請求成功

……

}

針對一些變化不大的且伺服器端和移動端共用的資料，可以採用memcached進行快取，在系統啟動後，根據具體的情況，進行資料載入。伺服器端改動後，進行重新載入。

注意memcached 需要做好安全隔離。

如果伺服器端專案可能有多個版本的時候，需要用SVN ，進行多個版本的控制，在主版本上打個分支 ，然後在主版本上改動後，通過 合併，把最新的需要合併的程式碼合併到分支上。