關於MVC和分層體系的一點認識

MVC

• 目錄結構： MVC模式的目錄結構就是Model, Controller,View。Model用戶存放業務邏輯；Controller鏈接業務邏輯和模板，其實就是調用Model獲取到數據丟給VIEW展現出來； VIEW用於存放模板。
• 爲什麼過期：主要緣由在於在Model裏面混雜了業務邏輯和數據存儲邏輯
  1. 難維護。例如你須要對用戶信息作緩存時，就須要在業務邏輯代碼上動刀，這樣就涉及到業務代碼的改動。
  2. 難拆分。在業務邏輯中使用數據查詢常常使用鏈接查詢，好比用戶表和文章表須要拆分到兩臺獨立的數據庫服務器上，或者某個表水平拆分，都會致使大量的拆SQL工做。即便鏈接查詢會減小數據庫的請求，有可能提升系統性能，可是不推薦使用鏈接查詢。致使難維護和難拆分是主要緣由，從另一個方面考慮，到你的系統訪問量、數據量很小，SQL拆成獨立SQL，對系統的性能影響並不大。當你的系統大到必定程度，大到拆成獨立SQL會致使明顯的性能問題時，應該考慮分佈式了，而不是合併一些SQL，提升性能，即便提升了，隨着數據、訪問量的增大，你的系統很快有進入性能瓶頸。 3.難擴展。因爲在Model中是直接讀取SQL，沒有數據存儲層的概念，你極可能在用戶的業務邏輯裏面直接經過SQL讀取訂單信息，當訂單或者用戶業務邏輯要獨立出來時，又得去修改這部分代碼，這樣大大增長了開發成本和風險。

分層體系結構

• 什麼是分層體系結構：我我的理解就是拆分MODULE，把數據存儲和業務邏輯獨立出來。系統又可拆分爲獨立業務，好比訂單，用戶，文章，統計等。每一個獨立業務都有本身對應的業務數據，業務邏輯內部獲取本身的對應業務數據，只能經過數據存儲層來進行。獲取其餘業務數據，只能調用其餘業務

• 目錄結構：

• Common下面是各個服務公用的文件。

• 一個服務對一個目錄；例如：用戶服務在目錄User下，標籤服務在Tag下，問答服務在Question下。

• 單個服務內部結構：

  1. XXXService.php 爲服務接口，Impl目錄下爲文件XXXServiceImpl.php均爲服務接口的實現。爲什麼使用接口，本身GOOGLE針對接口編程，能夠看個簡單的例子http://www.cnblogs.com/lotusswan/archive/2008/08/22/231357.html 2.Dao爲數據存取層，裏面的代碼只能設計數據存取邏輯，不能設計業務邏輯。每一個表對應一個TableImpl.php文件**，不使用鏈接查詢。特殊狀況下，必定要使用到鏈接查詢，可使用Module->getDb()方法獲取到DB實例後直接執行SQL。
  2. Test目錄爲單元測試目錄。

• 使用此種結構的好處：

  1. 便於拆分業務，好比訂單有兩個業務，一個是常規業務，一個是統計業務，當訂單統計業務過大時，能夠將統計業務拆其餘地方，而且只須要實現接口文件定義的接口便可，客戶端只須要更改調用統計業務的方法，便可完成拆分。 例：

  <?php // 拆分前 public function indexAction() { $stat = $this->getOrderStatService()->getOrdersDistinctMap(); } protected function getOrderStatService() { return \Service\OrderStat\OrderStatServiceImpl::Instance(); } <?php // 拆分後 public function indexAction() { $stat = $this->getOrderStatService()->getOrdersDistinctMap(); } protected function getOrderStatService() { return RpcClient::Instance()->getService('OrderStatServiceImpl'); } 2. 便於數據庫垂直、水平拆分：對一單個服務，很容易將Dao層獨立出來，部署當單獨機器上，服務只須要更改調用對應的Dao的方法就能夠完成。

• Controller 和View 仍是和MVC同樣，不作更改