ios 的mvc

Posted 琴鸟

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ios 的mvc相关的知识,希望对你有一定的参考价值。

再一次理解mvc。到此结束。
一个程序,界面和数据放在一起处理,是混乱的源头,所以第一步就是要建立一个中间层来隔离view 和model.
所以自然形成mvc这3层,.这3层的通讯关系,比如control调用 model.可以包含一个model的接口,这样来降低耦合度。但实际上包含具体的model更常见,因为包含接口有设计过的之味。
但这3部分。v这个层比较特殊,因为view的中子控件变化是最频繁的,并且动作(方法)是很多的,所以和view  接触的control 在实际上一般不是control来调用 view的方法。
比如付钱后,更新界面,view并不会有一个方法叫 \'updateUiafterPay\' 来提供给control调用,而是control直接掌握view 的所有子控件,随意处理view.
基本上主流的界面系统。默认都是如此。
1.微软 web
后台页面可以直接获得view 的控件。(有一个隐藏的页面 xxx.design.cs 定义了所有的控件,提供给后台页面使用 ,并且会自动帮助注册事件)
2苹果 ios
没有微软那么细致,直接在前端页面注册了控件名字和绑定了事件,只是叫的好听了点,定义控件叫outle, 注册事件叫  target   action.
<所有系统都喜欢叫个不同的名词浪费大家时间> (用记事本打开storyborad文件可以看到)

<button 
<connections>
<action selector="onClickRight:" destination="BYZ-38-t0r" eventType="touchUpInside" id="aQ3-IE-GEf"/>
</connections>
</button>

<connections>
<outlet property="leftBtn" destination="Tmg-bu-8s9" id="6IX-K5-sjC"/>
</connections>

3.android
控件是默认会定义给control使用,事件的话默认需要自己注册;xxcontrol.setClickListener
 
可以看出,view由于变化大,逻辑细繁,导致和control天生就是紧密的。主流都是把他们捆绑在一起。所以
没有必要追求纯mvc,重点是mv需要彻底分离。control把业务逻辑再划分出来。
所以才导致了微软的三层结构非常流行。
导致mvvc在android .mfc也很流行。
反而mvc实际上流行不起来。
总结   
view ,control 无法分离 , 2者在一起统称为                                  UI 交互层。
control 需要把业务逻辑分离,control中的业务部分分类出来叫       bll逻辑层。
model一般和数据交互,所以可以叫做                                            dal数据层或者model层。
 
 
 
 
但简单mvc会出现vc过于紧密,意思就是control出现了xxbutton.settext("xxxx") .直接操控某个按钮。所以要隔离。隔离可以有2种方式
1.view写方法 public void setbutton{xxbutton.settext("xxxx")} .control调用方法setbutton. 什么,方法套一个语句,就隔离了?
是的,自己入门的时候,十分不能理解。调用一个只有一条语句的方法,和调用一个语句有什么区别?
 
那是因为自己还没有真正理解意图和实现的含义。刚接触接口以为意图和实现,专指的是接口。
后面发现有心的话很多东西都可以看作意图和实现,函数,文件,地址,等等。
虽然方法只包含一条语句。但是它包含的是实现(里面的一条语句),而提供了意图(public 出来的函数名)。函数名某种程度上也是意图,
所以函数也是可以实现开闭原则的。当然没有接口那么专业。
 
2.进一步三方最好通过接口沟通。这样三方,理想上,只要实现了接口,可以任意替换其中一方。就可以用来替换掉。非常符合开闭原则。但是个人觉得走入随时替换view的思路,已经太过了。mvc本意只是隔绝m和v,替换,呵呵,设计过度的味道。
 
 
mvc:逻辑:view 负责展示自己,并对control提出数据需求,control处理view的需求的时候,会对view提出界面修改的及接口需求,同时control会和model通讯的来获得数据,而不是自己直接获得数据。
所以整体上view是一个入口和出口,
而control是处理逻辑,是逻辑上的主导者,并对view 提出界面上的接口需求,对model提出数据上的需求。
以上是理论,实际上要考虑和系统的结合等因素。
参考.net  mvc 的框架。

ms的control是只处理业务逻辑的。倾向直接把数据给view,  界面的逻辑还是留给view自己处理。

对应于android 的项目,就是control最好不要进行太细节化的控制view.

如初始化 方法可以initview(map xx)这样前端可以拿到字典数据。自由处理自己界面。

用户动作可以xxdata clickOk()。这样control返回数据,操作交给view.   view得到数据自己安排自己的显示,而不是提供接口给control来调用。

 
 
