<?php
/**
 * 前言
 *     在開始之前首先要明確的是這裡所說的都是基於MVC模式的php應用，但是又不完全是MVC，因為這裡還有一個業務層。關於MVC
 * 每個人都有自己的看法，有的是將業務寫在控制器層（肥控制器瘦model），有的是寫在model層（肥model瘦控制器），
 * 但是這裡我們的業務有專屬的分層（Business層），業務層對控制器和model的隔離，是對具體業務的完整封裝。Model層負責的是對
 * 資料庫表模型的操作，包括增刪改差和資料的校驗等，使用ORM模型或者ActiceRecord。Controller層負責的是使用者訪問的控制，收集
 * 使用者的請求資料呼叫對應的業務，根據業務處理的返回資訊向用戶返回對應的結果，而不用關心業務層具體的實現。業務層用來實現對
 
 * 具體業務的封裝，根據不同的業務型別大致分兩類，一類是DataProvider（資料提供者）專門負責提供各種資料【注：包括快取獲取資料】，
 * 一類是BusinessHandler(業務處理程式)對具體業務的封裝。業務處理程式一般是一個公開的方法，也可以是一個類將複雜的業務分步驟
 * 進行封裝，提供公開的方法供Controller呼叫。
 */
/**
 * 第一階段：
 *      最初你的專案可能全都在一個目錄下，通過不同的目錄進行區分，多個子應用之間共享model或者業務層，通過這樣來達到業務的
 * 複用，一個比較好的情況是：控制器裡不會出現model的呼叫，而是直接呼叫業務方法，這個方法有確定的引數和返回值，將具體的業
 
 * 務封裝起來，而業務中不會出現對session，cookie等的呼叫，資料以引數的形式傳入，在業務中只是負責對資料層的呼叫完成整個業務，
 * 這時候只需要三個人就能完成對應用的開發，一個人寫前端頁面，一個人寫具體的業務，另一個人負責呼叫業務與前端完成互動。
 * 這是一種分層模式，如果沒有一套好的程式碼規範每個人可以以自己的理解開發自己負責那一層的規範，即使某一層不合格後面也可以
 * 對這一層進行單獨重構和優化而不是對整個專案。如果專案比較大，有較多的資料庫表，有較多的業務，這時候可以將整個專案按照
 * 業務模組去劃分讓不同的開發人員去完成不同的業務模組，這樣又保證了業務模組的規範性，如果這個模組不合格也只是對這個模組
 
 * 進行處理，而不用對整個業務層處理。
 *      一般情況我們會對業務層進行規範，傳入引數的規範，返回值的規範，甚至是對業務模型寫法的規範，業務模型封裝的規範，
 * 這些規範將大大提高團隊配合的效率，降低互相之間互動的成本，對於一個團隊是非常有必要建立一套這樣的規範，隨著團隊的擴大
 * 你會越發感覺到這種規範的重要性。
 *      對於一個擁有多個子應用的程式，這種做法將會省去對業務的重複開發從而達到業務的複用，保持了業務的一致性，讓業務
 * 便於維護。我們不選擇控制器的複用是因為每一端的具體業務不同，返回結果的方式和方法不同，處理請求的方式方法不同，如果複用
 * 控制器中將會有很多流程分支語句來控制業務走向，而且控制器本來就比較簡潔，對於整個業務來說它就像路由一樣。
 */
/**
 * 第二階段：
 *      當業務發展到一定的程度，升級配置或者增加伺服器所帶來的收益已經跟不上業務的需求的時候，你可能需要考慮將應用部署
 * 到不同的伺服器上去了，你可能要用子域名來管理子應用和或者模組，但是又希望業務層不用重新開發，這時候就需要對專案進行切割。
 * 將子應用分散到不同的伺服器，單獨將業務層部署到一臺伺服器。由於業務層和model層都是獨立的，就可以為這些業務直接寫一套介面，
 * 子應用將會通過呼叫介面的方式來呼叫業務，這樣就以最小的變動保證了業務層的穩定。而切割出來的子應用依然是使用控制器，
 * 在控制器中呼叫業務方法，只是這時候業務方法的實現就僅僅是發起一個curl請求，去請求業務的介面完成一個請求。我們會發現控制器
 * 沒有發生修改，業務也沒有發生修改，而是利用業務層的副本進行修改讓他們從直接呼叫業務變成發出一個curl請求呼叫業務。然後
 * 對業務層的請求方法進行抽象，對介面進行異常處理就輕鬆的完成了專案的切割。
 *      為了保證業務伺服器的安全我們直接將它放在內網只能讓應用伺服器請求，資料庫也是隻有業務伺服器才能進行連線，
 * 而外部的請求就不能對業務造成危害，獲取資料也可以在這裡直接加上快取。可能部分資料需要多個數據庫，或者多個型別的資料庫
 * 聚合產生，這裡可以採用定時任務去產生然後放到redis或者memecache中快取起來讓業務方法直接獲取。
 *      在一些對安全性要求比較高的應用，比如金融等等的發展到這個階段的時候就可以將業務層轉為java開發，從而平滑的提升程式的
 * 安全性和效能。這樣就變成了一個php做前端，java做後臺的應用，在效能和開發效率達到了一個平衡。
 *      在這個階段我們可以將靜態資源也獨立出來，專門放在一個靜態資源伺服器，或者也可以將靜態資源放到雲端進行管理。雲端的資料
 * 往往是有多個備份的，這意味著安全性得到了很大的保障，有些也提供了對圖片資源的處理，和對資源訪問的控制。開啟CDN加速後
 * 網站的速度又將獲得一個極大的提升，而我們的應用伺服器的壓力也得到了有效的緩解。
 */
/**
 * 第三階段：
 *      當網站有了比較多的訪問量的時候，單臺伺服器已經很難支撐大併發，這個時候可以考慮使用負載均衡來提升應用的抗併發能力，
 * 根據應用的訪問量定製大小不同的應用叢集。如果業務層的規劃很好不需要重新開發，這時就可以根據業務模組放到不同的業務伺服器叢集。
 * 而資料庫和快取的壓力可以通過主從讀寫分離的方案進行升級，當然這些都是基於你的專案有一個不錯的基礎，清晰的分層結構，合理的
 * 資料庫設計，和良好的程式碼規範。一個相反的案例就是隨著專案的成長每到一個階段都要對專案重新進行開發，甚至對資料庫重新設計，
 * 這樣帶來的就是大家一直在趕專案，一直在加班，一直在測試，一直在改bug。
 */
/**
 * 尾聲：
 *      筆者是一個php程式設計師，沒有豐富的經驗和資歷，只是結合自己做專案的經歷和在專案中的觀察和總結來談談自己對網站應用開發
 * 中的見解和認識。由於對沒有經歷過大型的專案，所以對第三階段也不好說太多，只是按照自己的所想簡單的表達出來。文中沒有提一些
 * 技術上的細節及實現方案或者具體的例子，可能導致表達不清楚，所以就總結了幾個關鍵字：分層、切割、平滑擴充套件。希望可以對那些
 * 曾經和我一樣糾結的人一些借鑑，互相學習，共同進步。
 */