再一次理解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.