纯mvc的理论指导意义大于实际。因为vc天然紧密且易变。导致接口数量繁多而且频繁变化,所以接口隔离不实际。
但是如果理想上,时间和精力成本非常低。那么用纯mvc非常好。反正人力多,前期累点,最后看起来舒服,view有什么功能一目了然,还可以进行ui单元测试。
但实际上要考虑具体实现,
如view或者control哪个先出来。还是有另外一个类来控制他们的生命?
所以更实际的操作是分层和 粗糙的mvc ,
如微软的三层结构。苹果的粗糙的mvc(vc有接口,但v也可以直接掌握view的具体控件)
分层,把业务逻辑从control中分离出来,把数据获得从control中分离出来。
粗糙的mvc,view可以提供自己一些的方法。把view的一些稳定方法,如初始,等方法。分离到粗糙的view。
对于ui逻辑和业务逻辑,在细小上无法定位一把准尺,某段代码是放入到view还是control。所以团队合作肯定会有不同意见。无法判断的准则,就不能成为准则。所以纯mvc不可靠。
分层,粗糙的mvc目的就是减轻control的负担,因为vc完全通过接口沟通不现实。
看看google的所谓实现了纯mvc, todo中的一个简单页面,,都还有那么多接口,就明白了。
当使用分层,粗糙的mvc之后,你就会恍然回忆mvc的目的是什么?目的就是变化隔离,适应修改。
而分层,粗糙的mvc,已经吧变化分离了大部分,
比方实现100%mvc需要100%劳动力。我们用40%的劳动力实现了80%的mvc,
为了剩下20%的变化,而需要60%的工作量,到底是否合算?这个自己衡量。
 

第二次小结
感觉纯mvc还是一个概念大于实用的模式。
纯mvc,
view必须是独立的,1.view自己有初始和修改,展示自己的各种方法,提供control使用,2.view应该含有一个实现了icontrol对象的接口,用于把用户动作所表达的数据逻辑给control.
control 1.应该有含有一个view对象,用于初始化view, 2. 应该有含有一个view对象修改view的样子来响应用户某个动作。
model 1,应该自己构建自己,并含有自己的各种操作逻辑 2. model的数据来源一般可以分离出来另外一个类,以便model 本身不含有非通用的动作(model放到不同的项目,可能数据来源动作不一致)

model 层是比较好理解和实际操作。并且符合实际。
但是view和control,好理解,但不符合实际操作,因为view的操作可以非常繁琐,如果把view的操作全部封装为方法,那么将非常耗费时间。
比如用户点击按钮修改按钮颜色,如果control含有view,那么可以直接取得按钮,并修改按钮的颜色。但是如果纯mvc。control必须通过view的一个方法如,changeXXButtonColro(),
如上,view必须含有很多的方法。而且会处理频繁的修改中。
很多mvc的模式教程都会开篇说,为了把vc解耦,之后巴拉巴拉,试过,思考过好几种mvc,自己的感觉就是vc不适合解耦,vc天然的紧密,不但紧密,而且变化修改相当频繁。
今天按钮的作用是修改颜色,明天可能修改颜色和另外一个按钮的大小。后天可能不变。再后天这个功能还是取消。
所以vc不需要分离。但是可以把control进行分层。分离出一个逻辑处理层。control既然和view 那么紧密,那就紧密吧。但是control除了和view的逻辑以外,其他逻辑全部分离出去。
这就是我们的分层,所以一般分离出一个逻辑层。逻辑层中又可以把处理数据部分的逻辑分离出去。处理数据层,又可以把缓存和数据库分开处理。
就好象面向对象设计很正确的概念,但最终被面向组合,面向接口所代替。

mvc 那就没有实际了意义?其实稍微想下,从某种意义,view已经是分离出去了。比如按钮,他就是一个view啊。修改按钮的大小如 btn.setsize().这个方法,已经由系统帮你实现了啊。我们不需要在control中去实现setsize()这个方法。我们在control操作的view的控件。就已经是在操作view的方法,已经是部分mvc了。 view 不单是指整个界面,view看作单独的控件。就有所安慰了。
纯mvc,是不错,但是耗费人力,精力。个人感觉,满足2条之一就可以用。


1.必须要有人员充足,甚至需要有多余的劳动力去处理view的分离。或者有工具提供了自动机制。
2.这个可能是纯mvc的有必要的理由,如果你的项目ui层,足够复杂,用户的每一个动作,都会引起界面各种复杂的变化。那么需要进行ui层的单元测试。
ui层的单元测试,那么就必须把ui的方法独立出来,不能混合业务逻辑和数据。只需要ui逻辑。那么view就有了充分独立出来的理由。也就有了纯mvc的理由。
存在每一个动作,都会引起界面各种复杂的变化的app吗?基本不存在,所以纯mvc的指导,理论意义大于实际。

 
 
 第一次小结
android mvc
 
