分層模式開發+MVC模式開發--韓順平僱員數據庫管理

一、分層模式

　　在使用分層設計模式編寫代碼以前，咱們更多的是採用面向過程而後眉毛鬍子一把抓，在一兩個程序代碼裏寫完全部的功能，這樣只適合於小型我的項目。由於不利於閱讀和修改，只有編程的我的比較熟悉程序的結構。這不利於程序的擴展性和協同開發。因此，咱們引入一個固定的模式來進行編程，使得全部代碼結構清晰明確，並且易於擴展延伸。

　　此處介紹的一種模式是分層模式。把程序分紅幾個層次：界面層、業務邏輯層、數據層。

　　界面層：主要功能就是實現界面的顯示。好比要在登錄頁面顯示輸入框之類，就須要login.php中放入form表單。好比要顯示僱員信息，就須要empList.php來顯示從數據庫中獲取的信息。可是，login.php中獲取的輸入數據是否合法與界面層無關；empList.php中顯示的信息界面層也不用管來自哪裏，它只要完成顯示就行。具體這些數據操做都交給業務邏輯層來作，它要作的只是接受業務邏輯層反饋回來的結果並做出相應顯示便可。

　　業務邏輯層：主要功能是實現邏輯處理，與界面層無關。該層主要包括 Admin.class.php,AdminService.class.php,Emp.class.php,EmpService.class.php等,Admin、Emp表示數據庫中的兩張表。

其中，Admin.class.php、Emp.class.php均爲類，類內的成員變量就是各個表格本身的屬性；

　　　AdminService.class.php、EmpService.class.php均爲類，主要做用就是爲兩張表格的操做提供函數支持；

除此以外，業務邏輯層還包括 SqlHelper.class.php助手類，主要提供mysql數據庫操做支持。其餘函數想要對數據庫進行操做都要經過調用該助手類來操做數據庫，例如完成 增刪改查 操做。

　　數據層：就是指mysql數據庫，在數據庫裏存放着要使用的表格Admin和Emp。這是最低層的數據庫資源。

 

針對僱員信息管理系統，來分別講解着三個層：

　　界面層：login.php empList.php等：login.php負責顯示錶單供用戶輸入，輸入數據的合法性交給loginProcess.php來處理,而loginProcess.php又會去調用AdminService.class.php中的CheckAdmin（）函數來驗證並返回結果。

　　　　　　　　　　　　　　　　　　　empList.php負責來顯示僱員信息，它的數據來自empManage.php，而這個php又會調用EmpService.class.php來實現實際操做。

　　業務邏輯層：CheckAdmin（）經過調用sql助手類來對數據庫操做，驗證輸入的信息是否合法。

　　　　　　　　SqlHelper.class.php助手類主要提供各類對數據庫的基本操做，例如：構造函數要實現獲取鏈接、指定數據庫、設置編碼格式；execute_dql($sql)實現執行查詢指令，返回$res;execute_dml($sql)實現增刪改操做，返回$res;mysql_close_conn()自動關閉助手類中定義的鏈接。

　　數據層:就是最低層的數據庫。

 

二、mvc模式

• （控制器Controller）- 負責轉發請求，對請求進行處理。
• （視圖View） - 界面設計人員進行圖形界面設計。
• （模型Model） - 程序員編寫程序應有的功能（實現算法等等）、數據庫專家進行數據管理和數據庫設計(能夠實現具體的功能)。

• 模型（Model） 用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。「模型」有對數據直接訪問的權力，例如對數據庫的訪問。「模型」不依賴「視圖」和「控制器」，也就是說，模型不關心它會被如何顯示或是如何被操做。可是模型中數據的變化通常會經過一種刷新機制被公佈。爲了實現這種機制，那些用於監視此模型的視圖必須事先在此模型上註冊，從而，視圖能夠了解在數據模型上發生的改變。（比較：觀察者模式（軟件設計模式））

• 視圖（View）可以實現數據有目的的顯示（理論上，這不是必需的）。在視圖中通常沒有程序上的邏輯。爲了實現視圖上的刷新功能，視圖須要訪問它監視的數據模型（Model），所以應該事先在被它監視的數據那裏註冊。

• 控制器（Controller）起到不一樣層面間的組織做用，用於控制應用程序的流程。它處理事件並做出響應。「事件」包括用戶的行爲和數據模型上的改變。

三、設計模式

　　設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構同樣。

　　

設計原則編輯

爲何要提倡「Design Pattern呢？根本緣由是爲了代碼複用，增長可維護性。那麼怎麼才能實現代碼複用呢？面向對象有幾個原則：開閉原則（Open Closed Principle，OCP）、里氏代換原則（Liskov Substitution Principle，LSP）、依賴倒轉原則（Dependency Inversion Principle，DIP）、接口隔離原則（Interface Segregation Principle，ISP）、合成/聚合複用原則（Composite/Aggregate Reuse Principle，CARP）、最小知識原則（Principle of Least Knowledge，PLK，也叫迪米特法則）。開閉原則具備理想主義的色彩，它是面向對象設計的終極目標。其餘幾條，則能夠看作是開閉原則的實現方法。

