MVC架构开发综述
MVC架构开发综述
MVC架构开发
一、什么是模式？什么是框架？
1、什么是模式？
模式，即pattern。其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度，那就是模式。Alexander给出的经典定义是：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。
模式有不同的领域，建筑领域有建筑模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现很多模式。
2、什么是框架？
框架，即framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。
3、为什么要用模式？
因为模式是一种指导，在一个良好的指导下，有助于你完成
任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。
为什么要用框架？
因为软件系统发展到今天已经很复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。
软件为什么要分层？
为了实现“高内聚、低耦合”。把问题划分开来各个解决，易于控制，易于延展，易于分配资源…总之好处很多啦
二、MVC架构开发
MVC是一种软件开发架构，它包含了很多的设计模式，最为密切的有以下3种：Observer（观察者模式）、Composite （合成模式）和Strategy（策略模式）。本节主要论述MVC
架构的原理、优缺点以及MVC为Web应用程序带来的好处。
1、什么是MVC架构
模型（Model）－视图（View）－控制器（Controller）即为MVC，MVC在八十年代为编程语言Smalltalk－80发明的一种软件架构模式，至今已被广泛使用。模型－视图－控制器模式是一个有用的工具箱，但它也存在一些不足。
2、MVC工作原理
MVC是一个设计模式，它使应用程序的输入、处理和输出强制性分开，使得软件可维护性、可扩展性、灵活性以及封装性得到提高。使用MVC应用程序被分成三个核心部件：M（模型）、V（视图）、C（控制器）。模型是所有的商业逻辑代码片段所在。视图表示数据在屏幕上的显示。控制器提供处理过程控制，它在模型和视图之间起连接作用。控制器本身不输出任何信息和做任何处理，它只负责把用户的请求转成针对Model的操作，和调用相应的视图来显示Model
处理后的数据。三者之间关系。
MVC（Model-View-Controller）把系统的组成分解为M（模型）、V（视图）、C（控制器）三种部件。下面分别对这三个核心部件进行介绍。
模型
模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，就是
说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
视图
视图是用户可以看到并与之交互的界面。视图就是由HTML 元素组成的界面，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括MacromediaFlash、XHTML、XML/XSL、WML等一些标识语言和WebServices 等。
如何处理应用程序的界面变得越来越有挑战性。MVC有一个突出的优点是能为应用程序处理很多不同的视图，在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是本地储存，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
控制器
现在总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。
三、为什么要使用MVC架构
https://www.wendangku.net/doc/cc10205389.html,提供了一个很好的实现这种经典设计模式的环境。
程序人员通过在ASPX页面中开发用户接口来实现视图，控制器的功能在逻辑功能代码（.cs）中实现，模型通常对应系统的业务部分。在https://www.wendangku.net/doc/cc10205389.html,中实现这种设计而提供的一个多层系统，将数据（模型）从对其操作的动作（控制器）分离出来可以设计一个与后台存储数据无关的系统，就MVC 结构的本质而言，它是一种解决耦合系统问题的方法。
在https://www.wendangku.net/doc/cc10205389.html,中编写MVC模式具有极其良好的可扩展性。它可以轻松实现以下功能：
实现一个模型的多个视图
采用多个控制器
当模型改变时，所有视图将自动刷新
所有的控制器将相互独立工作
这就是MVC架构的好处，只需在以前的程序上稍作修改或增加新的类，即可增添程序的功能。以前开发的类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。
下面介绍一下使用MVC架构的优点：
1、提高代码重用率
最重要的一点是多个视图能共享一个模型，无论用户想要Flash界面或是WAP界面；用一个模型就能处理它们。由于已经将数据和业务规则从表示层分开，所以可以最大化的重用代码。
2、提高程序的可维护性
因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变数据层和业务规则。例如，把数据库从SQLServer 移植到Oracle，只需改变模型即可。一旦正确的实现了模型，不管数据来自哪里，视图都会正确的显示它们。MVC架构的运用，使得程序的三个部件相互对立，大大提高了程序的可维护性。
3、有利于团队开发
在开发过程中，可以更好地分工，更好地协作。有利于开发出高质量的软件。良好的项目架构设计，将减少编码工作量。采用MVC结构和代码生成器，是大多数Web应用程序的理想选择。部分模型（Model）和存储过程一般可用工具自动生成。控制器（Controller）比较稳定，一般由架构师（或经验丰富程序人员）完成；那么整个项目需要手动编写代码的地方就只有视图(View)了。在这种模式下，个人能力不是特别重要，只要懂点语法基础的人都可以编写，无论项目成员写出什么样的代码，都在项目管理者的可控范围内。即使开放项目途中人员流动，也不会有太大问题。在个人能力不均衡的团队开发中，采用MVC开发是非常理想的。
另外，MVC架构可以实现一个模型、两个视图和一个控制器的程序。下面将讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前
面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。
同样也可以实现其他形式的MVC。例如：一个模型、两个
视图和两个控制器。从上面可以看出，通过MVC模式实现
的应用程序具有极其良好的可扩展性，是https://www.wendangku.net/doc/cc10205389.html,面向对象编程的未来方向。
四、表示层——业务逻辑层——数据访问层
1、什么是三层架构
所谓的三层开发就是将系统的整个业务应用划分为表示层——业务逻辑层——数据访问层，这样有利于系统的开发、维护、部署和扩展。
分层是为了实现“高内聚、低耦合”。采用
“分而治之”的思想，把问题划分开来各个解决，易于控制，易于延展，易于分配资源。
表示层：负责直接跟用户进行交互，一般也就是指系统的界面，用于数据录入，数据显示等。意味着只做与外观显示相关的工作，不属于他的工作不用做。
业务逻辑层：用于做一些有效性验证的工作，以更好地保证程序运行的健壮性。如完成数据添加、修改和查询业务等；不允许指定的文本框中输入空字符串，数据格式是否正确及数据类型验证；用户的权限的合法性判断等等，通过以上的
诸多判断以决定是否将操作继续向后传递，尽量保证程序的正常运行。
数据访问层：顾名思义，就是用于专门跟数据库进行交互。执行数据的添加、删除、修改和显示等。需要强调的是，所有的数据对象只在这一层被引用，如System.Data.SqlClient 等，除数据层之外的任何地方都不应该出现这样的引用。https://www.wendangku.net/doc/cc10205389.html,可以使用.NET平台快速方便地部署三层架构。https://www.wendangku.net/doc/cc10205389.html,革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#、VB、C++和
J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名空间可以方便的使用自己定义的组件。显示层放在ASPX页面中，数据库操作和逻辑层用组件或封装类来实现，这样就很方便的实现了三层架构。
2、为什么使用三层架构
对于一个简单的应用程序来说，代码量不是很多的情况下，一层结构或二层结构开发完全够用，没有必要将其复杂化，如果对一个复杂的大型系统，设计为一层结构或二层结构开发，那么这样的设计存在很严重缺陷。下面会具体介绍，分层开发其实是为大型系统服务的。
在开发过程中，初级程序人员出现相似的功能经常复制代码，那么同样的代码为什么要写那么多次？不但使程序变得冗长，更不利于维护，一个小小的修改或许会涉及很多页面，
经常导致异常的产生使程序不能正常运行。最主要的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依然走着面向过程的道路。
意识到这样的问题，初级程序人员开始将程序中一些公用的处理程序写成公共方法，封装在类中，供其它程序调用。例如写一个数据操作类，对数据操作进行合理封装，在数据库操作过程中，只要类中的相应方法（数据添加、修改、查询等）可以完成特定的数据操作，这就是数据访问层，不用每次操作数据库时都写那些重复性的数据库操作代码。在新的应用开发中，数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。读者现在似乎找到了面向对象的感觉，代码量较以前有了很大的减少，而且修改的时候也比较方便，也实现了代码的重用性。
下面举两个案例，解释一下为什么要使用三层架构。
案例一：
数据库系统软件由于数据量的不断增加，数据库由Access 变成了SQLServer数据库，这样原来的数据访问层失效了，数据操作对象发生了变化，并且页面中涉及数据对象的地方也要进行修改，因为原来可能会使用OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader
对象，SQLServer和Access支持的数据类型也不一致，在显示数据时进行的数据转换也要进行修改，这是其中一种情
况。
案例二：
由于特殊情况需要，把Web形式的项目改造成Windows应用，此时需要做多少修改呢？如果在Aspx.cs中占据了大量代码，或者还有部分代码存在于Aspx中，那么整个系统是
否需要重新来开发呢？
在上面的案例中是否体会到了没有分层开发模式的缺陷呢？是否碰到过这样的情况呢？这都是由设计不合理造成的，多层开发架构的出现可以很好地解决该问题，通过程序架构进行合理的分层，将极大地提高程序的通用性。
3、使用三层架构开发的优点
使用三层架构开发有以下优点：
从开发角度和应用角度来看，三层架构比二层架构或单层架构都有更大的优势。三层架构适合团队开发，每人可以有不同的分工，协同工作使效率倍增。开发二层或单层应用程序时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用程序时，则可以结合多方面的人才，只需少数人对系统全面了解即可，从一定程度降低了开发的难度。
三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以在多个计算机上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。美国人曾利用
分式计算解密，几个月就破解了据称永远都破解不了的密码。
三层架构的最大优点是它的安全性。用户只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
4、三层架构的种类
目前，团队开发人员在开发项目时，大多都使用分层开发架构设计，最常见的就是三层架构，目的在于使各个层之间只能够被它相邻的层产生影响，但是这个限制常常在使用多层开发的时候被违反，这对系统的开发是有害的。三层架构按驱动模式可划分三种：数据层驱动模式、陈述层驱动模式和隔离驱动模式，其中隔离驱动模式开发最为重要。下面通过三种模式的对比，介绍隔离驱动模式的重要性。
数据层驱动模式
所谓的数据层驱动模式，就是先设计数据层，陈述层围绕数据层展开，一旦完成了数据层和陈述层，业务层就围绕数据层展开。因为陈述层是围绕数据层展开的，这将会使陈述层中的约束不准确，并且限制了业务层的变更。由于业务层受到限制，一些简单变化可以通过SQL查询和存储过程来实现。
这种模式非常的普遍，它和传统的客户服务端开发相似，并且是围绕已经存在的数据库设计的。由于陈述层是围绕数据层设计的，它常常是凭直觉模仿数据层的实际结构。
常常存在一种额外的反馈循环在陈述层到数据之间，当在设
计陈述层不容易实现的时候常常会去修改数据层，也就形成了这种反馈循环。开发者请求修改数据库方便陈述层的开发，但是对数据层的设计却是有害的。这种改变是人为的而没考虑到其他需求的限制。这种修改经常会违反至少损害数据的特有规则，导致不必要的数据冗余和数据的非标准化。
陈述层驱动模式
陈述层驱动模式是数据层围绕陈述层展开的。业务层的完成一般是通过简单的SQL查询和很少的变化或者隔离。由于
数据库的设计是为了陈述层的方便，并非从数据层设计方面考虑，所以数据库的设计在性能上通常很低。陈述层驱动模式设计图如图1.6所示。
隔离驱动模式
用隔离驱动模式设计，陈述层和数据层被独立的开发，常常是平行开发。这两层在设计时没有任何的相互干扰，所以不会存在人为的约束和有害的设计元素。当两层都设计完成后，再设计业务层。业务层的责任就是在没有对数据层和陈述层的需求变化的基础上完成所有的转换。陈述层驱动模式设计。因为现在陈述层和数据层是完全独立的，当业务层需求改变的时候，陈述层和数据层都可以做相应的修改而不影响对方。改变两个在物理上不相邻的层不会直接对其他层产生影响
或发生冲突。这就允许数据层结构的调整或者陈述层根据用户的需求做相应的变化，而不需要系统做大的调整或者修改。
表1.1将对这3种驱动模式进行对比。
表种驱动模式对比
数据层驱动模式
陈述层驱动模式
隔离驱动模式数据库
（1）很容易设计
（2）产生负面影响
（3）很难改变数据层，因为它和陈述层紧密绑定
（1）数据库设计很糟
（2）严重的不规范化设计
（3）其他系统不易使用
（4）很难改变数据层，由于它跟陈述层紧密绑定
（1）优化设计
（2）集中设计数据库，陈述层对它影响很小业务需求常常不能适应业务需求变化
常常适应业务需求变化
适应需求变化用户界面
是围绕数据层而不是围绕用户，不易修改
适合用户扩展界面
适合用户扩展界面扩展性
通常可扩张，但是常常在用户界面需要比较多的重写以满足数据库的结构，同时数据库可能需要存储一些冗余的字段
完整性的扩张很难，常常只有通过“剪切，粘贴
”函数来实现
很容易扩展