MVC框架的优缺点


MVC的优点
  大部分用过程语言比如ASP、PHP开发出来的Web应用,初始的开发模板就是混合层的数据编程。例如,直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小,很难满足用户的变化性需求。MVC要求对应用分层,虽然要花费额外的工作,但产品的结构清晰,产品的应用通过模型可以得到更好地体现。 
  首先,最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下,可能有多种方式访问应用的要求。例如,订单模型可能有本系统的订单,也有网上订单,或者其他系统的订单,但对于订单的处理都是一样,也就是说订单的处理是一致的。按MVC设计模式,一个订单模型以及多个视图即可解决问题。这样减少了代码的复制,即减少了代码的维护量,一旦模型发生改变,也易于维护。 其次,由于模型返回的数据不带任何显示格式,因而这些模型也可直接应用于接口的使用。 
  再次,由于一个应用被分离为三层,因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。 
  控制层的概念也很有效,由于它把不同的模型和不同的视图组合在一起完成不同的请求,因此,控制层可以说是包含了用户请求权限的概念。 
   最后,它还有利于软件工程化管理。由于不同的层各司其职,每一层不同的应用具有某些相同的特征,有利于通过工程化、工具化产生管理程序代码。
   
MVC的不足
  MVC的不足体现在以下几个方面:
  (1)增加了系统结构和实现的复杂性。对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率。
  (2)视图与控制器间的过于紧密的连接。视图与控制器是相互分离,但确实联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
  (3)视图对模型数据的低效率访问。依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
  (4) 目前,一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的,从而造成使用MVC的困难。




MVC 和三层架构 首先、它们很相似; MVC 可分为: Model 模型层、 View 视图层、 Controller 控制层; 三层架构为:视图层、控制层、业务逻辑层
+ 数据访问层。 如此分包法, 层次上的结构虽清晰, 而且很大程度地减少了模块之间的耦合度, 但这样 同时也添加了些许麻烦。 小的项目这样分层, 分包, 不太符合实际; 但对于大中型项目这样 的分工是太有必要了,视图层、控制层、业务逻辑层、数据访问层,目前我们只要知道这是 最合理的分层模式就可以了。 架构中,我们可以如此分布: 控制层 + ( (模型层 + 数据访问层) + 视图层) = 合理架构。 数据模型层 顾名思义,用来和数据库进行连接交互, SQL 语句当然应该置于此。 模型层中数据访问模块的功能如下: 1) 实现数据的读取与存储操作。 2) 实现事务处理。 界面视图层 主要是处理和用户进行交互的界面,显示结果或者接受输入。 视图层中用户界面模块的功能如下: 1) 与用户的交互,接收用户的各种输入以及输出各种提示信息或处理结果。 2) 对于输入的数据进行数据校验,过滤非法数据。 3) 向业务层发送处理请求。 业务控制层 进行各种逻辑判断。也就是业务逻辑的封装,如有一客户要下一个用账户付款的订单, 但该客户账户内的余额不够,则不该允许此客户下订单,这种逻辑就应放在业务层。 业务层中业务处理模块的功能如下: 1) 实现各种业务处理逻辑或处理算法。 2) 验证请求者的权限。 3) 向数据层发送数据操作的请求。 4) 向用户层返回处理结果。 针对每一层可以设计一个或多个模块,每个模块完成相对独立的功能。 逻辑架构总结 逻辑架构定义了如何分离应用程序中不同的代码。 一个好的逻辑架构的目的是使代码更 容易维护、 理解和可重用性。 而物理架构的定义则指定了运行应用程序的电脑, 一个好的物 理架构目的在于使系统在性能、 可扩展性、 安全性和容错能力之间取得最好的平衡, 来满足 你的特定环境。 分层架构的主要优点是分化了系统的复杂度, 同时也提高了系统的灵活性 (这点从系统 同时满足各种类型数据库即可看出) ,另外,分层架构大大提高了系统的可维护性和可扩展 性。 但是, 分层架构在众多优点的背后也隐藏着缺点, 由于层次的增多, 同一个解决方案下 项目也多, 过多的跨项目访问对应用程序的效率有一定的影响, 但这一点现在可以在越来越 快的硬件提升速度中忽略。
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合"的思想。
  、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
  、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
  、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。
