iosmvc开发模式,iosmvvm设计模式
iOS中的MVC和MVVM
MVC的实现思路是：用户操作View，在Controller层完成业务逻辑处理，更新Model层，将数据显示在View层。
创新互联公司专注于连云企业网站建设,成都响应式网站建设,商城建设。连云网站建设公司,为连云等地区提供建站服务。全流程按需搭建网站，专业设计，全程项目跟踪，创新互联公司专业和态度为您提供的服务
在MVC中，每个层之间都有关联，耦合比较紧，在大型项目中，维护起来比较费力。
View把控制权交给Controller层，自己不执行业务逻辑；Controller层执行业务逻辑并且操作Model层，但不会直接操作View层；View和Model层的同步消息是通过观察者模式进行，而同步操作是由View层自己请求Model层的数据，然后对视图进行更新，观察者模式可以做到多视图同时更新。
Person.h
Person.m
TestView.h
TestView.m
ViewController.m
MVVM和MVP的最大区别是采用了双向绑定机制，View的变动，自动反映在ViewModel上。
MVVM结构如图：
模型层：
Person.h
Person.m
视图层：
TestView.h
TestView.m
PersonViewModel.h
PersonViewModel.m
ViewController.m
iOS的两种项目架构模式--MVC模式、MMVM模式
iOS的项目架构一般是使用这两种模式构建出来：MVC模式、MMVM模式。
MVC模式使用还是非常常用和普遍的，而对于MMVM模式则是一般会在项目考虑频繁View-Model交互情况下使用。
ios开发有没有必要将service层单独出来
有必要，遵循mvc的设计模式就可以
MVC是构建iOS App的标准模式。然而，最近我已经越来越厌倦MVC的一些缺点。在本文，我将重温一下MVC是什么，详述它的缺点，并且告诉你一个新的方式来架构你的App：Model-View-ViewModel。拿出你的流行语bingo card(宾果卡，一种游戏卡片-译者注)，因为我们即将进行一次范式转变。
Model-View-Controller
Model-View-Controller是一个用来组织代码的权威范式。Apple甚至是这么说的。在MVC下，所有的对象被归类为一个model，一个view，或一个controller。Model持有数据，View显示与用户交互的界面，而View Controller调解Model和View之间的交互。
在上图中，view将用户交互通知给controller。view controller通过更新model来反应状态的改变。model（通常使用Key-Value-Observation）通知controller来更新他们负责的view。大多数iOS应用程序的代码使用这种方式来组织。
模型model的对象通常非常非常的简单。很多时候，他们就是Core Data managed objects，或者避免使用Core Data，就是其他流行的数据模型层。根据Apple的文档，model包括数据和操作数据的业务逻辑。在实践中，model层往往非常薄，不管怎样，model层的业务逻辑被拖入了controller。
视图view通常是UIKit控件（component，这里根据习惯译为控件）或者编码定义的UIKit控件的集合。进入.xib或者Storyboard会发现一个app、Button、Label都是由这些可视化的和可交互的控件组成。你懂的。View不应该直接引用model，并且仅仅通过IBAction事件引用controller。业务逻辑很明显不归入view，视图本身没有任何业务。
还有控制器controller。Controller是app的“胶水代码”：协调模型和视图之间的所有交互。控制器负责管理他们所拥有的视图的视图层次结构，还要响应视图的loading、appearing、disappearing等等，同时往往也会充满我们不愿暴露的model的模型逻辑以及不愿暴露给视图的业务逻辑。这引出了第一个关于MVC的问题...
厚重的View Controller
由于大量的代码被放进view controller，导致他们变的相当臃肿。在iOS中有的view controller里绵延成千上万行代码的事并不是前所未见的。这些超重app的突出情况包括：厚重的View Controller很难维护（由于其庞大的规模）；包含几十个属性，使他们的状态难以管理；遵循许多协议（protocol），导致协议的响应代码和controller的逻辑代码混淆在一起。
厚重的view controller很难测试，不管是手动测试或是使用单元测试，因为有太多可能的状态。将代码分解成更小的多个模块通常是件好事。
遗失的网络逻辑
苹果使用的MVC的定义是这么说的：所有的对象都可以被归类为一个model，一个view，或是一个controller。就这些。那么把网络代码放哪里？和一个API通信的代码应该放在哪儿？
你可能试着把它放在model对象里，但是也会很棘手，因为网络调用应该使用异步，这样如果一个网络请求比持有它的model生命周期更长，事情将变的复杂。显然也不应该把网络代码放在view里，因此只剩下controller了。这同样是个坏主意，因为这加剧了厚重View Controller的问题。
那么应该放在那里呢？显然MVC的3大组件根本没有适合放这些代码的地方。
较差的可测试性
MVC的另一个大问题是,它不鼓励开发人员编写单元测试。由于view controller混合了视图处理逻辑和业务逻辑，分离这些成分的单元测试成了一个艰巨的任务。大多数人选择忽略这个任务，那就是不做任何测试。
定义模糊的“Manage”
之前我提到了view controller可以管理试图的层次结构；view controller有一个“view”属性，并且可以通过IBOutlet访问视图的任何子视图。当有很多outlet时这样做不易于扩展，在某种意义上，最好不要使用子视图控制器（child view controller）来帮助管理子视图（subview）。
要点在哪？验证用户输入的业务逻辑应归入controller还是model呢？
在这里有多个模糊的标准，似乎没有人能完全达成一致。貌似无论如何，view和对应的controller都紧紧的耦合在一起，总之，还是会把它们当成一个组件来对待。
Hey！现在有个点子...
Model-View-ViewModel
在理想的世界里，MVC也许工作的很好。然而，我们生活在真实的世界。既然我们已经详细说明了MVC在典型场景中的问题，那让我们看一看一个可供替换的选择：Model-View-ViewModel。
MVVM来自微软，不过不要坚持反对它。MVVM和MVC很像。它正式规范了视图和控制器紧耦合的性质，并引入新的组件。
在MVVM里，view和view controller正式联系在一起，我们把它们视为一个组件。视图view仍然不能直接引用模型model，当然controller也不能。相反，他们引用视图模型view model。
view model是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他各种各样的代码的极好的地方。有一件事情不应归入view model，那就是任何视图本身的引用。view model的概念同时适用于于iOS和OS X。（换句话说，不要在view model中使用 #import UIKit.h）
由于展示逻辑（presentation logic）放在了view model中（比如model的值映射到一个格式化的字符串），视图控制器本身就会不再臃肿。当你开始使用MVVM的最好方式是，可以先将一小部分逻辑放入视图模型，然后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。
使用MVVM的iOS app是高度可测试的；因为view model包含了所有的展示逻辑并且不会引用view，所以它可以通过编程方式充分测试。虽然有众多的hack技术参与到测试Core Data模型，但使用MVVM写的app可以进行充分的单元测试。
以我的经验，使用MVVM会轻微的增加代码量，但总体上减少了代码的复杂性。这是一个划算的交易。
你可以使用KVO，就像MVC那样，但这很快就会变得难以管理。事实上，使用ReactiveCocoa会是更好的方式来组织各个部分。
有没有自学 iOS 开发的一些经验
基础
一定的编程经验
这里说的编程经验是至少熟练一门编程语言，对 OOP 有一定的了解，最好熟悉一些基本的设计模式。遇到过的好多 iOS 开发，大多是从别的语言转过来的，所以有一定的编程基础，学起来会更容易 get the point.
如果是第一次接触编程，当然也是没问题的，只是要做好心理准备，可能会比想象的难。
英语
发现不少开发对于英语似乎有点接受不能，通常都是中文优先，除非迫不得已，才硬着头皮看看 StackOverflow，英文文章，文档等。忘了是谁说过「难走的路越走越好走」，通常如此。其实只要稍微 push 一下自己，那些技术文章啃下来应该不会有太大的问题，有过几次成功的体验后，这种恐惧感就会减少很多。优质的文章、视频、书籍，多是英文的，不迈过这个 坎，将来要么成为瓶颈，要么花更大的成本去填补。
入门
书籍
要学习 iOS 开发，自然要先学 Objective-C （当然现在也可以直接上 Swift，不过如果多人协作的话，OC目前还是主流），因为 OC 是 C 语言的超集，所以了解 C 语言对于学习 OC 肯定会有帮助，不过就算不了解，直接学 OC 也没太大问题。
这里推荐 BNR (Big Nerd Ranch) 的这本 Objective-C Programming The Big Nerd Ranch Guide，讲解地比较细致，能帮助你更好的理解 OC，更重要的是教你遇到问题时，如何去解决问题，以及这个问题对应的一些知识点，如何使用文档等等。
来到一个新的世界，肯定会对这个世界充满好奇，想订阅一大堆博客，买一堆书，看各种教程和视频，然后就变得浮躁，不知该从哪下手，这会导致拖延症。 我渴了，给我倒一杯水，这个很直接，马上就可以做，但如果是给我买一瓶饮料，而自己对那些饮料又不怎么熟悉时，就纠结了，不如刷会微博，看看朋友圈，玩个小游戏先。
所以一本好的入门教材很重要，要契合自己当前的水平，且常常会有收获，这种成就感会激励着你继续学下去。
在看书的过程中，往往会有这样的经历：书中提到某个人、观点、知识点、书、文章，然后就顺着它提到的这些东西出去了，可能某个知识点又牵扯到另一些内容，然后就这样越走越远。想起了一个故事——
三只猎狗追一只土拔鼠,土拔鼠逃跑时钻进了一个树洞。这个树洞只有一个出口,不一会儿,忽然从树洞里跑出一只兔子。兔子飞快地向前跑,并爬上另一棵大树。兔子因为慌乱在树上没站稳,掉了下来,砸晕了正仰头看的三只猎狗,最后,兔子终于逃脱。
对于这个故事可以从不同的角度去解读，我更愿意以初心去解读。兔子为什么会爬树？为什么能砸晕三只猎狗？这不是重点，重点是，之前追赶的土拨鼠哪去了？看书时难免会有延伸阅读，这个深度我觉得不宜超过 2 层，不然很容易就回不来了。
还有就是如果有可能，最好每天都看点，这其实是很难的，因为总是会有优先级更高的事，或者之前的某些习惯在干扰。一旦断了几天，就不想再拿起来了。
还有，苹果官方的 Start Developing iOS Apps Today 也是很不错的入门材料。
视频
推荐斯坦福老头子(Paul Hegarty)的 Developing iOS 7 Apps for iPhone and iPad ，当初也是看的这个（那时还是更老的版本），Paul 是资深的 Mac/iOS 开发（前苹果员工？），很多知识点讲得很到位，学生们的提问也大都在点上，同时配有Demo，总之听下来会对 iOS 开发有比较全面的了解。
同时推荐一本小册子：objc-zen-book，花不长时间就能看完，里面是一些 Best Practices，对于编写优质代码会很有帮助。
笔记
这是一个持久的过程，任何阶段都适用。以前也没太在意这个，觉得概念性的东西，脑子过一遍，就大概知道了，然后就去啃其他的东西了，现在看来，如果有记笔记的话，会更有助于消化概念、知识点，也可以记录自己的思考过程。达芬奇就记录了10000多页的笔记。
记笔记可以加深对知识点的理解，而成为编程巨星的唯一秘诀就是：对所做的事情理解地越深，就会做得越好。同时如果遵循遗忘曲线去复习的话，效果更佳。对知识点了解地足够透彻后，Debug 时才更有可能知道问题出在哪，解决问题也更容易有思路。
笔记不仅可以记知识点，也可以记录调试过程，比如这篇笔记，有一种调试方法：小黄鸭调试法
许多程序员都有过向别人（甚至可能向完全不会编程的人）提问及解释编程问题，就在解释的过程中击中了问题的解决方案。一边阐述代码的意图一边观察它实际上的意图并做调试，这两者之间的任何不协调会变得很明显，并且更容易发现自己的错误。
生活中我们可能不会真的这么去做，这时抽离出另一个自己，记录下跟ta的对话，也是个发现问题的好方法。
练习
这也是一个持续的过程，知道了些概念或原理后，总是会想着去验证下是不是这样，无论结果是否如自己预期，实践的过程会降低对语言的陌生感，慢慢地培养一种驾驭这门语言的自信，如果出了错，正好可以重新梳理一下。
目标
如果静下心来看完了 BNR 的这本书，以及斯坦福的 iOS 开发视频，那么对 OC 应该比较了解了，一些常用的 UIKit 用起来也没什么问题了，比如 UIViewController / UIView / UIScrollView / UIImageView / UITableView。也熟悉一些概念，如 KVO / MVC / Delegate / DataSource。
这个阶段下来，应该会有：哦，iOS 开发也就这样嘛，多翻翻文档，熟悉 Cocoa Touch 的一些 Class，差不多也能做出一个简单的 App 了。
进阶
入门之后，接下来可以折腾的东西还会有不少。
书籍
Effective Objective-C 2.0，里面提到了 52 种提高 iOS App 质量的途径。涉及了 API 设计、protocols / category 的使用、写出更模块化的代码等，读下来应该会有不少收获。
iOS Programming: The Big Nerd Ranch Guide (4th Edition)，又是一本 BNR 的书，这本书的特点是通过 Demo 来引出知识点，然后提一些问题，并且会细说解题思路。看书的过程中，对于元学习能力的提升也会有一定帮助。
--- update ---
发现巧哥的 iOS开发进阶 已经可以在京东买到了，虽然没有细看，但巧哥出品质量肯定有保障。
其他资源
进入这个阶段后，可以去探索更大的世界了，现在的资源已经很丰富了，但还是要遵循「少而精」的原则。以下是我觉得挺不错的资源
iOS Dev Weekly 每周一期，内容多为这一星期里值得关注的Github项目、文章、工具等。
iOS 移动开发周报 这是唐巧大大整理的每周不错的 iOS 开发相关的内容，多为中文。
RayWenderlich 很多详细又全面的教程，不容错过。
iOS Dev Slack 国内不少 iOS 开发（包括大大们）都在这里，不过现在好像不怎么能拿到邀请了。
中文 iOS/Mac 开发博客列表，打开工具订阅吧。
还有，如果可能的话，多去分享自己学到的东西，教是最好的学，我试过几次，效果真的很不错。
目标
这个阶段下来，对于常用的设计模式、内存管理、Blocks 的使用、图像操作、网络请求和管理、多线程应该比较熟悉了。对于 CALayer、Animation、UIScrollView、UITableView、UICollectionView、 ViewController Container 则非常熟悉，对「非常熟悉」的定义是：不打开 Xcode，脑子里就能把相应的知识点复述出来 80% ，比如这个类有哪些方法，Delegate / DataSource 有哪些方法，怎么使用，如果要实现某个效果，应该怎么做（好吧， UICollectionView 除外）。
高级
其实高级、进阶、入门并没有严格的界限，在入门阶段也可以探究高级阶段的一些东西。我觉得支撑我们不断探索和前进的动力不是兴趣，而是永不满足的好奇心，和对优雅代码的追求。
If your standards are low, you're going to stop pretty early on in the process.
BNR 的这篇 Leveling Up 已经讲得很好了，也更加细致。
书籍
iOS 7 Programming Pushing the Limits 这本书对 iOS 7 的一些特性会讲解地比较深入，当然也不仅仅是 iOS 7。只叹 iOS 更新实在太快，书籍往往跟不上，一本好书往往需要很长时间来撰写，等书可以出版了，iOS 又出新版本了。
源码
看优秀的源码，可以学到很多东西，使用过程中遇到问题也更容易解决。这些是我觉得值得细看的源码：AFNetworking(NSOperation, HTTP, Block), SDWebImage(Image Handle, Cache, NSOperation, Block),SVPullToRefresh(UIScrollView, State Handle), JSONModel(runtime)
如果有兴趣，也可以翻翻 CoreFoundation / OC runtime 的源码。
资源
oleb
NSHipster
objc.io || objcio.cn
WWDC 视频
工具
chisel Facebook 出品的 LLDB 助手，用于调试很方便
Reveal 每当好奇某个 App 的实现时，都会打开它一窥究竟，用于调试自己的 App 也很方便
Aspects steipete 大大出品的一款方便使用 method swizzling 的工具，可以在运行时动态添加代码到某个方法
class-dump 从 Mach-O 文件生成 OC 头文件，有时想看看某个 App 大概是如何组织的会比较方便
Hopper 可以对二进制文件进行反编译，甚至可以生成伪代码！有时想看看 UIViewController 里某个方法大概是怎么实现的，就可以用它。
Instruments 这个内置的工具对于发现 App 的各种问题很有帮助，如内存占用、泄露，渲染问题等。
目标
这个阶段，对于底层的实现会有更深入的了解，各种 Core 开头的 Framework 至少可以说出个大概，工具也能熟练使用，「正经的代码」写过数万行，可能天天在翻 Dash。如果别人让你实现某个功能，能在较短的时间内给出不错的实现方案，并且足够细致，甚至精细到如何使用 Core Graphic 去画某个图像。
其他
我觉得无论学习什么，「速成」的心态是最要不得的，这只会让自己变得浮躁，一知半解，整个过程也很难让自己的元学习能力得到提升。慢慢来，攻占一个城后，再去打下一个，这时心态也会平和许多。
当前标题：iosmvc开发模式,iosmvvm设计模式
当前URL：http://myzitong.com/article/phdjph.html