都说三层架构好，那么三层架构有没有缺点呢？

Question

都说三层架构好，那么三层架构有没有缺点呢？今天我们老师让我们思考，我看了很多资料，有点糊涂了。有人说三层简化开发，易于维护，有人说三层反而不易于维护。哪个给个权威的答案，谢谢！还有，用了MVC是不是就不用三层了？

Answer 1

三层架构有很多优点，但也有其缺点：
　　1、降低了系统的性能。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
　　2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
      3、增加了代码量，增加了工作量
至于mvc推荐一篇文章，希望对楼主与所帮助
从三层架构到MVC-MVP

Answer 2

很少有人去思考三层的弊端，但是正如所有事物一样，一样东西有利就有弊，三层也不例外。主要来说是以下几个方面：（1）三层使得替换层变得容易——你可以很方便地将DAL由MySQL实现变成MSSQL实现，但是更改层的功能变得繁琐，你需要修改层接口，以及所有实现这个层的类，如果一个层的接口已经发布，那么可能没有办法“召回”了。（2）多层结构的程序缺乏灵活性。往往导致配置和调试的复杂。一些特殊的技术很难集成到一个固定的架构里面去，或者实现不好。（3）性能问题，多层程序由于调用层次复杂，所以性能会受到一些影响，通常这不是问题，但是在某些情况下却难以接受。（4）滥用三层，不恰当地分层造成代码反而更加难以维护。多层架构对于新手来说难于很快理解，这意味着他们参与进来导致生产效率恶化，不伦不类地分层搞的系统一团混乱。

Answer 3

1.从10几年前,微软的开发工具就支持包括MVC在内的分层开发;
2.没听说过分层开发有缺点的,分层就是分工和协作,这早就详细阐述过了;
3.楼上所有提到分层有缺点的,不能因为不会分层,就归罪于分层

Answer 4

1.谁说分层后数据访问性能降低了?
  难道各位大牛们没有设计过数据访问服务器?不提供增量+分页服务?
  怪不得linq满天飞,什么通用分页满天飞了
2.那是你没有"发明"虚拟的组件去改善其他组件的关系,没有设计好驱动点,搞得的象链条
  面向对象设计中,发现对象是最基本的,重要的,也是起决定作用的是"发明对象"

Answer 5

楼主先把MVC弄清楚它属于哪个范畴，MVC几个字母？

Answer 6

主要是数据可以和VIEW分离。 像JSP就是写在一起的。

Answer 7

很少有人去思考三层的弊端，但是正如所有事物一样，一样东西有利就有弊，三层也不例外。主要来说是以下几个方面：（1）三层使得替换层变得容易——你可以很方便地将DAL由MySQL实现变成MSSQL实现，但是更改层的功能变得繁琐，你需要修改层接口，以及所有实现这个层的类，如果一个层的接口已经发布，那么可能没有办法“召回”了。（2）多层结构的程序缺乏灵活性。往往导致配置和调试的复杂。一些特殊的技术很难集成到一个固定的架构里面去，或者实现不好。（3）性能问题，多层程序由于调用层次复杂，所以性能会受到一些影响，通常这不是问题，但是在某些情况下却难以接受。

Answer 8

帖子很精彩。补充一下我的一点想法：三层架构做界面开发很合适，但归根到底是用于带界面系统开发的。
其所有的计算都源于界面触发，也就是UI触发。而对于一些服务性质、数据驱动的开发不适用，而很多实际工程中可能都需要参杂这种（界面+服务？），所以需要其他的好的方式来组织代码。或者说现在很多的三层架构开发动态界面比较麻烦？ajax我觉得充其量只能说是一种中间方式的补丁。关键是数据变化驱动界面更新如何在这种形式下做到更加敏捷、灵活。各种三层架构也限制了一些功能性控件的集成难度。比如，我是说比如，我开发一个控件/或者说是模块，它跨越了前后台，不但有界面还有后台数据驱动方式。那么如果需要在一个架构中对它进行集成，可能会比较麻烦。而对不同的架构，集成方式会不一样。当然，这也不能完全说是三层架构的缺点，而是目前没有一个相对统一的标准。

Answer 9

如果你将前台界面设计跟系统业务逻辑设计分离，那么自然也就是三层了（至少是三层了）。因为业务逻辑层自动化地处理前台跟系统数据的关联。这时候，你可以针对同一套业务逻辑api接口而开发出几十种前台应用程序，而它们的后台都是同一个。“三层”是指前后台网络架构。而MVC是前台界面程序开发时的最古老的一种分层方式，它表示各种图形控件（比如设计GIS中的各种建筑物）并不依赖于的真实数据，通过编写程序去监听控件与内存数据的双向变化来进行控制（同步）。MVC是指客户端界面程序的开发方法，比如当元件的温度的改变的时候那么所绑定到这个温度数值上的所有界面（颜色、刻度、警报声等等）都应该自动变化。不论是三层还是MVC（这两个都是30几年以上的老古董了，它们产生了许多具体的模式），最终都是为了让交互设计师快速地拼生产出新软件，90%的时间不是在那里写枯燥的代码来创作，而是使用绘图和行为工具来所见即所地立刻就给用户做出产品修改。如果从那些满脑子只考虑后台数据库的人的思路出发，就很难接受这种方式，因为他整天研究的就不是围绕着用户的千变万化的交互操作需求爱好的变化的而是针对自己查询一些数据的sql语句。