注:(内聚:一个模块内各个元素彼此结合的紧密程度;耦合:一个软件结构内不同模块之间互连程度的度量)

优缺点
  优点:
  1、开发人员可以只关注整个结构中的其中某一层;
  2、可以很容易的用新的实现来替换原有层次的实现;
  3、可以降低层与层之间的依赖;
  4、有利于标准化;
  5、利于各层逻辑的复用。
      6、扩展性强。不同层负责不同的层面,如PetShop可经过简单的配置实现Sqlserver和oracle之间的转换,当然写好了也可以实现B/S与C/S之间的转换
      7、安全性高。用户端只能通过逻辑层来访问数据层,减少了入口点,把很多危险的系统功能都屏蔽了。
      8、项目结构更清楚,分工更明确,有利于后期的维护和升级
  缺点:
  1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
  2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
      3、增加了代码量,增加了工作量


三层架构是:

一:界面层
界面层提供给用户一个视觉上的界面,通过界面层,用户输入数据、获取数据。界面层同时也提供一定的安全性,确保用户不用看到不必要的机密信息。

二:逻辑层

逻辑层是界面层和数据层的桥梁,它响应界面层的用户请求,执行任务并从数据层抓取数据,并将必要的数据传送给界面层。

三:数据层
数据层定义、维护数据的完整性、安全性,它响应逻辑层的请求,访问数据。这一层通常由大型的数据库服务器实现,如Oracle 、Sybase、MS SQl Server等。

------

从开发角度和应用角度来看,三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发,每人可以有不同的分工,协同工作使效率倍增。开发双层或单层应用时,每个开发人员都应对系统有较深的理解,能力要求很高,开发三层应用时,则可以结合多方面的人才,只需少数人对系统全面了解,从一定程度工降低了开发的难度。
三层架构属于瘦客户的模式,用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下,单层或胖客户对面器的要求太高。
三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行,充分利用网络的计算功能。分布式计算的潜力巨大,远比升级CPU有效。
三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层,减少了入口点,把很多危险的系统功能都屏蔽了。
另外三层架构还可以支持如下功能:Remote Access(远程访问资料),例如可透过Internet存取远程数据库;High Performance(提升运算效率)解决集中式运算(Centralize)及主从式架构(Client-Server)中,数据库主机的运算负担,降低数据库主机的Connection Load,并可藉由增加App Server处理众多的数据处理要求,这一点跟前面讲到的分布式计算提高运算能力是一个道理;Client端发出Request(工作要求)后,便可离线,交由App Server和DataBase Server共同把工作完成,减少Client端的等待时间;这个功能我觉得应用场合不是很多,自己感受也不是很深刻,从理论上是成立的。


小项目,以后变动不大的不用三层架构。

ASP.NET三层结构说明

完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层。否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说.不同的应用有不同的理解,这只是一个概念的问题.

理解ASP.NET三层结构——为什么要分三层?

我们用三层结构主要是使项目结构更清楚,分工更明确,有利于后期的维护和升级。它未必会提升性能,因为当子程序模块未执行结束时,主程序模块只能处于等待状态。这说明将应用程序划分层次,会带来其执行速度上的一些损失。但从团队开发效率角度上来讲却可以感受到大不相同的效果。

需要说明一下,三层结构不是.NET的专利,也不是专门用在数据库上的技术。它是一种更加普适的架构设计理念。 

此种架构要在数据库设计上注意表之间的关系,尽力满足主与子的关系。在功能上对用户要有一定的限制,不要表现在对于子表的删除操作一定要慎重,以免造成主表与子表的数据在逻辑上出现的主表的外键在子表中没有相对应的值。

对于表的综合查询方法是:

先对主表查询,调用主表所对应的DL。再根据主表的记录分别对每一个子表进行查询。将自表的查询结果添加的主表后,形成一个大的查询集合。

对于表的操作(增删改):

此时只对主表进行操作,调用主表对应的DL中的操作方法。

RL层是逻辑判断层,主要是对页面上传入的数据进行逻辑判断。RL层之上就是UI

 


免责声明!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系本站邮箱yoyou2525@163.com删除。



 
粤ICP备18138465号  © 2018-2025 CODEPRJ.COM