N层架构的一些评论
层次不是越多越好的，而是视乎项目的实际需要，这一点要明确；
常用的3层结构就是：数据访问层、业务逻辑层、UI层
而项目可能有更多的需要，
例如一个项目用了Web Service，那么业务逻辑层和UI层之间就会多了一层；
如果用的是Remoting，那么业务逻辑层与UI层之间就有Remoting代理和Remoting服务两层；
如果项目比较大，复杂度很高，那么业务逻辑层内部如果缺乏规划也会变得混乱，那么视乎实际的需要就会把它划分为2~3层；如果项目并发量很大，需要分布式技术，那么层次又要加......
个人认为，在把项目架构理解的比较透彻之前，迷信所谓的n层结构其实意义不大----而仅仅能够作为参考
尤其是在.net平台下
------------------------------------------------------------------------------
数据库，数据访问层，实体和数据转换存储层，业务逻辑层（facade），纯实体层，web层，6层够用了，实在不行，再加事务处理，验证处理层等等。。。
------------------------------------------------------------------------------
表示层-代理层-外观层-业务规则层-数据访问层-实体层-数据库
------------------------------------------------------------------------------
一般的，信息系统有七成结构：
1、用户层：用户面向对象操作
2、业务层：信息系统业务模型
3、功能层：信息系统功能模型
4、数据层：信息系统数据模型
5、工具层：信息系统开发工具
6、OS层： 网络操作系统
7、物理层：网络与通信硬件
一般而言,用户在第1、2层上工作,程序员在第3层上工作,信息系统分析员在第4层上工作,DBA与系统管理员在第5、6层上工作,硬件安装与维护人员在第7层上工作。上述七层的相互关系是:下一层是上一层的基础,上一层是下一层的实现目标。由上向下是系统分析的过程,而由下向上是系统实现的过程。
------------------------------------------------------------------------------
所谓七层指的是：
1。业务外观
2。业务规则
3。数据访问
4。系统框架
5。Web服务
6。Web界面
7。Windows界面
等七个层面，个人认为，不同的项目依据各自的特点只要对相应的层面进行裁减，就能得出符合各个项目的特点的系统组织框架。
比如：
含有以上各个层面的为分布式应用系统的，
含有业务外观，业务规则，数据访问，系统框架，Web服务为Web服务器
含有业务外观，业务规则，数据访问，系统框架，Windows界面为桌面应用系统。
关键是要适当的剪裁
------------------------------------------------------------------------------
微软这个七层架构害了很多人啊。
其实不管七层还是三层，其基本思想是一致的，就是界面和业务逻辑分开，业务逻辑和数据访问分开。
外观层是干什么的呢，我理解就是你在做一个业务的时候，可能要与很多个业务逻辑层的对象打交道，这样如果需要的类很多的话就有点凌乱，而“外观”指的是什么的外观呢？就是某个业务（或某些相关业务）的外界能看到的面貌，我并不关心你用了多少类来实现这个业务，我只想通过这个窗口实现我的业务。就像现在的政务大厅，我去办事的时候把文件交到一个窗口，具体里面是怎么操作，都是谁来操作我并不关心，到时间取结果就是了。而没有外观模式的话我是不是就得拿着文件到处找人，到处盖章了。
------------------------------------------------------------------------------
优质内容筛选与推荐>>1、输入框字符限制插件·
2、我的runtime理解和用法
3、Django Rest Framework
4、Web在线报表设计器使用指南
5、flask入门 七行代码讲解