下载掌阅APP，畅读海量书库
立即打开
时维九月，岁属三秋，这是一个阳光明媚的金秋，MOL所在的公司又新招了三位同学，MOL总算不是孤军奋战了，于是MOL带大家去了楼下一家餐厅吃饭。吃饭不是目的，这是给大家上的第一堂课。
到了餐厅以后，一个很水灵的妹子迎上前来，问道：“几位帅哥要饭吗？”
MOL当时就不高兴了，回道：“你看我们长得像丐帮的吗？”
妹子脸一红：“我的意思是，各位想吃点什么？”
这时，月月搭腔了：“蒸羊羔、蒸熊掌、蒸鹿尾儿、烧花鸭、烧……”
妹子赶紧打住：“哥哥，我得问一下厨房师傅，看看能不能做。”
不大一会儿，妹子出来了：“实在对不住，您几位刚才点的那些，我们这里都做不了，因为这里是西餐厅。”
月月：“那二尺长的龙虾有吗？”
妹子：“二尺长的没有，有二尺七的，要吗？”
MOL一看不对劲，这是要把我吃到破产的节奏啊，赶紧说：“二尺长的龙虾都没有，那就来小龙虾吧。”
妹子：“小龙虾暂时没有，如果您可以等的话，等采购师傅回来了，就有了。”
MOL：“可以等，不就几分钟嘛。”
妹子愤愤地下去了，月月也一脸不满意，MOL赶紧打圆场：“不就是龙虾嘛，大小都是龙虾，小怎么啦？小就不能满足你了？”
然后是等待吃饭……
吃完饭回到公司，MOL招集大家开会。
MOL：“今天这顿饭不能白吃，它将开始我给你们的第一课——三层架构。”
月月：“吃饭都能扯上架构，神了嘿。”
鹏辉：“今天的饭吃得确实有点意思，不过还能和程序扯上关系就有点意思了。”
MOL：“我们刚才在餐厅吃饭的时候，总共有这么4个角色，分别是我们3个“饭桶”、服务员、大厨和采购师傅。”
（下面都是MOL口述，将不再以引号来包含）
在程序员的世界里，这几个角色分别对应的关系是：
除此之外，还有一个隐形的角色是菜市场的大妈，她负责把菜卖给采购师傅。她对应我们软件系统中的数据库。当然，我们对大妈是不感兴趣的，所以这里先不说大妈的事。
OK，根据上面的描述，我们可以把一个餐厅里的工作分成3个部分，分别是服务员、大厨和采购师傅，他们之间的相互关系如图2-1所示。
图2-1 餐厅分工
大家有没有想过，如果我雇佣一个人，这个人既会炒菜又能采购，还会当服务员，那么这些角色不就不用分开了吗？
非常好，我们假设有这样一个人存在，他既要当服务员与食客沟通，还要炒菜，还要去买菜，那么将会发生什么情况呢？
这个人先要恭敬地问食客“您来点什么？”，然后再跑到厨房换上工作服开始炒菜，如果发现没菜了还得自己去买菜。我相信，即使有这样一个人存在，那么他也会累得够呛。而且他炒菜或者采购的时候，是不能与其他的食客沟通的。最后他累得实在不行了，辞职走人了，老板就哭了，因为他一走，餐厅就没人干活了，餐厅也得关门。
所以，分开服务员、大厨、采购员这几个角色，有利于每个角色都专注于自己的职责任务，而且，即使有人搁挑子不干了，那也只需要找一个对应职责的工人来顶上就可以了，不至于让整个餐厅都变得很被动。
好了，说完了餐厅的分工，再来说一下我们所关心的代码中的三层架构。
通常意义上来说，三层架构是UI、BLL、DAL这3层。这3层可以对应到餐厅中的3个角色来对比理解。UI层负责与用户交互，并将用户的请求交给BLL层处理；BLL层负责从UI层获取请求并将处理后的数据交给UI层，同时它还向DAL层发送请求，并获取DAL层返回的数据；DAL层负责接收BLL层的请求，并进行数据处理然后返回给BLL层，在大多数情况下，DAL还需要从数据库中获取数据。它们之间的关系如图2-2所示。
图2-2 程序中的三层结构
同样的，我们完全可以不使用三层结构就可以完成一个项目，这种代码结构最常见于新手程序员写的代码。这样的结构将会面临很大的风险，如果业务逻辑变动，那么将会出现“牵一发而动全身”的现象，由此不得不对整个项目进行修改。所以，分层可以让专业的层（Layer）去做专业的事情，如果逻辑有变动，那么只需要修改相应的层就可以了。
PS：餐厅吃饭的例子非常经典，它将贯穿于本书中的章节，在后面的章节中经常会说到“如果餐厅中的大厨有个助手……”，希望大家能立刻回想起MOL在这一节给大家讲的餐厅吃饭的例子。