設計模式就是實現了這些原則，從而達到了代碼複用、增長可維護性的目的。

開閉原則

此原則是由Bertrand Meyer提出的。原文是：「Software entities should be open for extension,but closed for modification」。就是說模塊應對擴展開放，而對修改關閉。模塊應儘可能在不修改原（是「原」，指原來的代碼）代碼的狀況下進行擴展。那麼怎麼擴展呢？咱們看工廠模式「factory pattern」：假設中關村有一個賣盜版盤和毛片的小子，咱們給他設計一「光盤銷售管理軟件」。咱們應該先設計一「光盤」接口。如圖：

[pre]______________

|<>|

| 光盤 |

|_____________|

|+賣() |

| |

|_____________|[/pre]

而盜版盤和毛片是其子類。小子經過「DiscFactory」來管理這些光盤。代碼爲：

1 2 3 4 5 6 7 8 9 10 11

publicclassDiscFactory{   publicstatic光盤getDisc(Stringname){   //return(光盤)Class.forName(name).getInstance();   return(光盤)Class.forName(name).newInstance();   }   }

有人要買盜版盤，怎麼實現呢？

1 2 3 4 5 6

publicclass小子{ publicstaticvoidmain(String[]args){ 光盤d=DiscFactory.getDisc("盜版盤"); d.賣(); } }

若是有一天，這小子良心發現了，開始賣正版軟件。不要緊，咱們只要再建立一個「光盤」的子類「正版軟件」就能夠了，不須要修改原結構和代碼。怎麼樣？對擴展開放，對修改關閉——「開閉原則」。

工廠模式是對具體產品進行擴展，有的項目可能須要更多的擴展性，要對這個「工廠」也進行擴展，那就成了「抽象工廠模式」。

里氏代換原則

里氏代換原則是由Barbara Liskov提出的。若是調用的是父類的話，那麼換成子類也徹底能夠運行。好比：

1 2	光盤d=new盜版盤(); d.賣();

要將「盜版盤」類改成「毛片」類，沒問題，徹底能夠運行。Java編譯程序會檢查程序是否符合里氏代換原則。還記得java繼承的一個原則嗎？子類override方法的訪問權限不能小於父類對應方法的訪問權限。好比「光盤」中的方法「賣」訪問權限是「public」，那麼「盜版盤」和「毛片」中的「賣」方法就不能是protected或private，編譯不能經過。爲何要這樣呢？你想啊：若是「盜版盤」的「賣」方法是private。那麼下面這段代碼就不能執行了：

1 2	光盤d=new盜版盤(); d.賣();

能夠說：里氏代換原則是繼承複用的一個基礎。

依賴倒轉原則

抽象不該該依賴於細節，細節應當依賴於抽象。

要針對接口編程，而不是針對實現編程。

傳遞參數，或者在組合聚合關係中，儘可能引用層次高的類。

主要是在構造對象時能夠動態的建立各類具體對象，固然若是一些具體類比較穩定，就沒必要在弄一個抽象類作它的父類，這樣有多此一舉的感受

接口隔離原則

定製服務的例子，每個接口應該是一種角色，很少很多，不幹不應乾的事，該乾的事都要幹。

合成/聚合複用原則

合成/聚合複用原則（Composite/Aggregate Reuse Principle，CARP）常常又叫作合成複用原則。合成/聚合複用原則就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分；新的對象經過向這些對象的委派達到複用已有功能的目的。它的設計原則是：要儘可能使用合成/聚合，儘可能不要使用繼承。

就是說要少用繼承，多用合成關係來實現。我曾經這樣寫過程序：有幾個類要與數據庫打交道，就寫了一個數據庫操做的類，而後別的跟數據庫打交道的類都繼承這個。結果後來，我修改了數據庫操做類的一個方法，各個類都須要改動。「牽一髮而動全身」！面向對象是要把波動限制在儘可能小的範圍。

在Java中，應儘可能針對Interface編程，而非實現類。這樣，更換子類不會影響調用它方法的代碼。要讓各個類儘量少的跟別人聯繫，「不要與陌生人說話」。這樣，城門失火，纔不至於殃及池魚。擴展性和維護性才能提升。

理解了這些原則，再看設計模式，只是在具體問題上怎麼實現這些原則而已。張無忌學太極拳，忘記了全部招式，打倒了「玄冥二老」，所謂「心中無招」。設計模式可謂招數，若是先學通了各類模式，又忘掉了全部模式而爲所欲爲，可謂OO（Object-Oriented，面向對象）之最高境界。呵呵，搞笑，搞笑！

最少知識原則

也叫迪米特法則。不要和陌生人說話。