.NET初学者架构设计指南(四)Model-View-Controller

Model-View-Controller简称为MVC,这是图形界面(GUI)应用程序的一种架构形式。Model是业务领 域层,比如我们在前面两篇里面提到的Account、Entry、Bill、Invoice之类的对象,这些类构成了一个 电信账务系统的业务领域层;View就是用户界面;Controller是指用户界面和业务对象之间的控制器, 控制器的作用是从业务对象中获取数据显示到用户界面上,并且从界面上收集用户的输入和动作,然后 调用业务对象完成业务功能。

大部分软件系统的工作可以总结成下面这样的流程:从存储数据的 地方取得数据,把他们显示在用户界面上,然后用户在界面上修改这些数据,再把数据写回存储。数据 在存储和界面之间来回流动。这种看似简单的分析方式经常让开发者有这样一种冲动:把界面和数据写 在一起,这样可以少很多层次,少写很多代码,也可以减少运行过程的环节,似乎可以加快程序的运行 效率。但是实际上,这种直来直去的烟囱式系统不能很好的隔离界面和业务代码,在开发和维护的过程 中会带来很多麻烦。

把程序的界面和业务代码分离开会带来很多好处。一般的说来,界面比起业 务逻辑来变化来的更加频繁一些,修改界面的时候,不应该对业务代码造成影响;开发这两个部分所使 用的技巧也有很大的差别;在有些系统里面,需要为同一个功能开发多种界面,比如一个Windows窗体界 面给后台管理人员使用,一个Web页界面提供给广大人民群众,还需要做一个适用于PDA浏览器的界面, 如果界面和业务代码是混杂在一起的,多种界面的开发就需要做很多重复性的工作;把界面和业务代码 分离开也使可以为自动化的单元测试提供很多方便,要对用户界面创建单元测试代码是十分繁杂的,而 对业务代码做单元测试则是简单的,也是必要的。

于是有经验的开发者会在设计程序的时候创建 一个业务领域层,在这个层次中有很多业务对象,他们直接体现了业务需求的核心。用户界面层不是自 己实现业务功能,而是调用后台的业务对象。用户界面向用户展示业务对象的属性,并且捕获用户的输 入,调用业务对象的方法实现各种功能需求。当业务逻辑层和用户界面层都具备了以后,剩下的一个问 题就是:如何把这两个层次粘和起来——这就是控制器需要做的工作。

最简单的控制 方式就是直接在界面中调用业务对象,这种方式称为Model-View模式。


