选择框架，并不是要简化开发过程，虽然有时确实提高了开发速度。但这种提升多是由于框架的基本结构在所有的应用里都差不多，节省了设计的时间，可以直接开始配置系统大环境。同时框架的管理层面已经是非常成熟的，不需要我们再做过多的考虑。
其实框架的应用和流行和MVC设计理念息息相关，而MVC本身不是为了简化什么，而是为了规范什么。如果你对MVC都不认可的话，那我们就没必要再谈论框架了。
有些人说，很多方法都比使用框架要灵活方便简捷很多。但是，这种开发是不是放弃了对系统的设计理念，回到了MVC之前，仅仅为了实现而编程。在没有MVC的日子里，系统的维护、扩展、安全以及稳定都是随时可以威胁系统生命的大问题。而现在，分层的设计理念大大提高了开发的效率，并且规避了不少的bug。我认为MVC和框架的出现是程序开发领域的一个进步。尽管现在还没有一个完美的框架，但框架的出现打开了编程的新纪元，我们应该积极地学习、掌握它。
很多人一提及框架就是SSH，其实这只是一种比较流行的组合而已，但你可以单用其中任何一个，这也是框架的使用（我觉得Spring是最有用的）。使用框架不过是对MVC一个规范的体现，通过使用框架，你的工程自然而然就分离各层，达到了高效先进的设计理念。
首先，开发效率：软件工程是个特殊的行业，不同于传统的工业，例如电器、建筑及汽车等行业。这些行业的产品一旦开发出来，交付用户使用后将很少需要后续的维护。但软件行业不同，软件产品的后期运行维护是个巨大的工程。如果不使用框架分层，将整个站点的业务逻辑和表现逻辑都混杂页面里，从而导致页面的可读性相当差，可维护性非常低。即使需要简单改变页面的按钮，也不得不打开页面文件，冒着破坏系统的风险。但采用严格分层框架，则可完全避免这个问题。对表现层的修改即使发生错误，也绝对不会将错误扩展到业务逻辑层，更不会影响持久层。因此，采用框架，即使前期的开发效率稍微低一点，但也是值得的。
其次，需求的变更：几乎很少有软件产品的需求从一开始就完全是固定的。客户对软件需求，是随着软件开发过程的深入，不断明晰起来的。因此，常常遇到软件开发到一定程度时，由于客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现需要改变时，是否可以尽可能减少修改、少改变软件的实现，从而满足需求的变更？答案是肯定的，采用优秀的解耦架构。在优秀的分层架构里，控制层依赖于业务逻辑层，但绝不与任何具体的业务逻辑组件耦合，只与接口耦合；同样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即使软件的部分发生改变，其他部分也尽可能不要改变。
对于技术的更新，系统重构：软件行业的技术更新很快，一旦环境变化，不得不更换技术时，如何保证系统的改变最小呢？答案肯定是选择优秀的框架。