- 浏览: 51916 次
- 性别:
- 来自: 北京
最新评论
从三层架构到MVC,MVP
http://www.cnblogs.com/daizhj/archive/2009/04/30/1447035.html
一. 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进行大型目开发,就连中小企业应
用都应付不来。
三. 能不能使用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,其实在这之前我们有必要看一下这张图:
看完了上面的图,大家就会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不该
通信(甚至双向通信,如图)。我想这也是目前做这两方面研究的专家所互相争论的战场。必定各
有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。如果没有它,
MODEL与View就是两个孤岛,尽管各有各的地盘(完全解耦),但不会给企业带来什么有用的价值。
所以我这里有一个比喻来形容MVP中的:
Presenter ----就是一个控制欲极强的女人,甚至就连“用什么姿势”,它都要管一管。
当然日里万机操心多了就会让自己要做的事越来越多,最终它面临的就是该层代码日益庞杂,
且书写起来不太方便,必定就连事件绑定这类鸡毛算皮的事都要归它管,累不累呀。最终我们看到
MVP中的View就真的代码轻闲了不少(国企职工嘛),难怪说View只要从相应的IVIEW接口下实现相
应的属性和一些简单方法就完事了,而最终调用IVIEW接口下的那个视图实例则完全交给了Presenter,
这让我想到了MVC中可以支持“自定义模版引擎(最终由MVC框架来控制使用系统还是自定义的模版
引擎)”以及平时大家常挂在嘴边的换肤功能,想到这里多少还真有那么点意思了(精神层面上)。
当然在微软内部对MVP的理解也有所不同,如下图中所说的Supervising Controller模式和上面
大家看到的PassiveView.
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层采用接口方式实现,以此来应对将来不断变化的业务需求。
.从三层架构到MVC,MVP
http://www.cnblogs.com/daizhj/archive/2009/04/30/1447035.html
一. 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进行大型目开发,就连中小企业应
用都应付不来。
三. 能不能使用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,其实在这之前我们有必要看一下这张图:
看完了上面的图,大家就会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不该
通信(甚至双向通信,如图)。我想这也是目前做这两方面研究的专家所互相争论的战场。必定各
有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。如果没有它,
MODEL与View就是两个孤岛,尽管各有各的地盘(完全解耦),但不会给企业带来什么有用的价值。
所以我这里有一个比喻来形容MVP中的:
Presenter ----就是一个控制欲极强的女人,甚至就连“用什么姿势”,它都要管一管。
当然日里万机操心多了就会让自己要做的事越来越多,最终它面临的就是该层代码日益庞杂,
且书写起来不太方便,必定就连事件绑定这类鸡毛算皮的事都要归它管,累不累呀。最终我们看到
MVP中的View就真的代码轻闲了不少(国企职工嘛),难怪说View只要从相应的IVIEW接口下实现相
应的属性和一些简单方法就完事了,而最终调用IVIEW接口下的那个视图实例则完全交给了Presenter,
这让我想到了MVC中可以支持“自定义模版引擎(最终由MVC框架来控制使用系统还是自定义的模版
引擎)”以及平时大家常挂在嘴边的换肤功能,想到这里多少还真有那么点意思了(精神层面上)。
当然在微软内部对MVP的理解也有所不同,如下图中所说的Supervising Controller模式和上面
大家看到的PassiveView.
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层采用接口方式实现,以此来应对将来不断变化的业务需求。
.从三层架构到MVC,MVP
发表评论
-
web前端优化
2014-07-21 18:16 648http://www.cnblogs.com/develope ... -
Java取得当前类的路径
2012-02-23 15:15 855一此不安全的做法: 1. new File(path),这个 ... -
SMTP 服务器要求安全连接或客户端未通过身份验证的各个解决方案
2011-10-18 11:21 4410转: SMTP 服务器要求安全连接或客户端未通过身份验证的各个 ... -
ExecutorService线程池
2011-10-10 14:10 934ExecutorService 建立多线程的步骤: 1。定义 ... -
CountDownLatch 的使用小例
2011-10-10 14:08 838CountDownLatch java.util.concur ... -
java正则表达式 过滤特殊字符的正则表达式
2011-09-24 09:30 981在网上找了好久也没找到个合适的正则表达式以过滤特殊字符;自己学 ... -
Java取得当前类的路径
2011-09-21 10:44 7001. new File(path),这个方法的路径到底在那里取 ... -
Eclipse europa 更新时 Error retrieving "feature.xml". [error in opening zip file]
2011-09-06 17:20 672Eclipse europa 更新时 Error retrie ... -
用java调用oracle存储过程总结
2011-08-04 23:45 6401、什么是存储过程。存 ... -
buffer 与cache 的区别
2011-08-04 23:27 780A buffer is something that has ... -
MVC与MVP简单对比
2011-08-01 21:14 822在Java平台,基于Spring等技术的MVC框架已经走向成熟 ... -
VSS介绍和备份技巧
2011-08-01 21:11 1026VSS 的全称为 Visual Source ... -
多线程Java Socket编程示例
2011-08-01 21:09 735采用Java 5的ExecutorService来进行线程池的 ... -
Java基于Socket文件传输示例
2011-08-01 21:04 589最近需要进行网络传输大文件,于是对基于socket的文件传输作 ...
相关推荐
【三层架构到MVC-MVP】的理解 三层架构是一种经典的软件设计模式,通常包括表现层(用户界面)、业务逻辑层(处理业务规则)和数据访问层(与数据库交互)。这种架构强调各层之间的职责分离,提高了代码的可维护性...
在你提供的示例项目中,`MVC+MVP+MVVM`这个压缩包很可能包含了使用这三种模式实现的Android项目实例。通过查看和学习这些示例,开发者可以更直观地理解每种模式的实现方式,以及它们在实际开发中的应用。每个模式都...
本项目深入探讨了三种主流的Android架构模式:MVC(Model-View-Controller)、MVP(Model-View-Presenter)以及MVVM(Model-View-ViewModel)。以下是对这些架构设计模式的详细解释: 1. MVC(Model-View-...
"MVC_MVP_MVVM_demos"这个压缩包文件显然包含了关于三种常见的UI架构模式的示例:Model-View-Controller (MVC),Model-View-Presenter (MVP) 和 Model-View-ViewModel (MVVM)。下面我们将详细探讨这三个架构模式,...
MVC是iOS开发中最常用的架构模式,它将应用分为三个主要部分:Model(模型)、View(视图)和Controller(控制器)。Model负责数据处理和业务逻辑,View负责显示数据,而Controller作为两者之间的桥梁,处理用户交互...
本示例着重探讨了三种常见的架构模式:MVC(Model-View-Controller)、MVP(Model-View-Presenter)和MVVM(Model-View-ViewModel),以及DataBinding的基本运用。下面将对这些知识点进行详细解释。 首先,我们来...
本文将详细探讨三种常见的架构模式:MVC(Model-View-Controller)、MVP(Model-View-Presenter)以及MVVM(Model-View-ViewModel),并结合AndroidFrameStudy这个项目来解析它们在实际开发中的应用。 1. **MVC...
本实践主要探讨了三种当前广泛使用的Android架构模式:Model-View-Controller(MVC)、Model-View-Presenter(MVP)以及Model-View-ViewModel(MVVM)。我们将详细解析这三种架构模式的核心概念、优缺点,并通过实际...
本文将深入探讨三种常见的架构模式:MVC(Model-View-Controller)、MVP(Model-View-Presenter)以及MVVM(Model-View-ViewModel),并结合提供的项目源码进行分析。 **MVC(Model-View-Controller)**: MVC是最...
本压缩包“flutter_mvc_mvp.zip”提供了一个实战案例,帮助开发者理解和实践MVC(Model-View-Controller)和MVP(Model-View-Presenter)两种设计模式在Flutter中的应用。 首先,我们来深入了解一下MVC模式。MVC是...
MVC模型-view-controller(控制器)是一种软件架构模式,主要用于将应用程序分为三部分:模型、视图和控制器。该模式的主要目的是将业务逻辑和表示层分离,提高应用程序的可维护性和可扩展性。 模型(Model)是指...
MVC是一种将应用程序分为三个主要部分的架构模式: 1. **Model(模型)**:模型层负责处理数据和业务逻辑。它包含了应用的数据模型和数据访问对象(DAO)。当数据发生变化时,模型会通知视图进行更新。 2. **View...
【C#基于三层架构的图书管理系统】是一种采用C#编程语言设计和实现的客户端/服务器(C/S)模式的应用程序,主要用于图书馆的信息管理和自动化操作。三层架构是一种将应用程序分为表现层、业务逻辑层和数据访问层的...
在IT行业中,MVC(Model-View-Controller)是一种广泛应用于软件开发的架构模式,尤其在Web应用领域中。这个模式将应用程序分为三个主要部分,每个部分都有明确的责任,从而提高了代码的可维护性和可扩展性。本项目...
三层架构模式通过将业务逻辑、数据访问和用户界面分离,提高了系统的灵活性和可维护性。这种分层方法使得各个部分可以独立开发和测试,降低了耦合度。 ##### MVC(Model-View-Controller) MVC是一种广泛使用的软件...
普通的三层架构(BLL,DAL,Model) 1)实体(Model),用来创建对象的实体; 2)业务逻辑层(BLL),用来处理复杂的数据间的关系或者是业务间的关系; 3)数据库访问层(DAL),用来用来访问数据库的; 当然还会有...
MVP架构是MVC(Model-View-Controller)的一种改进版本,主要解决了MVC中ViewController职责过重的问题,实现了代码的解耦。 **一、MVP架构介绍** MVP架构将应用分为三个主要组件:Model(模型)、View(视图)和...