Model-View模式在界 面和业务模型之间建立了一种最简单的依赖关系,界面直接调用业务模型,模型通过消息这样的松耦合 方式修改界面上的表示内容(比如上一篇里面使用C#语言中的事件实现告警在界面上的显示)。这样可 以实现层次的分离,对改善软件系统的构架是有一定的帮助的。

使用过Microsoft Visual Studio各个版本的开发者一定对Model-View的控制方式非常熟悉,无是在VB、VC,还是后来的C#、 ASP.NET中,我们把一个按钮控件拖放到窗体上,然后鼠标点击这个控件,就会自动生成一段事件响应代 码。下面是用这种方式编写的一段程序,这是“非洲电信公司账务系统”的一个界面,营业 员使用这个界面为用户缴费:


营业员在“号 码”输入框里面填写用户的电话号码,在“金额”输入框里填写需要交的金额,然后点 击“提交”按钮,就可以把钱交进账户。如果发生了异常情况,程序会出现提示。

按 下“提交”按钮的时候,按钮发出Click事件,窗体可以捕获这个事件,采取响应行动。控制 器就是用这样的机制实现的。

private void button1_Click(object sender, System.EventArgs e)    {        //按下缴费按钮,调用业务对象,实现缴费功能        try        {            string phone_no = textBox1.Text;            string money = textBox2.Text;            //根据电话号码得到用户对象            User user = GetUserByPhoneNumber(phone_no);            //得到这个用户的账号            Account account = user.Account;            //调用账号的Pay,接口给账号交钱            //Pay接口处理完费用之后要判断欠费,            //如果不再欠费向交换网络发指令,给用户开机            account.Pay(float.Parse(money));            MessageBox.Show("缴费成功了");        }        catch (Exception e)        {            MessageBox.Show(e.Message);        }    }

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索对象
, 界面
, 代码
, 用户
, 用户界面
, 不显示里面view的内容
, 界面调用Controller
, 业务
Model-View-Controller
r语言初学者指南、selenium初学者指南、设计模式初学者指南、r语言初学者指南 pdf、初学者摄影指南,以便于您获取更多的相关知识。

时间: 2024-10-31 05:17:30

.NET初学者架构设计指南(四)Model-View-Controller的相关文章

.NET初学者架构设计指南(三)设计模式

在上一篇里面,我们初步了解了OO设计,OO设计的最独特之处在于他看待需求的方式.用这样的方式 ,我们不需要急于确定软件需要实现哪些流程.设计哪些功能点.制作哪些画面,而是要关注需求中一 些更加基本的概念.首先根据这些概念开发出一些零件,然后把这些零件组装起来实现需要的功能.用 这样的方式,我们不需要一开始就去知道所有的业务需求,只需要知道一些比较重要的需求,就可以开 始开发了.这样开发出来的程序不仅可以实现当前的需要,同时也是一个业务开发的平台,在这个平台 上可以不断的开发新的功能. 这种设计思

.NET初学者架构设计指南(二)OO设计初次见面

我使用OO技术第一次设计软件的时候,犯了一个设计者所能犯的所有错误.那是一个来自国外的外包 项目,外方负责功能设计,我们公司负责程序设计.编码和测试. 第一个重要的错误是,我没有 认真的把设计说明书看明白.功能点设计确实有一些问题,按照他们的设计,一个重要的流程是无法实 现的.于是我在没有与投资方沟通的情况下,擅自改动了设计,把一个原本在Linux系统上开发的模块改 到了Windows系统上.结果流程确实是实现了,但是很不幸,根本不符合他们的需要,比起原先的设计差 的更多.在询问了这个流程的设计

.NET初学者架构设计指南(一)Hello world的时代

中学的时候,学校里开设了电脑课.当时的电脑还是一种比较希罕的东西,学校里的电脑一共就十几 台,还专门找了一个大厅摆放这些机器.厅里面铺着厚厚的地毯,整天都拉着重重的窗帘.每次上课前 一天,我们需要沐浴更衣,剪好指甲.上课时大家都穿上鞋套,排好队伍,列队进入机房.然后各位同 学坐在座位上,在老师的指挥下,拿出一张五英寸的软磁盘,磁盘里安装着DOS操作系统,插入电脑的A 驱动器.然后依次打开显示器.主机电源,在一阵吱吱声中,等待着电脑的启动,进入一个充满了幻想 的神奇世界. 我就是在那个时候写出了第

一起谈.NET技术,走向ASP.NET架构设计——第四章—业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在

走向ASP.NET架构设计第四章:业务层分层架构(前篇)

在讨论完四种模式之后,我将会和大家一起来看看DDD的一些知识.每种模式的讲解,我都会用实例的形式给出完整的代码,也希望大家多琢磨! 不是所有的应用程序都是一样的,也不是所有的系统都需要用复杂的架构来组织业务逻辑.作为开发人员,我们必须清楚每一种业务逻辑组织的模式,这样我们才能在需要的时候做出合适的选择. Transaction Script 这种组织业务逻辑的模式是最简单,也是最容易理解的.Transaction Script模式就是用面向过程的方式来组织业务逻辑的.通常情况下,系统的一个流程就

一起谈.NET技术,走向ASP.NET架构设计——第四章:业务层分层架构(后篇)

今天的内容比较简单,也是本章的一个收尾! Anemic Domain Model 这种模式和之前讲述的Domain Model有很多的相似的地方.在之前的Domain Model中,每个业务类都包含了自己的业务逻辑和数据,以及对象之前的关系:但是在Anemic Domain Model,每个业务类仅仅只是包含了一些保存业务数据的属性,把相应的业务规则从原本的业务类中移到了另外的一个专门的业务规则类(Specification Pattern,我们后面的章节讲述),同时把相应的业务方法移到了ser

走向ASP.NET架构设计第四章:业务层分层架构(后篇)

今天的内容比较简单,也是本章的一个收尾! Anemic Domain Model 这种模式和之前讲述的Domain Model有很多的相似的地方.在之前的Domain Model中,每个业务类都包含了自己的业务逻辑和数据,以及对象之前的关系:但是在Anemic Domain Model,每个业务类仅仅只是包含了一些保存业务数据的属性,把相应的业务规则从原本的业务类中移到了另外的一个专门的业务规则类(Specification Pattern,我们后面的章节讲述),同时把相应的业务方法移到了ser

走向ASP.NET架构设计第四章业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在

微服务架构设计(四):提升微服务分布式远程调用的可靠性与性能

在分布式微服务的架构下, 架构师往往面临著可靠性与性能间的抉择. 当来自某个微服务外部 Client 的远程调用, 要求微服务处理一购买 100 张股票的订单时.假如: A.  架构师所设计的微服务外部 Client 远程调用的 Time Out 时间是 2000 ms. 但, 此次微服务外部 Client 远程调用.微服务成功处理这 100 张股票的订单并送回一确认成功的信息到微服务外部 Client 时, 共花费了 3000 ms.所以, 微服务外部 Client 会误认为, 先前所发送的请