提到分层，我就想起一句图灵奖获得者说过的话：计算机科学领域任何问题，都可以间接的通过添加一个中间层来解决；当初看到这句话的时候还不能深刻的体会到这句话的真正灵魂是什么。之所以要写这篇文章作为技术爱好者之一更愿意与大家分享技术给我们带来的快乐，本人将从另一个角度来解析.NET分层架构的真正奥秘。分层，一些技术功底比较薄弱的程序员听到分层就会联想到三层架构(BLL,DAL之类的)，其实不是，分层是一个很大的技术框架思想，三层架构只不过是对普通的信息系统来说，将信息的流转通过三层来分解，在开发系统时一般总会在解决方案中新建一个Model层、一个BLL层、然后DAL层；其实如果是这样建项目的话跟一个解决方案中放上一个程序一样的只不过可以用文件夹分开建立文件是一回事；技术水品的不同对三层的理解各不相同，有时会加上一个接口层让每层依赖接口来实现，像上面的BLL、DAL之类的架构，只是人为的分解感觉解决方案看上去很清晰一幕了然，对框架来说没有什么分离作用，还是高耦合低类聚；
在分层架构中，是从总体上对系统进行一个分层，里面涉及纵横向的概念，一个大的系统从业务逻辑来讲可以不是单单的对信息的处理，也可能涉及到对一些其他的逻辑处理，这里就不能单单的把逻辑抽象到三层中，三层是横向分层中的一个层，如果对分层的焦距拉远点看是看不到三层的，如果把焦距拉近点看也许目标不会锁定在信息流的处理子层中，说起来比较抽象来个图吧；
上图中将一个大的系统分解为三个业务逻辑块其实也就是我所说的三个大的层面，我们将焦距拉近看业务逻辑1中的子层；
逻辑1这个大层被分解为两个子层BLL、和DAL，也就是我们常用的业务逻辑层和数据访问层；业务逻辑1层中主要是用来对数据库的增、删、改、查操作，将其抽象成BLL和DAL也是我们所熟悉的三层；在另外两个业务逻辑层中一样可以将其分解层多道子层；将子层分开后就要涉及到具体实现的问题了，就拿C#面向对象语言来将，架构跟思想都是一些方法论的东西，具体实现是少不了的；层是分好了是否在开发过程中真真做到层层隔离，不互相依赖，所以是用接口层分割开来，将具体的实现层脱离开来，我们将BLL层改为BLL接口层BLLI，将DAL层改为DAL接口层DALI，这样让BLL、DAL去实现BLLI和DALI接口，完全分离开发，这也是面向对象所提倡的面向接口编程而不是面向实现编程；
以后BLL层出现问题可以完全替换掉换另一个BLL层，DAL层同样也一样；但是这是思想性的东西落实到代码还没那么简单：
如：BLLI B=new BLL();//在通常情况下是这样去用接口的，但是似乎没有理论说的那么干净的分离，我们在通过添加一个工厂来实现分离；
这样在使用时：BLLI B=new BLLI工厂(BLLI接口类型);在调用工厂的时候将接口的类型做为参数传进去，在工厂中在通过接口类型去查找具体的实现对象；如：
public static T GetInterfaceRealization<T>(Type interfacetype)
{
Assembly ass = Assembly.LoadFrom("程序集的名称");
Type[] asstype = ass.GetTypes();
if (asstype.Length <= 0)
throw new Exception("接口管理器的异常：该程序集没有任何实现类");
for (int i = 0; i < asstype.Length; i++)
{
//获取该实现类的整个继承链中是否有传入的接口类型；
Type oddinterfacetype = asstype[i].GetInterface(interfacetype.Name);
if (oddinterfacetype != null)
{
T t = (T)System.Activator.CreateInstance(asstype[i]);
return t;//返回动态实例化的接口实现类；
}
}
throw new Exception("接口管理器的异常：没有该接口的实现类，必须先实现接口类才能查找");
}
因为同一个解决方案中的不同项目彼此直接引用时，有利于项目的开发调试，但是我们的BLL和调用方是完全没有任何依赖的在程序调用时候没有任何类型的调用所以在解决方案生成的时候不会将我们引用的项目程序集拷贝到执行目录中，如果想省略手工操作可以在执行查找的时候先调用一下实现层的对象，这样当编译生成的时候代码检查到你有调用会将你调用的项目程序集拷贝到执行目录中，在通过接口工厂动态查找时不会失败；
这样就彻底的实现层层分离的规则；所谓思考是前进的本质，本人也是通过不断的思考总结出来的一点点小的经验与大家分享一下，如果有什么地方说的不对的地方请大家指出，谢谢；