N层架构的理解

今天一个前同事问我这样一个问题：对于N层架构怎么理解？

 

好像在面试的时候，考官总是喜欢问这个问题，而且问的最多的是3层架构。如果按照以前，我的回答估计是展示层UI、业务逻辑层BLL和数据访问层DAL，好处是各个层逻辑分开互不干扰，实现是3个project，等等，估计还会说个实体层吧。我相信很多同学也会这么解释的。

 

但是，这种解释是否已经能够完全描述N层架构了呢？现在看来好像并不全面。如果现在要我解释一下N层架构，我可能会说是N个模块的组合的架构。这样说的理由如下：

1.N层架构要解决的是耦合问题。既然需要解决耦合，那么首先应该符合DIP，也就是说，各个层之间应该使用稳定的接口作为“通信的渠道”（此处的接口不等于interface，而是指稳定的抽象），使各个层的细节不对外暴露，也可以看做是层级别的OCP。

2.可以不按照UI、BLL、DAL的结构划分。可以具体问题具体分析，因为总重要的目的是解耦，当然UI、BLL、DAL这样的层次划分是有理由的，但不免有些局限性。推广来说，做没有界面或者没有数据访问的程序，也需要分层使各个功能点松散耦合。比如做一个图片比较的程序，获得图片和比较图片就可以分为两层，比较图片层不用知道我的图片是从哪里来的，从文件来也好，从屏幕截取也好，我只要关心这是个图片就已经足够了，获得图片层也是一样不需要知道怎么样来比较图片的。

3.真正的3层架构各层之间的调用和组织，与通常的3层或3.5层（加入实体层）实现不同。多数的所谓的3层架构的程序（而且以ASP.NET程序居多），一般都是UI.DoSomething->BLL.Entity.DoSomething->DAL.Entity.DoSomething一路调用下去，BLL层有的时候是相当的薄，薄到只有调用DAL对应方法的一行代码。这样做的好处可能也就是把SQL语句集中到一起而已，实际上还是个顺序结构，而且往往是逻辑会集中在UI而不是BLL层，并且BLL层像DAL的一个传话筒，DAL又像数据库的传话筒，有多少个表就要有多少个DAL的类和BLL的类。个人认为，真正的3层架构，应该是数据表的数量>DAL类的数量>BLL类的数量，越到上层结合的越紧密，下层相对松散。

 

其实，不管是什么软件架构方式，最根本的问题还是解耦，只要能把握这个最根本的目的，也就能做到表面无层但心中有层的境界了。