大话三层架构
情景
这篇博文呢,对于高手来说不值一提。仅作为入门同学的小建议。小编旨在帮助新人理解什么是【三层架构】?为什么使用三层架构?
且博文与使用无关,旨在帮助理解。小编会尽力把文字写的有趣。
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 就写到这吧。
求推荐,求分享。