情景
这篇博文呢，对于高手来说不值一提。仅作为入门同学的小建议。小编旨在帮助新人理解什么是【三层架构】？为什么使用三层架构？
且博文与使用无关，旨在帮助理解。小编会尽力把文字写的有趣。
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）、 厨师
数据访问层（Dataaccesslayer） 采购
区分层次就是分工，让一部分的变动，尽可能少的影响另一部分。用软件工程的行话说：这是“高内聚、低耦合”的思想。在软件体系架构设计中，分层结构是非常常见的。
其实不一定是三层，也可能是N层，跟生活中的分工一样，不同的业务，有不同的分工。这跟程序的逻辑有关。
2.欲知后事如何，且听下文分解
说好了今天只扯淡，在说就要跟程序相关了。so 就写到这吧。
求推荐，求分享。