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

今天我们老师让我们思考，我看了很多资料，有点糊涂了。

有人说三层简化开发，易于维护，有人说三层反而不易于维护。哪个给个权威的答案，谢谢！

还有，用了MVC是不是就不用三层了？

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

主要来说是以下几个方面：

（1）三层使得替换层变得容易——你可以很方便地将DAL由MySQL实现变成MSSQL实现，但是更改层的功能变得繁琐，你需要修改层接口，以及所有实现这个层的类，如果一个层的接口已经发布，那么可能没有办法“召回”了。

（2）多层结构的程序缺乏灵活性。往往导致配置和调试的复杂。一些特殊的技术很难集成到一个固定的架构里面去，或者实现不好。

（3）性能问题，多层程序由于调用层次复杂，所以性能会受到一些影响，通常这不是问题，但是在某些情况下却难以接受。

（4）滥用三层，不恰当地分层造成代码反而更加难以维护。多层架构对于新手来说难于很快理解，这意味着他们参与进来导致生产效率恶化，不伦不类地分层搞的系统一团混乱。
[解决办法]
优点
1、开发人员可以只关注整个结构中的其中某一层
2、可以很容易的用新的实现来替换原有层次的实现
3、可以降低层与层之间的依赖
4、有利于标准化
5、利于各层逻辑的复用。

缺点
1、降低了系统的性能。这是不言而喻的。
如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。 　　
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。
如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
[解决办法]
1.从10几年前,微软的开发工具就支持包括MVC在内的分层开发;
2.没听说过分层开发有缺点的,分层就是分工和协作,这早就详细阐述过了;
3.楼上所有提到分层有缺点的,不能因为不会分层,就归罪于分层
[解决办法]
你没有需求，就看不到需求变化，那么很自然就会断言为缺点。

比如有些小男孩看到女孩比自己少了一个物件，就会认为女人这个就是缺点。但是等长大了，有了需求，就反而知道这是优点了。
[解决办法]
直接造访数据库性能高？比访问缓存还高？要简单高效的管理缓存，最好的实践就是分层(当然这只是我个人经验)。
有时会导致级联的修改？说明分层设计不合理。对于简单一些数据库字段修改，分层结合代码生成甚至还可以实现零代码。
增加了代码量？分层几乎可以做到只关心业务逻辑代码。

数据完整性验证和安全性验证存在相当严重？自己的错不要推给分层，不分层我看也是同样的错。
没有使用异步传输技术的三层架构,可以说非常的烂,无论是性能上？说得太模糊，不知道这个异步传输指的是哪方面？
三层架构很致命的缺点就是数据大量的统计分析，实时的统计分析在三层架构上实践上是不可能的？自己的错不要推给分层，不分层我看也是同样的错。
上面三个问题，简直不知所云。

过度遵循开发框架，会增大项目开发难度？处理独立简单的事务比混合在一些的复杂事务更难处理？
不合理的使用也会导致其后期维护工作繁琐？不合理的使用不是分层的缺点吧？
增加项目开发成本？代码量少，工作量少，反而增加开发成本？
不知道是哪本书这样说，不懂乱说。

多层程序由于调用层次复杂，无非就是几层函数调用，相对于整个流程的开销，可以忽略。
多层往往导致配置和调试的复杂，对于初学者来说，这点倒是真的。

如果你是刚开始开发工作,一点积累都没有,不能把搭建开发基础的工作归罪于分层。
这个说得对，分层是要付出代价的，但是那可以说是一次性的代价。
打个不恰当的比喻，频繁的在一大堆不变的数中是查找数，要用二分法的话是先要排序的，要直接定位需要先建哈希表的。

不说分层架构松耦合带来的好处，分层的优点相对于那些鸡毛蒜皮的所谓的缺点，根本不值一提。
对于大型或稍复杂一点的项目，在代码量、性能、可扩展性、易维护都是明显的优点。
对于小型项目，虽然可扩展、易维护、性能不重要，手工代码量少是它的优点。
因为分层，所以功能独立；因为独立，所以可以更好的抽象；因为抽象简单，所以可以写一次代码到处生成或到处使用。

记住，分层不是为分层而分层，要知道为什么分层。如何不知道为什么分层，那就不要分层了。
当然，这些还是不够的，程序架构是会不断进化的。
我希望下一个阶段进化到由界面驱动代码生成，真正做到只关心业务逻辑。
[解决办法]
就个人开发而言，看到的分层的优点远大于缺点

分层可以让业务逻辑梳理起来更清晰，便于使用统一的缓存机制，完全可以弥补性能上的缺陷

而数据访问层和业务逻辑层的重用，也是其他相关应用程序开发健壮性的保证
[解决办法]
分层,或许有很多理解吧.
一个系统实现,可能需要多个不同类型的服务器,一个服务器则面向多个客户端,我们构建的程序,
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层都是随处可见.