前端跟服务端之间多了个中间层,前台先提交给中间层,由中间层去访问服务端。
JSP中,“<%……%>”里面的java代码是可以有一些业务逻辑的,而三层架构正是要将业务逻辑从页面中分离出来,因些不要过多的使用“<%……%>”,但根据实际情况,适量的添加一些是可以的。
而MVC实际上其实是一种架构模式,而不应该归入设计模式了,设计模式是在代码层面上说的:类都是什么样子的。
MVC编程模式
比如由html元素组成的网页界面,或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生,它只是作为一种输出数据并允许用户 *** 作的方式。
M即model模型是指模型表示业务规则。在MVC的三个部件中,模型拥有最多的处理任务。被模型返回的数据是中立的,模型与数据格式无关,这样一个模型能为多个视图提供数据,由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性。
以上内容参考:百度百科-mvc框架
MVC是一种目前广泛流行的软件设计模式,早在70年代,IBM就推出了Sanfronscisico项目计划,其实就是MVC设计模式的研究。近来,随着J2EE的成熟,它正在成为在J2EE平台上推荐的一种设计模型,也是广大Java开发者非常感兴趣的设计模型。MVC模式也逐渐在PHP和ColdFusion开发者中运用,并有增长趋势。随着网络应用的快速增加,MVC模式对于Web应用的开发无疑是一种非常先进的设计思想,无论你选择哪种语言,无论应用多复杂,它都能为你理解分析应用模型时提供最基本的分析方法,为你构造产品提供清晰的设计框架,为你的软件工程提供规范的依据。MVC设计思想MVC英文即Model-View-Controller,即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离,这样一个应用被分成三个层――模型层、视图层、控制层。视图(View)代表用户交互界面,对于Web应用来说,可以概括为HTML界面,但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性,界面的处理也变得具有挑战性。一个应用可能有很多不同的视图,MVC设计模式对于视图的处理仅限于视图上数据的采集和处理,以及用户的请求,而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户,以及将用户界面的输入数据和请求传递给控制和模型。模型(Model):就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱 *** 作,模型接受视图请求的数据,并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子,它从应用技术实现的角度对模型做了进一步的划分,以便充分利用现有的组件,但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件,从而减少了技术上的困难。对一个开发者来说,就可以专注于业务模型的设计。MVC设计模式告诉我们,把应用的模型按一定的规则抽取出来,抽取的层次很重要,这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远,也不能太近。MVC并没有提供模型的设计方法,而只告诉你应该组织管理这些模型,以便于模型的重构和提高重用性。我们可以用对象编程来做比喻,MVC定义了一个顶级类,告诉它的子类你只能做这些,但没法限制你能做这些。这点对编程的开发人员非常重要。业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存(持续化)。比如将一张订单保存到数据库,从数据库获取订单。我们可以将这个模型单独列出,所有有关数据库的 *** 作只限制在该模型中。控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起,共同完成用户的请求。划分控制层的作用也很明显,它清楚地告诉你,它就是一个分发器,选择什么样的模型,选择什么样的视图,可以完成什么样的用户请求。控制层并不做任何的数据处理。例如,用户点击一个连接,控制层接受请求后, 并不处理业务信息,它只把用户的信息传递给模型,告诉模型做什么,选择符合要求的视图返回给用户。因此,一个模型可能对应多个视图,一个视图可能对应多个模型。MVC的优点大部分用过程语言比如ASP、PHP开发出来的Web应用,初始的开发模板就是混合层的数据编程。例如,直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计d性力度很小,很难满足用户的变化性需求。MVC要求对应用分层,虽然要花费额外的工作,但产品的结构清晰,产品的应用通过模型可以得到更好地体现。首先,最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下,可能有多种方式访问应用的要求。例如,订单模型可能有本系统的订单,也有网上订单,或者其他系统的订单,但对于订单的处理都是一样,也就是说订单的处理是一致的。按MVC设计模式,一个订单模型以及多个视图即可解决问题。这样减少了代码的复制,即减少了代码的维护量,一旦模型发生改变,也易于维护。MVC设计模型其次,由于模型返回的数据不带任何显示格式,因而这些模型也可直接应用于接口的使用。再次,由于一个应用被分离为三层,因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。控制层的概念也很有效,由于它把不同的模型和不同的视图组合在一起完成不同的请求,因此,控制层可以说是包含了用户请求权限的概念。最后,它还有利于软件工程化管理。由于不同的层各司其职,每一层不同的应用具有某些相同的特征,有利于通过工程化、工具化产生管理程序代码。MVC的缺点MVC的设计实现并不十分容易, 理解起来比较容易,但对开发人员的要求比较高。MVC只是一种基本的设计思想,还需要详细的设计规划。模型和视图的严格分离可能使得调试困难一些,但比较容易发现错误。经验表明,MVC由于将应用分为三层,意味着代码文件增多,因此,对于文件的管理需要费点心思。综合上述,MVC是构筑软件非常好的基本模式,至少将业务处理与显示分离,强迫将应用分为模型、视图以及控制层, 使得你会认真考虑应用的额外复杂性,把这些想法融进到架构中,增加了应用的可拓展性。如果能把握到这一点,MVC模式会使得你的应用更加强壮,更加有d性,更加个性化。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)