由于个人学习之初，第一次使用三层架构的时候就是用的抽象三层架构模式，当时个人笨得不知道用工具，主要原因是个人当时的观点是：用一个新工具时，还得去熟悉新工具；刚学习的时候重点是技术；在技术比较熟练后再用工具来提高效率。
学习三层结构模式最好的方式就是拿一个（带三层模式）项目来实践。第一次我用的是petshop，使用的是抽象三层架构，但是项目还没有跑不起来，自己也没去调试，在项目实践中就学习套用了该三层模式（主要觉得代码组织形式很好）。在工作中，项目使用的是简单三层工厂！在适应中很难去接受这样的架构，主要是冗余太多，修改起来非常麻烦！
普通三层是所有东西已知，架构是竖井方式。
抽象工厂则是面向未知，架构是横向扩展。
一、简单三层架构：
1、从上图可以宏观看出从单类层到简单三层的实现，具体代码（例如vs里面选择部分代码->右击->重构->提取方法;右击->重构->提取结构）。
1）一层到二层：单层代码组织显得非常混乱。
2）二层到三层：业务逻辑层的加入起到了缓冲的作用，业务逻辑层跟业务紧密相连（如可放置权限，某段时间可修改等业务规则）。
此外，领域对象对数据访问层数据对象的封装，也有利于表示层对业务逻辑层的调用。在三层式架构中，表示层应该是对于数据访问层是“无知”的，这样既减少了层与层间的依赖关系，也能有效避免“循环依赖”的后果。
唯一可堪欣慰的是，由于我们采用分层式架构将用户界面与业务领域逻辑完全分离，一旦用户界面发生更改，例如将B/S架构修改为C/S架构，那么业务逻辑层的实现模块是可以完全重用的
3)Model层的引入：各个层之间用参数传递可能参数个数太多，而且编码不易阅读。将各个传递的参数封装起来，各个层传递的Model可能有所不同！
二、抽象工厂三层架构：
上图为简单三层架构到抽象三层架构的过程：
1）为什么要DAL要定义接口类：将具体的实现延迟到具体的类（如sql、oracle等访问）。
2）抽象工厂的作用：其实工厂就是利用反射机制动态加载类。抽象工厂则是面向未知！如果想切换数据（如从sql server改为oracle数据库似乎不太可能，这时就需要工厂三层架构），有了抽象工厂就可以通过配置文件进行简单的配置，不用重新编译就可实现不同数据库的部署工作！
抽象工厂三层架构的优势：
1）抽象工厂可以给系统带来更大的可扩展性和尽量少的修改量。最大的好处就是，我们在添加产品的时候只需要添加具体的产品类和“工厂类”，而不用修改原来的代码。
2）只要设计合理，规范了各个层次的接口方法，三层式架构的设计完全可以分离开由不同的开发人员同时开发，这就可以有效地利用开发资源，缩短项目开发周期。
3）降低各层之间的耦合，使项目结构更清楚，分工更明确，有利于后期的维护和升级；多数是为了方便自己更改，维护和扩展
总之，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话，学会了抽象工厂模式，你将理解OOP的精华：面向接口编程。
三、权限设置和三层架构中的业务逻辑层
现在不管什么系统几乎都和权限有关联，一般网站、论坛都有会员制，只有特定用户采用特殊的操作。企业权限管理设计用得较多的是基于角色的权限管理（资料参见http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/sjk/2007/0608/28036.html）。
基于权限的表设计不是很复杂，复杂的是多对多的关系！常常和业务逻辑关联，比如说某学校的教务系统，某些人在特定时间有特定操作<该特殊权限需要用户定制>。
设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。其实粗粒度就是该系统有who+what+how的问题，即某种用户+对某个按钮（资源)+点击/(操作)的问题，细粒度是业务逻辑解决,即某种用户+在某段时间(业务逻辑层)+对某个按钮（资源)+点击/(操作)的问题。
基于角色权限表设计可参考http://www.iteye.com/topic/930648
他的表结构设计还挺好，基于觉得的权限中心当然是角色，所有的权限设置都是通过角色来设定的，不过个人亲身实践觉得在角色在增加一个角色类型表，以便定制不同角色的菜单树、权限树！
三层架构：参考http://www.doc88.com/p-410726446970.html
三层抽象工厂模式：参考 http://www.cnblogs.com/cbf4life/archive/2009/12/23/1630612.html
基于角色权限管理（数据库）表设计：参考http://www.iteye.com/topic/930648