業務邏輯、架構----思考

根據近期接觸的知識和問題整理，主要說明： 開發中我如何處理那些業務邏輯。。。

1。 架構

　　形容事物的整體構成，去除内在的修飾、實作内容，最後留下的構成事物的骨架就是架構。

　　e.g ： 庖丁解牛,他熟練在于熟知牛身體的骨架，知道從哪下刀，在哪應該注意等等。

　　再來看看項目工程，無論是剛開始做項目還是給項目做二次開發，我們最先就應該了解的是“架構” ，從客戶手中的請求到伺服器那端的響應，在此過程中經過這一系列的函數調用和資料操作，才完成一個功能點。   雖說覺得複雜，但也不複雜。 因為你長期和這類事物接觸就覺得大同小異了。

　　也許對于我們來說：Struts2+Hibernate+Spring這一架構(也是架構)非常熟悉，成套的規則，易懂的操作，擴充性強，處理大資料也不馬虎。 這就讓我對它形成了依賴，久而久之按照非常老套的方式來程式設計：

　　POJO->業務邏輯->DAO　　

　　插曲：之前在學院内接觸到的PHP小架構---每個請求都會進入index.php主程式，然後根據url的通路路徑來将通路不同的子產品，然後來執行各自的業務邏輯函數，最後CRUD資料并互動給前台頁面顯示。

　　　　　而這衍生出來的JAVA小架構，思想近似相同，看上去好像會對每個POJO建立DAO、SERVICE、ACTION，可想而知那工程檔案就相當龐大了，架構的思想很不錯，但卻讓我發現我漸漸的依賴它，一直誤解了子產品如何去分塊，我建了個TestAction，Test頁面中的請求全扔給TestAction來處理，那往後是不是有了相同操作也都要如此操作呢？

　　靠着這些無腦操作，更讓自己覺得很久沒學到東西了(除了一些技術) ，日常做的無非就是對資料庫的CRUD、頁面業務邏輯更改、前台頁面效果的處理。

　　說到底這些東西其實是我們都在做！ 那我們覺得自己已經能夠熟用他們。并且設計完美了嗎？   我覺得沒有！

2. 業務邏輯

　  我就覺得我沒有掌握，在某些方面完全就是個小白！

　　----因為新項目在上線，着手開始構思，設計資料庫，觸發器對資料處理(省去很多邏輯代碼)，分析功能需求，以每個POJO對象為機關來建立DAO、Service、Action，這樣貌似一個整體的架構就基本完成了， 但是今天boss卻跟我說“你這樣的一個設計 以後編碼你不覺得你很累嗎？”   當時我就覺得 這樣的做法很平常啊，也很容易讓人一看就懂了！

　　問題： 從軟體制作流程來看并沒有什麼錯誤，但是在業務邏輯處理這方面卻發現 重複性的工作很多很多... (雖然一個POJO一個Action讓人好找代碼，而且結合頁面的功能就能找到相應的邏輯函數，但是牽一發而動全身的道理我們都懂，這樣的代碼将不利于後續開發，現在又有哪個軟體能做到一步到位，永久使用？----起碼連個API也要不斷完善和更新的，自己寫的代碼更是！)

3. 解決(架構+業務邏輯)

　　業務邏輯：

　　1. 設計邏輯層之前，按照如下流程：存在哪些對象、需要哪些操作(業務邏輯)、需要哪些list(與前台互動資料)

　　也就是處理業務邏輯層時, 如果項目小的話，就可以按：對象 來劃分 ，至于一些共同的邏輯操作和需要的資料操作，我們可以用繼承體系來解決，減少代碼的編寫量

　　2. 針對大項目，邏輯層易變動(就是前台頁面資料需求更替)，我們就要為資料處理的業務邏輯單獨處理，用最少的代碼管理一類操作。

　　拿到一個項目對其進行二次開發，按照我現在的開發流程：

　　1. 釋出通路、大緻了解站内基本功能，劃分了幾大子產品，有個印象就行

　　2. 了解 Http請求處理機制，以及資料互動的一整套流程

　　3. 熟知項目的整體架構，如：繼承體系、站内配置、DAO資料通路、業務邏輯的劃分，以及是否颠覆你的思想讓你受益匪淺！

　　4. 完成上述流程之後，如果你能在了解全部的功能并整理文檔劃分好規則。後續的開發隻需要根據自己拟定好的邏輯規則實作方法就好了，至于最後取資料也就小菜一碟