三层起步终结

       话说万事开头难，三层经历了一个礼拜，从理解到实现上机加上抽象工厂+反射+配置文件，同时中间为了它自己不得已的重装了一次系统。一路走来的确是有点难，但是还好我坚强的挺过来了！最后看到“登陆成功这个界面”的时候，我笑了。真的很开心。

        三层架构，通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层、（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。一下的这张简单的图，是我对三层的初步理解：

                                                             

        通过以上图片，以我的理解就是：

        顾客有一个需求，想要吃这个菜。其中服务员就好比是（UI层），他的任务是将做好的菜肴给顾客端上去，厨师是（B层），具体实现这道菜该怎么去做。采购员（D层）是一个库存的地方，厨师通过顾客的菜单（接口）去调用里边的材料。而且每个餐厅都有菜单，这个餐厅菜单（实体），每一层都要去调用这个实体。

三层的具体内容：

       UI(user interface)

                     位于最外层（最上层），最接近用户。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作                    的界面

     BLL(Business Logic Level)

                    

                    业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的                   作用。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计。

     DAL(Data Access Layer))

                    功能主要是负责数据库的访问。

具体应用原则：

       

      UI:只负责显示和采集用户操作，不包含任何的业务相关的逻辑处理。

     BLL:负责处理业务逻辑，通过获取UI传来的操作指令，来决定执行业务逻辑，在需要访问数据源的时候直接交给                DAL处理。处理完成后，返回必要数据给UI。

     DAL:只提供基本的数据访问，不包含任何业务相关的逻辑处理。

       开发软件用三层有很多好处，首先就是高内聚低耦合，如果是大型或者比较复杂的程序，利用三层有利于维护，减少了类与类之间的联系。但是相对于一些简单的程序，如果用三层就有点小题大做，而且三层也有它不利的一面，层次分多了降低系统的性能。本来很多业务可以直接造访数据库，一次获取数据，如今却必须通过中间层来实现。所以还是要根据具体情况来使用。但是毫无疑问的是，三层的利大于弊。