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

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

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

还有，用了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类开发,是需要一个应用程序服务器开统一管理协调各个客户端的,因为纯分布式的应用程序更难写.