。。。。。
32 个解决方案
#1
就是不分层也可以实现一个企业级的项目
为什么要分层呢？因为可以加速开发速度及维护
也没有非要分为七层，还是看技术储备和项目大小
为什么要分层呢？因为可以加速开发速度及维护
也没有非要分为七层，还是看技术储备和项目大小
#2
好像没有讨论的价值。
7层只是工程化的结果，他不代表啥，只是代表一种施工工艺
就像喝茶，你可以一杯水，一个杯子，几两茶叶，泡了就喝。
也可以学习茶道，先洗手，正心，焚香，烧水，泡茶，洗茶（泡第一道茶不喝直接倒掉）------------
实际没区别，茶终究是要喝的，茶道本身也就是一个规定（用规定来体现意境），你遵不遵守规定和喝茶本身并没直接关系
7层只是工程化的结果，他不代表啥，只是代表一种施工工艺
就像喝茶，你可以一杯水，一个杯子，几两茶叶，泡了就喝。
也可以学习茶道，先洗手，正心，焚香，烧水，泡茶，洗茶（泡第一道茶不喝直接倒掉）------------
实际没区别，茶终究是要喝的，茶道本身也就是一个规定（用规定来体现意境），你遵不遵守规定和喝茶本身并没直接关系
#3
呵呵，兄弟来这里了阿，例子举得不错！
#4
GOOD THANKS
#5
我想下载你的框架，但没有分了啊
#6
层次不是越多越好的，根据项目的实际需要
基本还是三层
基本还是三层
#7
我以前经常用“竖井思维”来说一些假的分层策略，这样各个层紧耦合，痛苦和繁琐，分层还不如不分。
#8
别把自己框死在层数上。。。
#9
没有好的分层，只有适合的分层，要看项目
#10
楼上几位说的很在理,小弟也来学习学习.
#11
凡是揪住7层不放的，都是不明白分层方法...
#12
一直没有时间写，等有时间先把7层架构介绍下。
#13
2楼的兄弟，比喻不错，很有文学功底，你应该转做文职工作的
呵呵
呵呵
#14
真有才，写七层。我赞同九楼的观点，没有好的分层，只有适合的分层，关键是要项目需不需要去那样做。
#15
分层就是分工与协作
物理分层（分工）：按代码职责划分，目的是重用代码，提高效率，很显然，代码被分的越细越好。我们把最底层的代码称为原子代码，然后一层层收集分类，这样在不同的粒度上都是按强内聚原则装配的，所以物理分层的数量并不固定，最典型的物理就是：BLL、DAL、MODEL。论坛里很多人的思想仅仅停留在物理层面，物理分层是基础工作，或者说是比较原始的代码策略。物理分层不负责降低耦合，相反，往往把代码之间的关系搞得像一团乱麻，整个架构经不起一点风吹草动。
逻辑分层（协作）：为了解决物理分层带来的副作用，按依赖或驱动关系划分，为了更好理解这种关系，我们可以把它称作：分级。很显然，层级越少越好，目的是降低耦合，比较理想的逻辑分层是星星结构或者说总线结构，最典型的逻辑分层就是：MVC，逻辑上就是2级，而且与物理分层的原则类似，在不同的粒度上，都是可以做到2级的，比如ASP.NET MVC就是解决UI的，你也可以在全局上MVC：程序代码和数据库是V，项目模型就是M，开发工具（通常指团队自主的开发工具）或者将M转换成V的手段就是C，所以如果你能这样看待开发全局，就会意识到数据库驱动的开发是多么的不妥了。总之代码之间的逻辑层级关系越简单越好。
其实，最好的理论教材在我们身边无处不在，别的不说，就是我们天天使用的电脑，软件开发的最深刻理论就在里面了，随便举个例子：V：显示器、打印机等输出设备，它们是数据无关的（它们不知道要呈现什么东西）、领域相关的（比如分辨率不同、用途不同），它们并不知道M的存在，他们仅提供接口供C（主板）使用。
需要强调的是，分层在开发全局中只是相对简单的工作（V），最重要的工作是如何转换（C），通过这一步才能控制代码量极限和迭代极限，细节另作探讨。
最后要说：分层是一种实践技能，就像学驾驶一样，没有人上完理论课就学会开车的，对于没有经验的开发者，都要通过不断实践、走弯路、甚至碰壁才能悟出其中的道理。
物理分层（分工）：按代码职责划分，目的是重用代码，提高效率，很显然，代码被分的越细越好。我们把最底层的代码称为原子代码，然后一层层收集分类，这样在不同的粒度上都是按强内聚原则装配的，所以物理分层的数量并不固定，最典型的物理就是：BLL、DAL、MODEL。论坛里很多人的思想仅仅停留在物理层面，物理分层是基础工作，或者说是比较原始的代码策略。物理分层不负责降低耦合，相反，往往把代码之间的关系搞得像一团乱麻，整个架构经不起一点风吹草动。
逻辑分层（协作）：为了解决物理分层带来的副作用，按依赖或驱动关系划分，为了更好理解这种关系，我们可以把它称作：分级。很显然，层级越少越好，目的是降低耦合，比较理想的逻辑分层是星星结构或者说总线结构，最典型的逻辑分层就是：MVC，逻辑上就是2级，而且与物理分层的原则类似，在不同的粒度上，都是可以做到2级的，比如ASP.NET MVC就是解决UI的，你也可以在全局上MVC：程序代码和数据库是V，项目模型就是M，开发工具（通常指团队自主的开发工具）或者将M转换成V的手段就是C，所以如果你能这样看待开发全局，就会意识到数据库驱动的开发是多么的不妥了。总之代码之间的逻辑层级关系越简单越好。
其实，最好的理论教材在我们身边无处不在，别的不说，就是我们天天使用的电脑，软件开发的最深刻理论就在里面了，随便举个例子：V：显示器、打印机等输出设备，它们是数据无关的（它们不知道要呈现什么东西）、领域相关的（比如分辨率不同、用途不同），它们并不知道M的存在，他们仅提供接口供C（主板）使用。
需要强调的是，分层在开发全局中只是相对简单的工作（V），最重要的工作是如何转换（C），通过这一步才能控制代码量极限和迭代极限，细节另作探讨。
最后要说：分层是一种实践技能，就像学驾驶一样，没有人上完理论课就学会开车的，对于没有经验的开发者，都要通过不断实践、走弯路、甚至碰壁才能悟出其中的道理。
#16
勘误：星星结构
更正：星形结构
更正：星形结构
#17
厉害，我一般用三层......
#18
东西是死的、人是活的
#19
先转载一篇7层架构的介绍文章：
------------------------------------------------------------------------------
表示层-代理层-外观层-业务规则层-数据访问层-实体层-数据库
------------------------------------------------------------------------------
一般的，信息系统有七成结构：
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界面为桌面应用系统。
【原文地址：http://blog.csdn.net/yslhome/archive/2005/09/09/475700.aspx】
------------------------------------------------------------------------------
表示层-代理层-外观层-业务规则层-数据访问层-实体层-数据库
------------------------------------------------------------------------------
一般的，信息系统有七成结构：
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界面为桌面应用系统。
【原文地址：http://blog.csdn.net/yslhome/archive/2005/09/09/475700.aspx】
#20
7层架构缩减的方案：
首先就是进行概念上的归类，
6。Web界面
7。Windows界面
------这是属于UI层的东西；
3。数据访问
4。系统框架
5。Web服务
-------这是属于系统框架和服务层，可以归为一类；
1。业务外观
2。业务规则
-------这个不用说，自然属于业务层，归为一类。
对于很多人说的数据访问这个功能，都把他再分为DAL，IDAL，DALFactory三个层次，这是完全没有必要的，再怎么分，也是属于数据访问的功能，这样分仅仅是为了跨数据库访问。
现在，很多ORM框架，比如Entity Framework，它直接就可以支持不同的数据库，没有必要再细分几个层了。所以，现在的项目开发，一般来说就是“三层架构”+ORM框架即可。
PDF.NET框架
http://blog.csdn.net/bluedoctor/archive/2010/01/24/5251913.aspx
实际上就是一个简单的ORM框架，它还有一套支持工具，帮助完成DAL层代码的编写和Model组件的编写，使得传统多层开发变得更加简单高效！
首先就是进行概念上的归类，
6。Web界面
7。Windows界面
------这是属于UI层的东西；
3。数据访问
4。系统框架
5。Web服务
-------这是属于系统框架和服务层，可以归为一类；
1。业务外观
2。业务规则
-------这个不用说，自然属于业务层，归为一类。
对于很多人说的数据访问这个功能，都把他再分为DAL，IDAL，DALFactory三个层次，这是完全没有必要的，再怎么分，也是属于数据访问的功能，这样分仅仅是为了跨数据库访问。
现在，很多ORM框架，比如Entity Framework，它直接就可以支持不同的数据库，没有必要再细分几个层了。所以，现在的项目开发，一般来说就是“三层架构”+ORM框架即可。
PDF.NET框架
http://blog.csdn.net/bluedoctor/archive/2010/01/24/5251913.aspx
实际上就是一个简单的ORM框架，它还有一套支持工具，帮助完成DAL层代码的编写和Model组件的编写，使得传统多层开发变得更加简单高效！
#21
7。。。。层
#22
菜鸟，来学习学习了！
#23
现在觉得，有个大牛说的“三层架构+ORM框架即可”的确如此，我们不能把问题复杂化啊。
#24
该回复于2010-04-14 13:53:36被版主删除
#25
该回复于2010-04-14 16:15:06被版主删除
#26
该回复于2010-04-15 09:02:13被版主删除
#27
赞同2楼的
#28
还有人顶就结帖了。
#29
路过，打打酱油
#30
需要分几层要根据实际项目的功能来确定，过多的分层不一定就适合
#31
说的都挺对的，哈哈
#32
结贴送分！
#1
就是不分层也可以实现一个企业级的项目
为什么要分层呢？因为可以加速开发速度及维护
也没有非要分为七层，还是看技术储备和项目大小
为什么要分层呢？因为可以加速开发速度及维护
也没有非要分为七层，还是看技术储备和项目大小
#2
好像没有讨论的价值。
7层只是工程化的结果，他不代表啥，只是代表一种施工工艺
就像喝茶，你可以一杯水，一个杯子，几两茶叶，泡了就喝。
也可以学习茶道，先洗手，正心，焚香，烧水，泡茶，洗茶（泡第一道茶不喝直接倒掉）------------
实际没区别，茶终究是要喝的，茶道本身也就是一个规定（用规定来体现意境），你遵不遵守规定和喝茶本身并没直接关系
7层只是工程化的结果，他不代表啥，只是代表一种施工工艺
就像喝茶，你可以一杯水，一个杯子，几两茶叶，泡了就喝。
也可以学习茶道，先洗手，正心，焚香，烧水，泡茶，洗茶（泡第一道茶不喝直接倒掉）------------
实际没区别，茶终究是要喝的，茶道本身也就是一个规定（用规定来体现意境），你遵不遵守规定和喝茶本身并没直接关系
#3
呵呵，兄弟来这里了阿，例子举得不错！
#4
GOOD THANKS
#5
我想下载你的框架，但没有分了啊
#6
层次不是越多越好的，根据项目的实际需要
基本还是三层
基本还是三层
#7
我以前经常用“竖井思维”来说一些假的分层策略，这样各个层紧耦合，痛苦和繁琐，分层还不如不分。
#8
别把自己框死在层数上。。。
#9
没有好的分层，只有适合的分层，要看项目
#10
楼上几位说的很在理,小弟也来学习学习.
#11
凡是揪住7层不放的，都是不明白分层方法...
#12
一直没有时间写，等有时间先把7层架构介绍下。
#13
2楼的兄弟，比喻不错，很有文学功底，你应该转做文职工作的
呵呵
呵呵
#14
真有才，写七层。我赞同九楼的观点，没有好的分层，只有适合的分层，关键是要项目需不需要去那样做。
#15
分层就是分工与协作
物理分层（分工）：按代码职责划分，目的是重用代码，提高效率，很显然，代码被分的越细越好。我们把最底层的代码称为原子代码，然后一层层收集分类，这样在不同的粒度上都是按强内聚原则装配的，所以物理分层的数量并不固定，最典型的物理就是：BLL、DAL、MODEL。论坛里很多人的思想仅仅停留在物理层面，物理分层是基础工作，或者说是比较原始的代码策略。物理分层不负责降低耦合，相反，往往把代码之间的关系搞得像一团乱麻，整个架构经不起一点风吹草动。
逻辑分层（协作）：为了解决物理分层带来的副作用，按依赖或驱动关系划分，为了更好理解这种关系，我们可以把它称作：分级。很显然，层级越少越好，目的是降低耦合，比较理想的逻辑分层是星星结构或者说总线结构，最典型的逻辑分层就是：MVC，逻辑上就是2级，而且与物理分层的原则类似，在不同的粒度上，都是可以做到2级的，比如ASP.NET MVC就是解决UI的，你也可以在全局上MVC：程序代码和数据库是V，项目模型就是M，开发工具（通常指团队自主的开发工具）或者将M转换成V的手段就是C，所以如果你能这样看待开发全局，就会意识到数据库驱动的开发是多么的不妥了。总之代码之间的逻辑层级关系越简单越好。
其实，最好的理论教材在我们身边无处不在，别的不说，就是我们天天使用的电脑，软件开发的最深刻理论就在里面了，随便举个例子：V：显示器、打印机等输出设备，它们是数据无关的（它们不知道要呈现什么东西）、领域相关的（比如分辨率不同、用途不同），它们并不知道M的存在，他们仅提供接口供C（主板）使用。
需要强调的是，分层在开发全局中只是相对简单的工作（V），最重要的工作是如何转换（C），通过这一步才能控制代码量极限和迭代极限，细节另作探讨。
最后要说：分层是一种实践技能，就像学驾驶一样，没有人上完理论课就学会开车的，对于没有经验的开发者，都要通过不断实践、走弯路、甚至碰壁才能悟出其中的道理。
物理分层（分工）：按代码职责划分，目的是重用代码，提高效率，很显然，代码被分的越细越好。我们把最底层的代码称为原子代码，然后一层层收集分类，这样在不同的粒度上都是按强内聚原则装配的，所以物理分层的数量并不固定，最典型的物理就是：BLL、DAL、MODEL。论坛里很多人的思想仅仅停留在物理层面，物理分层是基础工作，或者说是比较原始的代码策略。物理分层不负责降低耦合，相反，往往把代码之间的关系搞得像一团乱麻，整个架构经不起一点风吹草动。
逻辑分层（协作）：为了解决物理分层带来的副作用，按依赖或驱动关系划分，为了更好理解这种关系，我们可以把它称作：分级。很显然，层级越少越好，目的是降低耦合，比较理想的逻辑分层是星星结构或者说总线结构，最典型的逻辑分层就是：MVC，逻辑上就是2级，而且与物理分层的原则类似，在不同的粒度上，都是可以做到2级的，比如ASP.NET MVC就是解决UI的，你也可以在全局上MVC：程序代码和数据库是V，项目模型就是M，开发工具（通常指团队自主的开发工具）或者将M转换成V的手段就是C，所以如果你能这样看待开发全局，就会意识到数据库驱动的开发是多么的不妥了。总之代码之间的逻辑层级关系越简单越好。
其实，最好的理论教材在我们身边无处不在，别的不说，就是我们天天使用的电脑，软件开发的最深刻理论就在里面了，随便举个例子：V：显示器、打印机等输出设备，它们是数据无关的（它们不知道要呈现什么东西）、领域相关的（比如分辨率不同、用途不同），它们并不知道M的存在，他们仅提供接口供C（主板）使用。
需要强调的是，分层在开发全局中只是相对简单的工作（V），最重要的工作是如何转换（C），通过这一步才能控制代码量极限和迭代极限，细节另作探讨。
最后要说：分层是一种实践技能，就像学驾驶一样，没有人上完理论课就学会开车的，对于没有经验的开发者，都要通过不断实践、走弯路、甚至碰壁才能悟出其中的道理。
#16
勘误：星星结构
更正：星形结构
更正：星形结构
#17
厉害，我一般用三层......
#18
东西是死的、人是活的
#19
先转载一篇7层架构的介绍文章：
------------------------------------------------------------------------------
表示层-代理层-外观层-业务规则层-数据访问层-实体层-数据库
------------------------------------------------------------------------------
一般的，信息系统有七成结构：
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界面为桌面应用系统。
【原文地址：http://blog.csdn.net/yslhome/archive/2005/09/09/475700.aspx】
------------------------------------------------------------------------------
表示层-代理层-外观层-业务规则层-数据访问层-实体层-数据库
------------------------------------------------------------------------------
一般的，信息系统有七成结构：
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界面为桌面应用系统。
【原文地址：http://blog.csdn.net/yslhome/archive/2005/09/09/475700.aspx】
#20
7层架构缩减的方案：
首先就是进行概念上的归类，
6。Web界面
7。Windows界面
------这是属于UI层的东西；
3。数据访问
4。系统框架
5。Web服务
-------这是属于系统框架和服务层，可以归为一类；
1。业务外观
2。业务规则
-------这个不用说，自然属于业务层，归为一类。
对于很多人说的数据访问这个功能，都把他再分为DAL，IDAL，DALFactory三个层次，这是完全没有必要的，再怎么分，也是属于数据访问的功能，这样分仅仅是为了跨数据库访问。
现在，很多ORM框架，比如Entity Framework，它直接就可以支持不同的数据库，没有必要再细分几个层了。所以，现在的项目开发，一般来说就是“三层架构”+ORM框架即可。
PDF.NET框架
http://blog.csdn.net/bluedoctor/archive/2010/01/24/5251913.aspx
实际上就是一个简单的ORM框架，它还有一套支持工具，帮助完成DAL层代码的编写和Model组件的编写，使得传统多层开发变得更加简单高效！
首先就是进行概念上的归类，
6。Web界面
7。Windows界面
------这是属于UI层的东西；
3。数据访问
4。系统框架
5。Web服务
-------这是属于系统框架和服务层，可以归为一类；
1。业务外观
2。业务规则
-------这个不用说，自然属于业务层，归为一类。
对于很多人说的数据访问这个功能，都把他再分为DAL，IDAL，DALFactory三个层次，这是完全没有必要的，再怎么分，也是属于数据访问的功能，这样分仅仅是为了跨数据库访问。
现在，很多ORM框架，比如Entity Framework，它直接就可以支持不同的数据库，没有必要再细分几个层了。所以，现在的项目开发，一般来说就是“三层架构”+ORM框架即可。
PDF.NET框架
http://blog.csdn.net/bluedoctor/archive/2010/01/24/5251913.aspx
实际上就是一个简单的ORM框架，它还有一套支持工具，帮助完成DAL层代码的编写和Model组件的编写，使得传统多层开发变得更加简单高效！
#21
7。。。。层
#22
菜鸟，来学习学习了！
#23
现在觉得，有个大牛说的“三层架构+ORM框架即可”的确如此，我们不能把问题复杂化啊。
#24
该回复于2010-04-14 13:53:36被版主删除
#25
该回复于2010-04-14 16:15:06被版主删除
#26
该回复于2010-04-15 09:02:13被版主删除
#27
赞同2楼的
#28
还有人顶就结帖了。
#29
路过，打打酱油
#30
需要分几层要根据实际项目的功能来确定，过多的分层不一定就适合
#31
说的都挺对的，哈哈
#32
结贴送分！