随着应用程序的发展和变化，页面的流动和商业逻辑也增加了。应用程序变得难以维护，因为页面流动逻辑跨多个页面分布，而且商业逻辑可能开始存在于未计划的地方。从Model 1转到MVC的最佳时机就是当这些类型的维护问题出现的时候。
你也可以预先计划将你的应用程序从一个架构移植到另一个架构。当你的应用程序中的JSP页面包含脚本元素，定制标记或JavaScript来执行一个forward()操作时，你可能想调整你最初的设计，变成一种用MVC架构的设计。
Refactoring用在这儿是个不错的术语。它指的是以一种高度严谨的方式重建代码结构的一种技术。当你的代码变得难以理解、修改和调试时，你通常就开始考虑调整了。你可以用几种方式来调整代码：你可以简单地重新命名变量和方法，或者将部分代码移植到不同类型的执行模式中。更多的关于调整及其技术方面的信息，请访问Martin Fowler的网站www.refactoring.com 或者阅读他写的书 Refactoring: Improving the Design of Existing Code。
在许多情况下，一开始就选择MVC架构是很有意义的，例如你的应用程序是为广泛的企业应用而设计的，或者在几年内，你的应用程序可能扩展到一个相当高的流量。 设计一个MVC架构需要有深谋远虑。大多数程序员发现写逻辑脚本或JavaBeans，以及用HTML显示很容易。当你设计一个MVC架构时，你必须首先进行一个完整的设计。这就意味着，分析需要处理的请求的类型，确定哪些组件（JavaBean、数据库或其它servlets）将处理这些请求，以及对那些请求的回应是如何显示给用户的。 该设计的关键就是请求和数据的流动性。为MVC架构设计应用程序组件只是对你现在用JSP和servlets所做工作的扩展。面临的挑战就是构建一个servlet，它接收请求并把那些请求分到应用程序的不同的组件。将一个数据库请求传送到一个数据库，或将一个处理请求传送到一个JavaBean是很容易的，但是如果一个请求包含这两种元素，会怎样呢？或者如果请求的性质在一些处理出现前不能确定，又怎样呢？
Struts 构架
该挑战使我们又回到Struts构架。Struts提供了一个实现MVC架构的高度自动化的方式。它的结构实现了MVC，并包括一个控制器servlet、一组JSP页面和应用程序的商业逻辑。控制器将用户请求打包，并把它们导向架构中的其他对象。
