`
923080512
  • 浏览: 190527 次
  • 性别: Icon_minigender_1
  • 来自: 商丘
社区版块
存档分类
最新评论

MVC 与 MVP

    博客分类:
  • GWT
阅读更多
文本Tag: 系统架构
【IT168 技术文章】

    当然这种架构模式本身的一些问题也会在接下来的内容就加以介绍,另外就是如果大家有什么不同观点的话,欢迎拍砖(只要不打脸就行,呵呵)。

    一. MVC是谁提出的

    模型-视图-控制器(MVC)是Xerox PARC在八十年代为编程语言Smalltalk-80发明的一种软件设计模式,至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式,并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型-视图-控制器模式是一个有用的工具箱,它有很多好处,但也有一些缺点。

    二. MVC是否适合进行大项目的开发

    MVC框架肯定是适合于做大项目开发的,但并不是说有了MVC框架我们就可以开发大项目,听起来有些绕,其实道理很简单,原因就是人(开发者)。如果你是一个对MVC框架的设计理念有深入研究的人,那么你在使用MVC框架进行产品和项目开发的时候就会随时随地都要考虑一些问题:

    1.低耦合性(强调视图层和业务层分离)

    2.可测试性(这个非常重要)

    3.高重用性和可适用性

    4.有利于软件工程化管理等等。

    这里我很欣赏老赵的治学态度,因为在他的文章和代码中随时随地都在进行着思考,特别是其对可测试性,单元测试(这里不是什么TDD)的思考,让我看起来有心灵相通的感觉。因为这些问题都是在做中型甚至大型项目中要认真思考的,决不是说微软给的例子就是我们的唯一准则,必定里面有对也有错,我相信在MVC面前,国内甚至微软内部的牛人都不是很多。

    说了这些,大家可以意识到了,如果在没有理解下面这张图以及对MVC的“所谓优点是从何处得到的”有认识,而一上来就去拿MVC去开发大型项目的话,我想不仅不能发挥asp.net MVC框架的估势,相反会时时受制于里面的约束,配置和功能特性,最后感觉还不如直接用asp.net webform开发来的直接,不是吗?真要是到了这一境地,我想不仅无法使用MVC进行大型目开发,就连中小企业应用都应付不来。
                        <<图1>>




内容导航
    三. 能不能使用MVC架构进行Webform的开发

    有人尝试使用ASP.NET MVC 框架来进行webform方式的开发,我个人是不欣赏这种做法的,这就好比在使用LINQ的项目中又同时使用SQL语句一样“怪异”,这在代码的整体风格上会让人产生迷惑,不是吗?当然老赵也在他的视频课程中提到在webform页面中使用一些MVC功能(比如:ModelBinder等),但我想老赵的本意决不是让这种混合方式的开发大行其道,必定这是“非主流”,所以孰轻孰重还是要大家自己把握的。

    四. 传统的三(N)层架构与MVC,以及MVC与MVP关系

    本文所说的三层架构指:表现层(显示层), 业务逻辑层, 数据访问层(持久化)。如果大家非要“生搬硬套”的把它与MVC扯上关系的话,那我就只能在这里"强扭这个瓜"了,即:

    三层架构中"表现层"的aspx页面对应MVC中的View(继承的类不一样)

    三层架构中"表现层"的aspx.cs页面(类)对应MVC中的Controller,理解这一点并不难,大家想一想我们以前写过的Redirect,当然它本身就是跳转了一些链接页面,而MVC中的Controller要做的更爽,它控制并显示输出了一个视图。即然所起到的作用都是对业务流程和显示信息的控制,只不过是实现手段不同而已。

    三层架构中业务逻辑层和数据访问层对应MVC中的Model(必定View和Controller已找到“婆家”,剩下的Model只能是业务业务层和数据访问层的了,呵呵)。但其实微软的一些MVC示例项目中对这个问题理解的并不是这样简单,这一点在我之前的关于两个MVC示例的思考(MVCStore和Oxite) 已阐述过,就不多说了。

    其实明白了这个关系,就可以尝试把以前的三层结构迁移到MVC框架下,当然在这个过程中肯定会遇到这样或那样的问题,但原则就是把将MVC的优势发挥到极致,要不然还不如不做。说到这里,其实早在N年前就有人提出使用FrontController(前端控制器)来实现对HTTP页面请求的路由跳转(包括数据的展现),说白了就是使用HttpHandler来进行页面请求的处理和数据绑定,而不是完全“指望”普通的页面访问重定向等。这样做的目的,就我而言与Routing中的Controller和Action的出发点标是一致的,只不过Routing实现的更优雅同时也更底层一些。

    说完了三层架构,再看看MVC与MVP,其实在这之前我们有必要看一下这张图:
                    <<图2>>



    看完了上面的图,大家就会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不该通信(甚至双向通信,如图)。我想这也是目前做这两方面研究的专家所互相争论的战场。必定各有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。如果没有它,MODEL与View就是两个孤岛,尽管各有各的地盘(完全解耦),但不会给企业带来什么有用的价值。所以我这里有一个比喻来形容MVP中的:

    Presenter ----就是一个控制欲极强的女人,甚至就连“用什么姿势”,它都要管一管。

内容导航
    当然日里万机操心多了就会让自己要做的事越来越多,最终它面临的就是该层代码日益庞杂,且书写起来不太方便,必定就连事件绑定这类鸡毛算皮的事都要归它管,累不累呀。最终我们看到MVP中的View就真的代码轻闲了不少(国企职工嘛),难怪说View只要从相应的IVIEW接口下实现相应的属性和一些简单方法就完事了,而最终调用IVIEW接口下的那个视图实例则完全交给了Presenter,这让我想到了MVC中可以支持“自定义模版引擎(最终由MVC框架来控制使用系统还是自定义的模版引擎)”以及平时大家常挂在嘴边的换肤功能,想到这里多少还真有那么点意思了(精神层面上)。

    当然在微软内部对MVP的理解也有所不同,如下图中所说的Supervising Controller模式和上面大家看到的PassiveView.
                <<图3>>



    Supervising Controller模式其实很接近于MVC的那张图了,只是又提供了Presenter与View之间的“双向通信”。这种做法也是有很多不同意见的,起码对那些支持“单向依赖”的开发者而言是“嗤之以鼻”的。

    说到这里,表达一下我的观点,我是偏向于PassiveView的,虽然这种模式有些霸道,但必定是让Model和View之间真正解耦,为开发者提供了最大的“控制成就感”,可以说想怎么控制视图就怎么控制,但因此所造成的问题就是代码书写量和实现复杂性等问题了。

内容导航
    五. Controller和Model中该有哪些东东

    因为VIEW中的逻辑比较简单,所以对系统复杂性的考虑基本上要重点放在Model中,而Controller是对业务流程的控制,其应该保持“代码清爽”。说是这么说,但实际进行项目开发时这两者之间的界线能这么清楚吗,答案是“尽量保(坚)持”。必定这是MVC的“特色”嘛。

    另外这里向大家推荐一个不错的方法"Robustness",有了它您就可以很容易的找出那些系统方法要放在MODEL中,哪些该归入控制逻辑中了,该方法我在两年前的一篇文章中提到过,大家感兴趣的话可以看看这个链接, 采用[ICONIX] 方法实践BLOG设计之四 [健壮性分析] .其核心内容如下:

    实体对象(entity object):

    通常是来自域模型中的对象(也就是现实世界),它常对应于数据库表和文件,这些数据表和文件中存储了执行用例所需的数据。有些实体对象是“临时”对象(如搜索结果),当用例结束后将消失。

    边界对象(boundary object):

    参与者使用它来同系统交互,这通常包含窗口,屏幕,对话框和菜单。如果有GUI原型,将会知道许多主要的边界对象是什么。

    控制对象(control object):

    将边界对象和实体对象关联起来(通常被称为控制器,因为它们通常不是真正的对象),它包含了大部分应用逻辑,它们在用户和存储的数据之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略。这样修改只需要在这些对象中进行,而不会涉及到用户界面和数据库模式。控制器偶尔 (20%的时间内)也会是设计中的“真正对象”,但大部分时间内,控制器只是一个占位符,用于避免您遗漏用例要求的任何功能和系统行为。

    上面的三个对象分别对应Model, View, Controller.

    正如文中所说,该方法还提供了如下好处:

    1.它帮助您确保用例文本的正确性,且没有指定不合理或不可能的行为 (基于要使用的一组对象),从而提供了健康性检查。

    2.帮助确保用例考虑了所有必需的分支流程,从而提供了完整性和正确性检查。

    3.让您能够(持续)发现对象,因为在域建模期间可能会遗漏一些对象, 而这些对象在绘制时序图时不易被发现,并且很可能正是它导致无法绘制时序图。

    4.缩小分析和设计的鸿沟,从而最终完成初步设计(关于初步设计复核会在下一篇中介绍)。

    六.MVC与MVP是否可以同时出现在一个SLN甚至一个项目中

    这一点我想谁说了都不算数,只有用户需求才是王道,用户使用在当前项目中实现某些特定功能,而该功能恰恰是MVC或MVP的用武之地,那就一个字:“用”。

    最后还要再说明一点:

    业务逻辑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,所以说一个系统来说,业务逻辑是无处不在的。View上的是显示逻辑,Controller上是流程控制逻辑),Model上简直就是“逻辑大本营”了。

    使用 MVC 框架时我们要将“经常变化”的业务规则(位于Controller)和相对稳定的业务逻辑(位于Model)分离开,同时在Model层采用接口方式实现,以此来应对将来不断变化的业务需求。

  • 描述: 图2
  • 大小: 39.6 KB
  • 描述: 图3
  • 大小: 35.7 KB
  • 描述: 图1
  • 大小: 46.1 KB
分享到:
评论

相关推荐

    MVC和MVP深度对比

    **MVC(Model-View-Controller)和MVP(Model-...综上所述,MVC和MVP都是为了实现业务逻辑与用户界面的分离,但在具体实现和优势上有所不同。选择哪种模式取决于项目的规模、团队的偏好以及对测试和可维护性的需求。

    MVC和MVP的区别

    **MVC(Model-View-Controller)模式与MVP(Model-View-Presenter)模式是两种常见的软件架构设计模式,主要用于构建用户界面。这两种模式在软件开发中扮演着至关重要的角色,帮助开发者组织代码,提高代码的可维护...

    MVC与MVP代码实现在android上

    1. **View(视图)**:与MVC中的视图类似,但在MVP中,视图通常是一个接口,由Activity或Fragment实现。视图只负责用户界面的显示,不包含任何业务逻辑。 2. **Presenter(呈现器/中介者)**:Presenter是视图和...

    MVC与MVP与MVVM.pdf

    MVP是MVC的一个演进版本,它将MVC中的控制器改为Presenter。在MVP中,视图不再负责同步的逻辑,而是由Presenter来处理。Presenter是视图与模型之间交互的中间纽带,它处理与用户交互的逻辑。视图通过接口与Presenter...

    android中的mvc与mvp模式的小demo

    在Android开发中,模型-视图-控制器(MVC)和模型-视图- presenter(MVP)是两种常见的设计模式,它们有助于实现代码的结构化和可维护性。让我们深入了解一下这两种模式以及如何在实际项目中应用它们。 **1. MVC...

    MVC与MVP与MVVM.zip

    **MVC、MVP 和 MVVM 模式详解** 在软件开发领域,尤其是Web和移动应用的开发中,设计模式是提升代码结构和可维护性的关键。MVC(Model-View-Controller)、MVP(Model-View-Presenter)和MVVM(Model-View-...

    Android mvc、mvp、mvvm示例

    **模型(Model)**:仍然处理数据和业务逻辑,与MVC和MVP中的模型相同。 **视图(View)**:与用户交互,展示数据,但不处理任何业务逻辑。在MVVM中,视图通常通过数据绑定直接与ViewModel交互。 **ViewModel**:...

    浅谈三大模式(mvc,mvp,mvvm)

    本文将深入探讨三种常见的设计模式:Model-View-Controller(MVC)、Model-View-Presenter(MVP)和Model-View-ViewModel(MVVM)。这些模式在构建用户界面时起着至关重要的作用,尤其是在Web和移动应用开发中。 ...

    MVC_MVP_MVVM_demos

    - **Model**:仍然负责数据和业务逻辑,与MVC和MVP相同。 - **View**:显示用户界面,但不直接操作Model。通过数据绑定,View的变化会自动反映到ViewModel,反之亦然。 - **ViewModel**:作为View和Model之间的中间...

    MVC、MVP和MVVM

    在MVP中,Presenter取代了Controller,它直接与Model交互并处理业务逻辑,同时与View建立接口,确保View的更新。Presenter使得逻辑更集中,提高了测试性,但可能导致大量接口和回调,增加代码复杂性。 然后是**MVVM...

    Android中的MVC、MVP和MVVM

    Android中MVC、MVP和MVVM的使用,区别,以及使用场景

    mvc,mvp,mvvm简单框架

    1. **模型(Model)**:仍然负责业务逻辑和数据管理,与MVC和MVP中的模型类似。 2. **视图(View)**:用户界面,但其状态和行为直接绑定到ViewModel的属性和命令。 3. **视图模型(ViewModel)**:作为视图和模型...

    android mvc、mvp、mvvm项目源码

    本文将深入探讨三种常见的架构模式:MVC(Model-View-Controller)、MVP(Model-View-Presenter)以及MVVM(Model-View-ViewModel),并结合提供的项目源码进行分析。 **MVC(Model-View-Controller)**: MVC是最...

    Android架构设计(MVC/MVP/MVVM)

    MVP解决了MVC的问题,使代码更易于测试,但 Presenter与View的耦合度仍然较高。而MVVM引入了数据绑定,降低了View和ViewModel之间的耦合,增强了可读性和可测试性,但可能需要额外的学习成本。 在实际开发中,选择...

    flutter_mvc_mvp.zip

    本压缩包“flutter_mvc_mvp.zip”提供了一个实战案例,帮助开发者理解和实践MVC(Model-View-Controller)和MVP(Model-View-Presenter)两种设计模式在Flutter中的应用。 首先,我们来深入了解一下MVC模式。MVC是...

    移动端MVC-MVP架构简单示例

    "移动端MVC-MVP架构简单示例"是一个很好的学习资源,它涵盖了两种常见的Android应用程序架构模式:Model-View-Controller (MVC) 和 Model-View-Presenter (MVP)。 **MVC架构** MVC是一种经典的软件设计模式,它将...

    MVC架构 学习Demo

    MVP与MVC类似,也是一种分层架构,但在Android或Java开发中更为常见。在MVP模式中,Presenter作为模型和视图的中间人,负责协调两者间的交互。这有助于在Android环境中实现更清晰的代码组织和更好的测试能力。 1. *...

    Android架构(MVC、MVP和MVVM).ppt

    PPT的形式展示Android 常用架构(MVC、MVP和MVVM) 简单明了 包含例题以及文字解释 对于刚上路的朋友 不懂架构的 可以下载看看 自己学习一下 有助于项目优化 对后期拓展有很大的帮助!

    AndroidMvc, Android MVC/MVP/MVVM 框架.zip

    AndroidMvc, Android MVC/MVP/MVVM 框架 AndroidMvc框架 特性易于实现 MVC/MVP/MVVM Pattern 用于Android开发增强的Android生命周期- 比如 视图需要刷新时,但不需要旋转,onResume() 不足以区分两个场景。

Global site tag (gtag.js) - Google Analytics