赶不上园子讨论三层最热烈的时候，看了几篇.Net三层的博客，手痒写点东西。菜鸟一个，勿拍砖。

 

     一、三层是什么？

          三层是多层架构中使用极为频繁的一种架构，三层三层，大体上分为三个层。分别是：

         1.数据访问层（DAL）。该层只负责对数据（数据库，xml，json等）的访问。力争做到原子性，独立性。大白话说，DAL就是提供对数据访问的接口，什么业务逻辑，什么缓存处理通通不去管。

         2.业务逻辑层（BLL）。该层就是根据UI层的需要，去封装DAL层提供的接口，将获得的结果集返回给UI层。理论上讲，数据验证，缓存处理，都是要放在BLL层上的。

         3.界面（UI）。该层只负责UI的显示，和数据的获取。数据处理的逻辑都放在BLL层中去做。

          当然，这只是理论上的理想型。实际开发中，总会有或多或少的跨层和穿透。甚至现在很多BLL层的逻辑放到了数据库的存储过程中。个人理解，如果UI层只依赖于BLL层，BLL层只依赖于DAL层，就算是实现了最基本的三层架构。如果架构的好的话，可以做到三层中的每一层都可以独立出来，随意的进行扩展和维护而不影响其他层的代码，就很完美了。

      二、三层的优点

         ”低耦合高内聚“总是被三层大师们挂在嘴边，但却让人印象不深刻。其实可以举个这样的例子，我们公司要做一个网站+桌面+移动一体化的系统软件。如果不用分层结构的话，难道还要为每个终端都写一套一模一样的访问数据库和逻辑控制的代码么？

        如果好的三层架构，完全可以在完成DAL层后，交付给其他三个终端的BLL层去使用。而当BLL层写完之后，就回家睡觉吧。UI层让美工们去鼓捣去吧，什么这个DIV在这里，哪个Panel在那里，我才不用管

       三、三层的缺点

        我们把三层看做一个厚厚的运行栈，当你看到那么繁琐的栈调用时，你能确定的唯一一件事情就是它必然效率低下 。当然，与以后要维护和扩展程序的代价相比，这点效率低下是完全可以忍受的。尤其是当程序是由你和其他同事一起完成的时候，那么明确的分工和模块之间的独立化就尤为珍贵了。尤其是当代码生成器十分方便的今天，三层写起来好像也没那么麻烦了好像。

 

       当然， 如果写代码的就我一个人，是写给我自己或朋友用的东西，那么，让三层见鬼去吧。