看了官方的todo的mvp的例子。无法接受这种模式,严格的分离导致,view 的繁琐。
基本的mvp不好。
不喜欢v c的沟通是通过接口沟通。不喜欢view把显示自己封起来,让control来调用。这样view会有很多的细节操作,需要自己一个一个全部包装起来。
仔细想想,如textview, 的方法 settextview. 。我个人觉得settextview的实现已经是view了。而调用settextview这是是control。不再需要view去包一层方法,那个已经是逻辑了。
就该由control来控制。总结就是 view把显示自己封起来的方法,不应该是view,而应该是control。view的渲染任务止步于 这些控件本身的 ondraw.
完全的隔离,必然需要更细节的沟通。
所以,
view: 静态xml或代码技术,放置好控件。就应该是view所做的全部任务。view的渲染任务,止步于它自己最底层的draw方法。
conrol:可以直接获得控件,不应该让view封装方法,而感知逻辑,就算是显示也不行,如果显示全部由view控制,那么必定会非常繁琐。
直接让control获得view,并控制显示view。 这个其实是control,而不是view的显示范畴。view的渲染任务,止步于它自己的最底层的draw方法.
bal:因为control的任务会比较多。所以必须设置bal.把独立出来。
model:本地或远程数据。
 
先学习的ios,后学习的android。
发现对于mvc 的态度一致。还是喜欢 弱iew,强 control. control稍微包含多一点。所以分出一个business等。
微软已经死掉的asp.net ,虽然死掉了。但是它的分层模型却是非常简单,有效。view<--->control<---->business<---->Model
 
 
IOS 的mvc
 

 

 
综述:所有的运用程序,都逃不开展示和互动。
view:        负责创建界面元素,界面布局,负责接收外部互动,并通知control处理。
control: 负责控制view元素的实际数据,负责处理view发过来的动作的逻辑处理。并在处理逻辑中,在界面方面的操作上对view提出的接口需求,当然也负责从model获得,保存数据
model:     负责数据模型的逻辑,通常还有另外一个数据获得帮助类。(如Book 和BookDBHelper类)

 

 
因此==>
view:1,应该有一个方法初始化创建元素: initUi  ..2. 所有元素都可以公开给control,以便展示实际数据。3  提供外对接口,并执行接口函数,实际由control来实现。 protocal: onclick
control:1..应该拥有view. 如可以先执行view的初始方法。并得到view. self.view=xxx ==>getSomeControl. 2..实现view 的接口 <pagePortocal>   3  实现某些系统封装好的元素的接口如  .ios \'s protocal .eg:table delegate.
model: getlist ,updatesomemode. ,观察数据变动。并向订阅者发送通知。
 
因此,任何control,只要创建一个view的实例,并实现接口。都可以很好接管view.甚至可以管理多个view.
而view是独立的,不依赖于control.
 
其实可以推广到大多数的程序结构。
如.web.
html负责创建和布局。并负责post 数据到服务端处理。
服务端处理互动事件。asp.net ,可以知道任何view的元素并进行数据显示。
 
 
 
 
 

综述:所有的运用程序,都逃不开展示和互动。
view:负责创建界面元素,界面布局,负责接收外部互动,并实现一个可注册的机制,负责公开所有必须的组件元素,提供给control来实现互动和其他功能。
control:负责控制view元素的实际数据,负责注册互动事件和实现事件。负责从model获得或发送数据。
model:保存数据,并响应control的请求。

所以v和c通讯的话,没有完美的分隔。比如注册机制,要完美的话,应该是每个控件都提供接口。让control来实现。
但是这样就非常繁琐,所以在控件的基类中,提供注册机制,而让control自己来注册,虽然暴露了控件,不但获得的灵活和简便,而且也是必须的。
两个模块的通讯可以完全隔离,用派生类需要的接口实现(已经注册好,让调用方实现),也可以让基类实现接口让一个有主动控制权(主动注册和实现)
对于 V和C感觉还是让control有更多控制权,完全掌握view。view只做2件事情:建立控件,布局控件。


!!!!!!!!觉得可以写个例子模拟一下。注册机制和接口机制。2种事件驱动模式。
对于get,set有了新的一个理解。之前的理解是通用的,就是封装性。后面发现其实还是 1.延迟加载2.减轻程序复杂压力。
1.当用的时候才执行get.不必要再某个地方集中get.避免浪费资源。因为有可能这个属性这次操作根本没用到。
2.也可以省去心思思考某个变量放在那里初始化,特别是写某些脚本程序的 时候,用户接触的类基本是派生类,初始化一般不会去overwrite.

以上是关于ios 的mvc的主要内容,如果未能解决你的问题,请参考以下文章

漫谈iOS中的MVC

iOS -MVC

iOS开发之理解iOS中的MVC设计模式

iOS 基于 MVC 的项目重构总结

iOS中的MVC设计模式

iOS开发设计模式之MVC