作者：蒋军利 | 来源：互联网 | 2023-05-17 12:59
常听人说：.Net七层架构构建企业平台，功能强大，本人不才，未能理解其含，是不是与我们平时说的二层、三层、四层程序设计是一回事？ 另外，如何构建七层架构。
118 个解决方案
没见过7层的，估计与2、3层的也差不多。
估计是在不同级别的地方，就算一层的吧。如银行系统，在总部算2层，在省行一层，在市行一层，在支行一层，在各储蓄所一层，就这么一层一层下来的吧。
不懂，关注。
层次不是越多越好的，而是视乎项目的实际需要，这一点要明确；
常用的3层结构就是：数据访问层、业务逻辑层、UI层
而项目可能有更多的需要，
例如一个项目用了Web Service，那么业务逻辑层和UI层之间就会多了一层；
如果用的是Remoting，那么业务逻辑层与UI层之间就有Remoting代理和Remoting服务两层；
如果项目比较大，复杂度很高，那么业务逻辑层内部如果缺乏规划也会变得混乱，那么视乎实际的需要就会把它划分为2~3层；如果项目并发量很大，需要分布式技术，那么层次又要加......
个人认为，在把项目架构理解的比较透彻之前，迷信所谓的n层结构其实意义不大----而仅仅能够作为参考
尤其是在.net平台下
我也同意楼上的说法！分的层并不是越多就越好的！就像类的封装一样，要依需要而定。
小弟不才，纯属个人意见。并建有
QQ群：vs.net设计与开发
群号码：9978078
期望各位大侠的加入，共同讨论建模知识和程序的设计开发。
常用的3层结构就是：数据访问层、业务逻辑层、UI层
例如一个项目用了Web Service，那么业务逻辑层和UI层之间就会多了一层；
如果用的是Remoting，那么业务逻辑层与UI层之间就有Remoting代理和Remoting服务两层；
如果项目比较大，复杂度很高，那么业务逻辑层内部如果缺乏规划也会变得混乱，那么视乎实际的需要就会把它划分为2~3层；如果项目并发量很大，需要分布式技术，那么层次又要加......
无非就是针对具体问题而对层次的进一步细化，比如加个数据实体层，有的项目还把很多控件封装起来，方便使用，不过这个只是和UI交互，我觉得不能算一个层来讲，呵呵
数据库，数据访问层，实体和数据转换存储层，业务逻辑层（facade），纯实体层，web层，6层够用了，实在不行，再加事务处理，验证处理层等等。。。
表示层-代理层-外观层-业务规则层-数据访问层-实体层-数据库
7层？我觉得表示层、逻辑层、数据层、就是够了。至于现在所说的那么多中间层，我个人觉得并没有完全脱离逻辑层的范围，纯属个人YY
通常三层就够了，为了方便系统之间的整合会有个业务的中间层。
中间层在。NET下通常以WebServier或Removting实现。
以上也只是个人理解。
我有个同事更误解成，一个解决方案中有多少个项目就是多少层。
常听人说：XXX万层架构构建企业平台，功能强大，本人不才，未能理解其含，是不是与我们平时说的二层、三层、四层程序设计是一回事？ 另外，如何构建七层架构。
ui层,业务外观,业务规则,数据访问,服务层 在这些中间可以加web service 和 remoting
我觉得那只是逻缉上的概念罢了 一般物理上分层大都是三层,如果在这些层中间都加上web services,那可以称得上是N层,不过一般的项目应该没这种需求
agree with appleseeker. 可以参考一下微软的duwamish7示例，麻雀虽小，五脏俱全。
实际上最基本的还是三层，只不过再加上了扩展而已。
数据层，通常只存放数据，也就是数据库。如果这一层加上了什么验证之类的也可以算一层了。
业务层，也就是自定义层，通常我们所编写的处理各种应用的（如查询统计）都属于这一层，如果把在这一层所做的开发也独立分层感觉有点可笑。就好象经理必须通过副经理才管事一样。
客户层，这一层是发往客户端的，可能会实现一些小的应用（如客户端验证），但主要的还是在一个外观上。
以目前的应用结构上来说，无论怎么扩展实际上都是这三层。
三层是概念意义上的，而七层是实现层面上的，如果你搞清楚了七层，你对整体架构就会非常清晰，从而在开发过程中能更从容的分工
三层是概念意义上的，而七层是实现层面上的
----------- 这句话很同意，其实不同的视点而已，最基本的还是3层
层次划分是根据项目的需要而言,以3层为基础,可以根据实际需要自己再细分,这个没有固定的标准.
常听人说：.Net七层架构构建企业平台，功能强大，本人不才，未能理解其含，是不是与我们平时说的二层、三层、四层程序设计是一回事？ 另外，如何构建七层架构。
---------------------------------------------------------------------------------
七成结构就功能强大？？？
荒唐！
一个企业平台，你要去实现它的功能，随便你用什么方法。至于所谓的几层，完全是概念上的东西，你想怎么划分就怎么划分。功能强大与你划分的层次有什么必然的关系？？？
一个企业平台，一个软件系统做好了，如果没有变更的话，那么功能很可能是固定了，你把它的层次划分得越多，功能就会越强？？？荒唐……
构建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界面为桌面应用系统。
关键是要适当的剪裁
4。系统框架
------------------
这个算一层？看不懂。。。
to: starpacific(全世界的细雨落在全世界的草坪)
为啥说web services不是夹在中间的？
小弟是在不明白web services的定位
客户端
业务逻辑
数据库
业务逻辑层不管你怎么去划分都是归于业务逻辑层的实现,所以还是三层结果最切实的说法和做法.
一本书有300页,分为20个小节,5章,3部分,就这么简单
呱呱，路过，路过，呵呵，微软网站上有关于设计基于。NET 的N层架构的应用的指导，至于用多少层，每个层都是什么层是根据项目的需求而定的，做一个小网站的话不必要用什么3层架构吧，做一个多界面的企业应用，可哟用手机，winform,webform，linux,大型机都可以访问数据的程序，你想不分层都不行，你的的的底层数据有的来自MSSQL,有的来自ORACLE，有的来自XML WEB SERIVICE，有的来自ACCESS，你的业务实体需要传递到DCOM层，还要让J2EE使用，你还要把订单用MSMQ传递给第三方程序使用，你想不分层都不行，你的业务层经常改变，你就要实现业务层和其他层的松散耦合，否则你每次改变业务层代码，都要改好多层的代码。。。。。
反正不可能一句话回答“什么样的架构是最好的架构”，“应用程序应该分多少层”这样的问题。
http://blog.csdn.net/thinkingforever/archive/2005/06/27/404173.aspx
分层只不过是门面模型的一种应用而已，层与层之间的分开有利于梳理信息流。同时也有利于分配任务。
但是分层肯定要影响效率了，因为直接传递信息总比通过某些中间对象传递要快一些。但是现在的机器已经不在乎这点效率了（否则JAVA和.NET都死在娘肚子里^_^）
分层一定要有合适的开发思想，不能乱分，要符合业务的逻辑层次，否则维护人员不知所以，这个项目就得自己留着用吧，^_^
小弟愚见
说的是software design 还是 network？呵呵
7层不是必须，但是4~5层一般的项目都有。
如果说不要分层，那基本上就不是什么项目。
分层会给开发人员带来负担，增加开发时间。
为什么要分层，建议提问者想清楚这个问题后，再做决定。
~~~~~~~~~~~~
当然，我个人经验，一般的小项目，分为 UI， Logic(Biz) 两部分。
大项目会在UI与Logic中插入 Facade. 防止复杂的调用一旦模块出现疾病，产生感染(或者成为蝴蝶效应)
项目中不存在 DataAccess，而是使用 SilenceLake ORM 2 作的对象关系映射，一个 entity.Save() 就能够保存，entity.Delete() 就能够删除，查询不用去写 SQL 的时候，DataAccess 没有什么用处了。
我个人觉得层的主要作用就是用来区分系统的逻辑划分的，不可太过迷信，怎么方便合理怎么用才是正道！
http://www.exdevteam.com/blog/more.asp?name=payne&id=56
Dowamish构架分析篇
看来看去还是同意他们的看法:
starpacific,Eddie005
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 