mvc使用什么设计模式 (mvc用什么技术实现)
本文目录导航：
mvc使用什么设计模式
MVC是Model,View,Controller的缩写,MVC是Application开发的设计模式，也就是大家所知道的Model2.在MVC的设计模式中，它包括三类对象：（1）模型（Model）对象：是应用程序的主体部分。
（2）视图（View）对象：是应用程序中负责生成用户界面的部分。
（3）控制器（Control）对象：是根据用户的输入，控制用户界面数据显示及更新Model对象状态的部分。
即要求在Application开发中你把商业逻辑，界面显示，数据分离。
MVC应用程序总是由三个部分组成(事件)导致Controller改变Model或View,或者同时改变两者.只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新.类似的,只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己 MVC模式是一个复杂的架构模式,其实现也显得非常复杂,但多种设计模式结合在一起,使MVC模式的实现变得相对简单易行可以看作一棵树,显然可以用Composite Pattern来实现和Models之间的关系可以用Observer Pattern体现控制Views的显示,可以用Strategy Pattern实现通常是一个调停者,可采用Mediator Pattern来实现. Java开发Web Application有几种符合MVC设计模式的开发方式。
1:Jsp+Servlet+JavaBean(EJB) 2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model) 3:TDK(Turbine，Velocity...) 4:Xsp 5:Jsp+Struts+JavaBean(EJB)
设计模式的C语言应用-表驱动模式
表驱动模式在C语言编程中常见，它通过从表中查找信息而非使用逻辑语句（如if和case）来实现，其核心操作是将输入因素作为直接或间接的索引，以此在数组中找到直接的结果或对应的处理（通常是函数指针）。
表驱动模式实质上是将逻辑与数据分离，使得因素与结果之间的映射关系存储在数组中，而非混杂在流程代码中。
这使修改映射关系变得简单，只需调整数组即可，无需修改代码，便于管理和维护。
甚至可以将数据作为配置文件存放在硬盘上，需要时读取进来，避免代码重新编译。
根据输入因素的不同，表驱动模式可以分为直接访问、输入元素转化为序号访问和输入元素是分段范围的访问。
按照输入因素的个数，又可分为一维表查找和多维表查找。
直接访问模式是基础且本质的模式，适用于输入因素为整数或易于转换成数组元素序号的情况。
输入元素难以直接作为序号时，可将其通过函数转换为序号后再进行访问。
对于输入元素是分段范围的情况，则需要更复杂的方法来实现。
表驱动模式在实际编程中应用广泛，尤其是在状态机设计模式和命令设计模式中，常用于状态转移和命令码数组的实现。
通过将逻辑关系写入数组，简化代码结构，减少if、else和switch的使用，提高程序的可维护性和可读性。
设计模式（三）创建型模式
根据菜鸟教程的目录，我们首先来看看创建型模式。
创建型模式研究： 下面分别对创建型模式下的各种具体模式进行讲解。
先看例子： 工厂模式。
某功能的使用者只和接口打交道，不关心如何实现。
这种情况下，肯定有一个接口类，使用者使用接口；功能提供者继承并实现接口。
这利用了C++的多态特性。
既然使用者只关心接口，那么没有必要把子类直接给使用者，没有必要让使用者在代码中直接new子类。
如果这样做，会把不必要的信息暴露给使用者，增加了信息的耦合。
试想，如果使用者在很多地方都new了子类，那么如果这些地方需要修改的话，怎么改？只能一个一个地方改，改完还需要编译，维护极其困难。
工厂模式是指，针对某一功能接口，我们要新建一个工厂类，此工厂类将接口子类名称、接口子类的创建过程封装起来，只返回一个接口指针给接口的使用者。
接口的实现类对使用者完全透明，高度解耦。
这样可以方便地切换接口的具体实现，而不影响上层功能使用者。
拿 汽车 打比方，不管工厂生产 汽车 的流程是什么，只要是 汽车 ，它的驾驶方法（人机接口）都类似。
显而易见，工厂模式在使用者和实现者之间增加了一个封装层，这正印证了计算机行业中一句名言： 典型的例子是：Qt中的数据库模块就利用了工厂模式，封装了数据库的底层实现。
在保持数据库用户接口不变的情况下，通过更换数据库驱动，可以实现数据库类型无缝切换。
在需求趋于稳定时使用，需求不稳定时，不要过度设计，否则设计很容易被推翻，白费力气。
从设计模式的本质来看，工厂模式： 先看例子： 抽象工厂模式。
由前面工厂模式可知，所有的“工厂”有一个共同点：每个工厂都会提供创建对象的函数。
既然所有工厂都实现了同一类功能，那么我们可以为工厂抽象出一个公共接口（虚基类），此接口定义了创建工厂子类的功能。
这种场景是否似曾相识？是的，工厂和工厂的功能接口构成了使用工厂模式的场景。
即工厂本身也适用于工厂模式。
使用工厂模式来设计工厂，必然要写一个生产工厂的工厂。
生产工厂的工厂，返回值是工厂的抽象接口类，所以这种设计模式叫“抽象工厂模式”。
其实，笔者觉得把这种设计模式叫做“工厂工厂模式”更容易理解。
如果只有一个工厂就不要使用抽象工厂模式了，只有在工厂很多时，才使用抽象工厂模式。
需求不稳定时，不要过度设计，一切都可能被推翻。
对于小的项目，不需要过度追求使用设计模式，架构的代码最好只占整个项目代码的一小部分，否则就是主次颠倒，给自己找麻烦。
对于大的项目，在需求较稳定的情况下，为了提高可维护性、扩展性，可以考虑使用设计模式。
另外，抽象工厂模式有一定的理解难度，要考虑你设计的代码，其他人是否能够读懂，简单易懂也是需要考虑的方面。
所以，从设计模式的本质来看， 先看例子： 单例模式。
上面的例子都是允许一个类被创建多次的。
如果我们想要限制一个类只被创建一次，即只有一个全局可访问的实例（和C语言中的全局变量一样），例如应用程序对象，每个应用程序都应该只有一个应用程序对象。
此时应该怎么编写代码呢？ 答案还是封装。
把不想暴露出来的信息藏起来，把必须暴露的信息暴露出来。
单例模式把类的构造函数设置成private私有访问权限，限制外部无法通过new来创建实例。
只能通过特定的接口来获取实例指针。
需要提及的是，封装时需要考虑多线程安全的问题。
当一个类需要有多个实例存在时，不使用单例模式。
从设计模式的本质上看， 具体的例子和写法，可以参考菜鸟教程中的 建造者模式。
建造者模式的典型使用场景是快餐店的套餐搭配模型。
套餐由若干个单个餐品组合而成。
单个餐品又由不同的原材料构成。
这种层层组合的树形对象关系的应用场景下，为了创建顶层的对象，需要先一层层的创建底层的对象，逐步向上，直到构造出根对象。
这种场景下，使用继承可以将同类的对象关联起来，使用组合可以将不同类型的对象组合起来。
组合就是把不同对象放在一块内存中保存，作为一个整体使用。
完全使用继承来解决此类问题是非常不提倡的。
设计模式理论中有一个原则是：“少用继承，多用组合”。
因为继承是一种强耦合，组合是一种松散的耦合。
耦合不利于适应需求变化，是项目中的一颗定时炸弹。
从设计模式的本质上看， 菜鸟教程中没有提及的一种设计模式是组合模式。
具体内容可以参考： 第四节：组合模式和建筑者模式详解。
这里简单说明一下，组合模式和建造者模式比较像，也是遵循树形对象关系结构。
和建造者模式相比，不同之处在于，子对象和父对象具有相同的类型。
所以可以说，组合模式是简单的建造者模式。
具体的使用场合和实例，见原型模式。
原型模式，在实际使用时可能用得不多。
用一句话描述其特点： 这种克隆是一种内存中的复制行为，速度快，能充分利用已有对象的缓存数据，性能高。
克隆出来的对象具有和原对象相同的属性和行为，可以用来帮助原对象处理一些事务。
用一句动漫中的词汇来描述，“影分身”再合适不过了。
从设计模式的本质看， 下一篇，我们将介绍结构型模式。
phper