在分层架构中，是从总体上对系统进行一个分层，里面涉及纵横向的概念，一个大的系统从业务逻辑来讲可以不是单单的对信息的处理，也可能涉及到对一些其他的逻辑处理，这里就不能单单的把逻辑抽象到三层中，三层是横向分层中的一个层，如果对分层的焦距拉远点看是看不到三层的，如果把焦距拉近点看也许目标不会锁定在信息流的处理子层中。
1.
上图中将一个大的系统分解为三个业务逻辑块其实也就是我所说的三个大的层面，我们将焦距拉近看业务逻辑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和调用方是完全没有任何依赖的在程序调用时候没有任何类型的调用所以在解决方案生成的时候不会将我们引用的项目程序集拷贝到执行目录中，如果想省略手工操作可以在执行查找的时候先调用一下实现层的对象，这样当编译生成的时候代码检查到你有调用会将你调用的项目程序集拷贝到执行目录中，在通过接口工厂动态查找时不会失败；
这样就彻底的实现层层分离的规则