大概是这么一个情况
很多年前，那是一个贫苦的年代，如果我们要使用Java在网页上做一些动态的交互功能。很多人会告诉你一个技术，叫做JSP。在我还对Java非常困惑的时候，就有人告诉我，JSP是个好东西，它可以在HTML代码里面写Java代码来完成逻辑。1.%2.Stringname=request.getParameter("name");3.Stringpassword=request.getParameter("password");4.UserHandleruserHandler=newUserHandler();5.if(userHandler.authenticate(name,password)){6.%7.p恭喜你，登录成功/p8.%9.}else{10.%11.p对不起，登录失败/p12.%13.}14.%作为一张JSP，它可以接收从别的JSP发送过来的登录请求，并进行处理。这样，我们不需要任何额外的配置文件，也不需要任何框架的帮忙，就能完成逻辑。
再后来，出现框架时代进一步发展，人们发现简单的JSP和Servlet已经很难满足人们懒惰的要求了。于是，人们开始试图总结一些公用的Java类，来解决Web开发过程中碰到的问题。这时，横空出世了一个框架，叫做struts。它非常先进地实现了MVC模式，成为了广大程序员的福音。truts的代码示例我就不贴了，网上随便搜搜你可以发现一堆一堆的。在一定程度上，struts能够解决web开发中的职责分配问题，使得显示与逻辑分开。不过在很长一段时间内，使用struts的程序员往往无法分别我们到底需要web框架帮我们做什么，我们到底需要它完成点什么功能？无论是使用JSP，还是使用Struts1，或是Struts2，我们至少都需要一些必须的元素：
数据——Model页面展示——View处理具体业务的场所——Control上面的这些必须出现的元素，在不同的年代，被赋予了不同的表现形式，有的受到时代的束缚，其表现形式非常落后，有的已经不再使用。但是拨开这些外在的表现形式，我们就可以发现，这不就是我们已经熟门熟路的MVC嘛？来看下图在这幅图中，MVC三个框框各司其职，结构清晰明朗。不过认真的你应该发现了这幅图忽略了一个问题，就是数据是动的，数据在View和Control层一旦动起来，就会产生许多的问题：1.数据从View层传递到Control层，如何使得一个个扁平的字符串，转化成一个个生龙活虎的Java对象。2.数据从View层传递到Control层，如何方便的进行数据格式和内容的校验？3.数据从Control层传递到View层，一个个生龙活虎的Java对象，又如何在页面上以各种各样的形式展现出来。4.现在你试图将数据请求从View层发送到Control层，如何才能知道你要调用的究竟是哪个类，哪个方法？一个HTTP的请求，又如何与Control层的Java代码建立起关系来？除此之外，Control层似乎也没有想象中的那么简单，因为它作为一个控制器，至少还需要处理以下的问题：1.作为调用逻辑处理程序的facade门面，如果逻辑处理程序发生了异常，我们该如何处理？2.对于逻辑处理的结果，我们需要做怎么样的处理才能满足丰富的前台展示需要？这一个又一个问题的提出，都基于对MVC的基本概念的挖掘。所以，这些问题都需要我们在写程序的时候去一一解决。说到这里，你感觉到了吗？实际上，框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的。不同的框架，都是为了解决不同的问题，但是对于程序员而言，他们只是jar包而已。框架的优缺点的评论，也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以，千万不要为了学习框架而学习框架，而是要为了解决问题而学习框架，这才是一个程序员的正确学习之道。框架不重要，概念是王道。只要能够深刻理解MVC的概念，框架对你来说，只是一个jar包而已。关于框架思想你有啥想说的留言唠唠赞赏