实际PetShop4是三层扩展出来的，用七层模拟做了两个小
项目，实际和三层没区别，只是多了反射和接口。但是项目强壮了很多，可以顺利过渡任意数据库 可以灵活切换数据库不改源码，很好的实现了OCP原则，至于上层换BS或换CS 分三层就能够灵活实现，所以对七层的理解很重要.
所以我上面说能把三层讲清楚就不容易了...
factory和ioc是什么？请去查清楚概念再想想它们和分层的关系...
分层是一种工程方法并非开发技术...
举个不太恰当的例子：
我现在穿T恤+牛仔裤+休闲鞋，当然我还穿内裤和袜子，然而所有人都知道我这身装扮的架构是上衣+裤子+鞋...没有人会拿自己的内裤出来炫耀...
天气再冷一些我会再加外套，更冷的时候我会再加保暖内衣...需求变化了，然而它的架构依然是上衣+裤子+鞋...
如果我去寒冷的北方会再加毛衣和大衣鞋子也会换成靴子袜子可能穿两双，如果我去登珠峰我会加更多更专业的御寒装备，需求变化导致我扩展我的架构...然而它的架构依然是上衣+裤子+鞋...不管我穿了多少条裤子它们只有一个功能——保护我的下肢——我认为它们是一个层次的东西...
其实我感觉在分层的意义上,可能各个人对层的深浅不同，所以出来的层也不同吧.
如果:
裤子 = 保护下肢
裤子+鞋 = 保护下肢
上衣+裤子+鞋+ 两双袜子 = 保护下肢
如果说以上三个选择是一个层次的东西,那退一步来看,穿着的基本功能都是为了保暖的,上衣+裤子+鞋是不是可以看成是一层(因为功能一致)呢?
分层的概念:分层表示将功能进行有序的分组.
我觉得当鞋或袜子加入时,它们的功能与裤子是不同的,于是,将他们的功能进行分组是可以出新的"层的",这样分层有多了一层.
我觉得架构和分层还是有区别的.
工程方法是从实践中来到实践中去，是为了解决实际问题的...
化繁为简见功夫...化简就繁是庸才...
逻辑层和物理层不是一回事，一个项目只是一个物理上的概念，不是逻辑上的。
分层的目的
为了多人开发方便
1 开发 个人开发，我想怎么开发怎么开发，那是我的问题,分不分层无所谓的事情
多人协作开发
一人开发一个模块，各不相干的开发,那么模块之间的调用肯定是接口最恰当了
2 布署
布署你把bll.dll和model.dll放到二个服务器上.这，显然不恰当 ,那么分布式布署也仅仅是说web服务器和数据服务器不在同一服务器上
3 维护
如果bll出了问题那么我们更新一个bll然后再上传这个dll，显示是很方便的
事实上,就面对对像来说如果某一类某一方法出了问题,一般的解决方法是重写子类或是再继承一个类重写掉 这样不会影响其它类， 这就要求我们在开发时候一定要规化好类层次
事实上,分层主要是分类的层次,主要是为了方便维护和管理
一个程序员写出来的程序不能扩展，不能改良，这个程序员只能是代码工人啊， 苦口婆心，绝对没有伤人的意思。 可以看看一些分层的开源项目，对自己绝对没有损失。
并不是每个系统都要分层，一般只针对一些大型系统才采用分层，你看PetShop4，总共有22个项目。
大体思想是3层，从Model,DAL,BLL，
然后他在各层上又采用了工厂模式，把逻辑与实现想分离，比如以前BLL直接调用DAL就好了，
但现在BLL却调用了IDAL,IDAL只是一个接口层，里面封状了要完成的一些业务逻辑，
而具体的实现则交给DAL去实现，
然后借助于工厂模式DALFactory和映射完成IDAL层中类的实例化。
这样不管我们用的底层用的是什么数据库都可以完成BLL对DAL的调用。
另外，从分层角度来看，你的分层至少也不标准。
首先你不应该将那些SQL语句放在BLL层中，而应该是由DAL层来完成和数据库的交互。
要想研究分层模式，PetShop4的确是一个相当好的例子，值得学习。
在.NET中 DAL+IDAL+Model+BLL+Web是什么意思
业务逻辑层(BLL)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理。如果说数据层是积木，那逻辑层就是对这些积木的搭建。
数据访问层(DAL)：主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务。
(IDAL)它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL
(Model)实体和数据库表映射类
（Web）web网站项目
1.兵无常势，水无常形
2.吾常闻拙速，未尝闻巧以久也
3.运用之妙，存乎一心
形式真有那么重要吗？？世人皆称 二万五千里长征是奇迹，但这个奇迹是一个无奈的奇迹，是需求和条件决定的，你会无缘无故的去做二万五千里长征吗？？
三层开发
我想到我以前对其的理解 也只是数据,逻辑,表现
但如何区分它们,实在太难
后来,对其深入的思考 数据层 不过是从数据库取出数据,
逻辑层是逻辑的实现功能,表现 就是 呈现出来.
有一个方法区分用多少 就是上楼模型.
你必须从一楼一楼上,不可跨越任何一层.
如:当你从一楼到二楼,不论你走那个楼梯,都可以到二楼,
这些楼梯可以看作一层.
分层是工程方法...
设计模式也是工程方法...
工程方法的最终目的不是技术层面的东西而是TCO...从纯技术的角度去理解分层永远都是纸上谈兵...
我写过七层的模块,有过两次,
我们大部分开始构架的时候是五层,然后再整理分析七层就出来了,
没有什么乱的啊,感觉很好,方便调用.不像楼上有些人说的那样[把问题复杂化了].
项目较大的,我想七层是最好的选择了.
三层
UI层
逻辑层
数据层
已经很经典了,当然不是我说了,但是里面还是可以继续分的,主要是为了开发便利.
7层没什么,很正常. 只是楼主没真理解7层,实际上所谓7层还是3层!! 无非是分的更详细些,比如提供了接口层,实体层(参数数组)等等
七层是正确的，这帖子讨论的时候我还没开始分析PetShop。
实际PetShop是三层扩展出来的，用七层模拟做了两个小项目，实际和三层没区别，只是多了反射和接口。但是项目强壮了很多，可以顺利过渡任意数据库 可以灵活切换数据库不改源码，很好的实现了OCP原则，至于上层换BS或换CS 分三层就能够灵活实现，所以对七层的理解很重要，如果鄙视技术思想还做技术做什么，不用就不用，用不着站着说话不腰痛。
factory 独立出来 主要是为了直观，分七层 如果接口和方法都定义好后，任何一个有基础的程序员都可以参与大型项目。 项目风险降低很多，节约很多时间。
层，无所谓有，无所谓无
层在心中，层的最高境界是 无层
---DBUtility数据层基类
---DALFactory数据层工厂类
---IDAL接口层
---SQLDAL接口实现层
---Model实体类
---Logic业务逻辑层
---Web表示层