Answer 10

lz要根据自己的项目需求来分析是否需要用到三层，没有绝对的好与坏，看lz怎么用

Answer 11

界面不一定是可见的，可以说需求的结果就是界面。ajax与分层没有直接关系，只是因为一般来说它们之间并不互斥，可以成为其实现的一个组成部分。
数据驱动要做到敏捷、灵活确实很复杂，所以我认为下一阶段应该进入界面驱动。分层的基础思想就是独立，它天生就难以与混合模块互相兼容，但是它可以给混合模块提供服务。

Answer 12

不喜欢在客户端还写sql的三层

Answer 13

分层,或许有很多理解吧.
一个系统实现,可能需要多个不同类型的服务器,一个服务器则面向多个客户端,我们构建的程序,
1.如果只在客户端是我们自己写的,其他都是用现成的服务器,这个可能被理解成不分层,也是CS两层的典型模式.
2.如果客户端自己不写,只用IE等浏览器,只写服务端代码,生成浏览器页面,这是典型的BS开发模式,往往被认为是三层.也有说分层是技术的体现,是物理拓普无关,MVC是一种开发模式也算是三层,M V C 各算一层,还有什么数据层 逻辑层 界面层等等各种各样的层次划分. 我也不知道三层程序的真实定义是什么,往往人家说是三层就三层了,通常的看法是有一个应用程序服务器的是三层,否则为两层,好象这样的定义很呆板.   撇开技术上的大大小小分层不说,我们谈论的三层,好象确实是:有一个应用程序服务器的算三层.
这个确实要从需求上去理解, 应用程序服务器是否需要,一些简单程序,不需要应用程序服务器,只要一个数据库来存放数据的话,两层足矣.不过,针对MIS或ERP类开发,是需要一个应用程序服务器开统一管理协调各个客户端的,因为纯分布式的应用程序更难写. 谈两层或三层是否需要,就是谈需求及应用程序服务器的作用.
我说说应用程序服务器的一些特殊作用:
   1.动态升级,需要一个服务器去通知各客户端升级,不然的话,只能是客户端主动检测文件服务或数据库中的设定值是否改变来得知是否升级,这个在某些场合不被认可. 如果是每一个客户端同是也是一个应用服务器的开发方式,则程序只有更复杂难写.
   2.强制中止某个客户端.或者发信息至某客户端去.等客户端的监控管理及通信功能.两层往往只能实现客户端操作日志.
   3.延时执行指令,或批量统一执行指令. 这个指令指的是"MIS系统中的指令",例如: 每天晚上例行检查数据合理性,不合理时,发邮件短信通知或在用户第二天登录时通知. 考勤系统自动收发考勤数据,人事系统指定某人离职时间延时执行. 多个客户端要求同一指令时(如采集现场数据,或生成极费时的报表),指令排队合并执行.
   4.提供对象数据缓存,可以有效提高系统性能. 一些常用的不经常改变的数据,抽象为对象,将由应用服务器统一管理,可提高效率. 例如,企业中固定的科目,部门,物料类别,甚至于一些常用的关系表,放在应用服务器统一管理,当他们修改时,通过应用服务器修改,自动通知客户端关键数据有更改,自动修正.
   5.一些程序,当数据库锁容易产生时,可以改由应用程序服务器排队执行,从而能有效避免并行执行时数据库锁的问题.不过,由于现在数据库的强大,锁问题一般不是问题.但是应用程序服务器还是可以合并这些指令,让数据库只执行一次. 如一个费时的报表,被多个客户端不停地要求执行,此时应用程序服务器可以有效地让所有客户端等待,而且数据库服务器只执行一次,就能将执行结果分发给需要的客户端.这就避免数据库服务器忙死.
   6.与数据库的连接问题. 我们把一些程序说成是伪三层,因为他们的数据还是直接存取数据库,没有通过应用服务器,这个就是仁者见仁的问题了.当然还有一个程序发布时安全性及端口是否能用的问题.是否需要绕过应用程序服务器直取数据,是设计上的问题. 与使用者需求无关.   可以说,只有1.2.3是与需求相关,4.5.6与需求无关,只是实现技术上的问题.
如果你的需求只是单机数据库(或者3用户以内)就可以满足的话,两层肯定够了,三层是多余的.三层不足的地方是需要规划应用程序服务器的作用.当你这个应用程序服务器没起到应有的作用时,就象是脱裤子放屁,多此一举.
   至于说什么面向对象,逻辑,易于管理多人开发之类的,难道不开发应用程序服务器就不易管理了吗? 就不需要多人开发?一个程序内部分多个层这个太正常了,无须多言什么两层三层,N层都是随处可见.

Answer 14

那只能说你不会写，分层的目的是么？分离关注吧？既然分离关注，那么各层之间就不应存在强耦合说白了点，你写的DAO换到另外一个项目能不能原封不动的重用？如果不能那说明你个人技术问题！为什么强调ORM？为什么NH换到哪里都能用？再说你的领域层，以及系统内部划分出来的其他模块，缓存，工厂，FRAMEWORK等等的，你能否重用？如果不能，那说明你分层是乱分的！代码量海了去的不是IF ELSE这样的判断多，而是SQL语句多！