三层架构之我见

      不久之前,老师叫我去讲三层架构,那时候吓了一跳,因为我只是知道这东西,却没有接触过.作为一个大二的学生,也许有人认为我就算怎么研究也不会真正理解三层架构.这一点我承认,我对三层架构可能真的不太懂,所以,我把自己的理解写出来,让大家帮我纠正一下~~

     无论是网上的人还是我周围的师兄,他们都追求着真正的三层架构,对正在的三层着迷.在我的观点来看,我看到的是分层的目的,至于自己的代码怎么分,只要是符合这一种分层目的还有思想的,无论是在同一个项目还是分在不同文件夹而已,都已经不是重点了.当然我不是说他们分得都对或者都错,只是在不同的场合我们的需求不同,不能用同一种分层方式来套进去,假如我们硬着来套进去,那三层便变得很死板.

     说回我自己理解的三层吧,首先呢,跟网上大多数的人说的一样,主要分成表示层(UI)----业务逻辑层(BLL)----数据层(DAL),数据库并不包在DAL中,这是我刚开始学的时候误以为DAL就是数据库(=_=)......层与层之间的沟通是通过定义好的接口来接受数据,上一层对于下一层是不可知的.他们通过接口通信,对于UI,BLL的接口已经说出BLL层有什么东西提供,对于BLL,他的接口已经说出他要提供什么功能给人家,DAL的也这么理解~~

     其次说说每一层的工作吧,UI,顾名思义,做的是一个外壳,该层的重点应该放在表示方式上(即如何令用户用得舒服),同时他为BLL提供原始的数据和接受BLL提供的数据显示出来.BLL,业务逻辑层,做的工作就是把UI的数据经过逻辑处理(业务上需要,并不是所有数据都要),再发送到DAL.当然有些业务逻辑处理没有设计数据库的操作的话就不用发送到DAL中啦~~,作为夹在UI和DAL中间的层,BLL同时也接受DAL的数据,根据需要进行逻辑处理后发送到UI中.最后到DAL啦,他呢,主要作用是对数据库中进行操作,那些什么新增删除修改查询啊,都在这里做.

    由上面看到,我们实际写代码的时候是一层一层的方法调用,可能有人说这样子会很烦的.我不可否认三层的代码量会比一般的多一些,从可扩展性和维护性来看,三层是不错的选择(当然三层的优点不止这些啦).当你想修改或者扩展的时候,你会很快的把要修改的地方进行定位,因为你知道那些功能的代码在哪里.我对他三层中我觉得最难搞的就是中间的业务逻辑层,我到现在对他都比较模糊的~~在看了petshop后,发现里面还有一个model这个东西,上网一搜,原来他的用处挺爽的~~

   小弟语文本来就不太好,所以语言表达上可能会有点问题,凑着看吧,我也是为学习而来的,看出问题记得要留言指导指导啊~~