对于mvc所针对 要解决的问题 而言，目前来讲，从面向对象的角度（也就是从可复用，可扩展和灵活性角度）出发mvc应该是最佳选择。
第一：mvc针对的问题要素是：1、用户需要输入，2、然后系统要对用户输入作出反应，3、这种输入经过处理之后需要显示回馈给用户。这是mvc模式适用的范围，如果待解问题不具备这三个要素，那显然不适合使用MVC，其他模式更适合。
第二、除了具备三要素之外，关键一点在于问题的复杂程度和进化、扩展需要！用不用mvc模式，取决于你的应用的复杂程度和进化需要。1、如果你的应用逻辑简单，并且逻辑稳定，几乎不存在未来发生变更的可能，那么，请不要生硬地使用mvc（不过在现实开发过程中，这种简单固定的情形，除了在某些嵌入式应用中，基本不可能出现）。2、如果你的应用在显示逻辑、控制逻辑和数据逻辑上面存在着独立演化和扩展的可能，那请考虑适度使用MVC模式。3、如果你的多种不同的显示逻辑、控制器逻辑和数据逻辑中存在一致性的抽象可能（当然前提是系统有进化的可能和需要），那么请考虑使用mvc模式。原则上，系统分层的依据，在于系统中是不是存在着可以形成一致抽象可能和必要的子系统，可以依据这一分层的判定原则来考虑是不是需要使用mvc模式。——当然，这种一致的抽象同时应该是对于应用逻辑处理有意义有用的，可开发并且有开发必要的抽象， 一句话，就是有用的抽象而不是为抽象而抽象 （不过从可扩展和灵活性的角度看，抽象往往都是有用的）
web表示层和数据处理开发，mvc当然不是唯一的，除此之外还有pipeline等模式。mvc模式我更愿意看作是一种架构模式，应为这种模式在系统或者子系统中应用，往往是全局性的，这意味着，在mvc的框架下将会有其他各种模式在mvc的辖制下一起协作，共同完成总体的mvc效果。
mvc模式当然会有些缺点，前面朋友讲过的我就不再重复了，只强调一点： mvc模式最大的优点在用对了的时候出现，此时那些所谓的缺点，例如增加复杂度和编码的繁琐性，就会转化为优点，增加了代码的复杂度和繁琐性（例如编码要遵循一定的约定规则，所有的实例都需要继承某一一致的抽象接口），但是简化了逻辑处理的僵化性、模糊性和易错性，所以这是必要的复杂度和繁琐性，等等；最大的缺点在用错了的时候出现，用错了，上面朋友引用的马丁总结的种种缺点才成为真正的缺点，其优缺点的关键在于其所处理的问题适合不适合它处理 ，例如在适合应用pipeline的地方机械地使用了mvc。所以mvc优缺点的问题之关键在于基于mvc的特点进行问题分析！