大话三层架构_.NET_编程开发_程序员俱乐部

情景

        这篇博文呢，对于高手来说不值一提。仅作为入门同学的小建议。小编旨在帮助新人理解什么是【三层架构】？为什么使用三层架构？

且博文与使用无关，旨在帮助理解。小编会尽力把文字写的有趣。

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  就写到这吧。

     求推荐，求分享。