這篇博文呢，對于高手來說不值一提。僅作為入門同學的小建議。小編旨在幫助新人理解什么是【三層架構】？為什么使用三層架構？

且博文與使用無關，旨在幫助理解。小編會盡力把文字寫的有趣。

1.大佬們怎么想到使用三層架構？ 

         好了，咱們開始今天的第一個話題。程序世界的大佬們是如何想到使用三層架構的呢？其實這個問題很好回答。任何技術、思維的出現一定是為了解決一些問題。隨著問題的嚴重，這種解決問題的手段、技術、方法。被推而廣之。也就是說，我們假設在沒有三層架構的時候，編程遇到了一些麻煩。而三層架構的出現解決了這些麻煩。

        是什么麻煩呢？

2.少年李有錢之煩惱（跟編程一毛錢關系都沒有） 

        1）話說，從前有個人，他手頭突然有了點錢。（老板叫李有錢吧）

        于是他決定開一個小吃部。自己做老板！

       2）于是他決定招聘3名員工。招聘條件是這樣寫的。

       “小吃部招聘員工3名：工作簡單，待遇好。負責買菜、炒菜、上菜。月薪：￥500”。

           沒多久3個小明來應聘，做了李有錢員工，小吃部正常運營了起來。

           小明們每天買菜→然后炒菜→然后上菜。

           小明們做菜好吃，飯菜價格又實惠。有錢的小吃部日益紅火。

       3）隨著小吃部的生意的紅火。來吃飯的人越來越多，買菜的成本成了大問題。

            李有錢果斷怒花5塊錢在地攤買了3本采購的書給小明們學。

            小吃部暫時停業。

            小明們發奮圖強，努力學習。小明們慢慢發現買個菜有這么多學問。

            買菜的危機在1年以后，逐漸度過。。。。

       4）再后來顧客們開始向，李有錢老板反應。上菜的服務員形象太差，尤其個頭太矮。

        影響進餐。

        盡管小明們炒菜好吃，有錢不得不辭退了3位小明。重新招聘。

      “小吃部招聘員工，要求精通采購、炒菜、身高160cm以上、五官端正。工資高，待遇好”

         小吃部暫停營業。

     總結）

         不知道，這樣的一段扯淡式的敘述中，諸位看到了什么問題？

         如果按照李有錢大大的管理方式。

         員工菜不好吃，辭退換人，不管這人服務得如何出色。

         員工服務不好，辭退換人，不管這個員工炒菜多好吃。

         小吃部運營過程中，不論哪個環節遇到什么問題，都會影響到整個小吃部。

         小吃部就不得不進行整體的人員調整。

         總的來看，這么多的工作就不能交給一個人去完成。一旦出問題，我們只能辭退換人

         這個問題自然也存在于程序世界中。與數據庫的數據交換，數據的處理，還有前端的顯示。

         如果都交給這些工作都交給一塊代碼去處理，那么出現的問題 跟有錢小吃部是一樣的。     

         無論發生哪一環節出現問題，我們都必須對全部代碼進行修改。                                         

3.我們需要分工明確 

       其實，真實的世界中，有錢的招聘應該是這樣的。

       招聘：  采購 1 

                    廚師 1

                    服務員 1

       只有分工明確，才能物盡其用，人盡其才。

       廚師炒菜出現問題，問廚師就是了。。。

       其實，采購，廚師，服務員，就是我們生活中的三層架構。

1.三層架構 

        三層架構（3-tier architecture）通常意義上的三層架構就是將整個應用劃分成：

        表現層（PResentation layer）、             服務員

        業務邏輯層（Business Logic Layer）、  廚師

        數據訪問層（Data access layer）           采購

        區分層次就是分工，讓一部分的變動，盡可能少的影響另一部分。用軟件工程的行話說：這是“高內聚、低耦合”的思想。在軟件體系架構設計中，分層結構是非常常見的。

      其實不一定是三層，也可能是N層，跟生活中的分工一樣，不同的業務，有不同的分工。這跟程序的邏輯有關。

2.欲知后事如何，且聽下文分解 

     說好了今天只扯淡，在說就要跟程序相關了。so  就寫到這吧。

     求推薦，求分享。