目录

直白都有人撰文吹捧MVVM应用开发框架,作品把MVVM说的动听并且批评包括iOS和android所用的MVC经典框架。这篇著作就是想给这一个捧臭脚的众人泼泼冷水,即使有可能导致骂声一片,可是目标是给那么些刚入门的同伙一些参照和指出,以免误入歧途。同时也给那个深陷其中无法自拔的伴儿们敲敲警钟,以免其在错误的征途上越走越远。

—— MVVM并非框架,而只是简单的文本夹分类 ——

MVVM被引入的前因后果

大体是在二零一零年左右运动端支出火了四起,起首是iOS,Android,
WinPhone六个大平台竞争,后来膝下退出了争夺,变成了二分天下。从使用系统布局以及为开发者提供的框架体系来看,六个平台都是生产了经典MVC三层构造的开发情势,这三层所代表的含义是模型、视图、控制。那多少个开发框架的初衷其实也很简短:视图负责体现和渲染,模型负责作业逻辑的实现,控制负责调度视图的轩然大波以及业务逻辑的调用以及通告视图的基础代谢布告。
三片段松散耦合,各司其职。下边是经典的MVC框架结构:

[图片上传失利…(image-1d68cb-1512992093070)]

一个很可惜的谜底是无论是Android和iOS都只对C和V两部分进行了正式的定义和兑现:Android的视图部分的兑现是概念了各样控件以及经过XML文件来组装视图布局界面,iOS的视图的落实也是概念了各类控件以及因而XIB或SB来组装视图布局界面;
Android的支配部分则是经过Activity来兑现,而iOS的决定部分则是透过UIViewController来实现的。而模型部分吗?因为每个应用的作业逻辑和采用场景并不相同,所以多少个阳台也无力回天也不可知定义出一个通用的模型层出来,而是把模型层的定义留给了开发者来兑现。然则这为大家的开发者在采取MVC框架开发应用时埋下了隐患。

先前时期的利用开发相对简单,因为从没标准的模型层的概念,而控制层又在工程变更时留下了累累可供开发者写代码的地点,所以重重开发人员就自然则然的将工作逻辑、网络请求、数据库操作、报文拼装和剖析等等全体代码都放入了控制层里面去了,根本就不需要咋样模型层的概念。
这样随着时光的延迟和利用的扑朔迷离扩展,就涌出了C层膨胀的动静了。一个控制器的代码可能出现了好几千行的现象。于是乎有人就起来找解决方案来为C层瘦身了。又一个很心痛的谜底是还不曾人去想着抽象出M层,而是用了如下方法来化解问题:

  • 客户端和服务器之间交互的数量报文是否足以定义出一个个只有属性而尚未章程的数目对象呢?这样在处理和渲染界面时就不需要和原有的XML或者JSON或者其他的格式报文交互了,只要操作数据对象就好了。于是解决方案就是依照客户端和服务器之间交互报文定义出一个个的数据模型,然后再付出出一套XML或者JSON和数据模型之间互转的解析器来。最终将这多少个个只有数据而没有主意的对象数据模型统一置于一个地点,然后给她们定义为M模型层(呼!终于给出模型层的概念了,然而:Are
    you kidding
    me??)
    。那样C层就不会再冒出XML或JSON解析以及从来读取报文的代码了!而是把这有的代码挪到模型层了(我们来看呀,我毕竟应用上了MVC框架了!)
    好了!瘦身第一步成功。但是只是,问题还在啊,我的政工逻辑如故一大片在C层啊,看来MVC这种框架也只是这样啊!根本没有解决我的题目。不行,我无法再用MVC这种框架来支付自己的应用了,我要另找它法,要继续对C层瘦身。

  • 自己的某部界面和某个业务逻辑是绑定在一块的,这么些界面的显得是经过调用某个业务逻辑来贯彻的,业务逻辑完成后要直接更新这些界面。这种环环相扣的调用和换代关系一直就不需要C层的涉企。因而能够将这有些界面的翻新刷新和工作逻辑的调用绑定在联合,
    二者结合为一个查封而单身的完全并形成独立的类。这样把这些类的代码抽离出来了,存放到一个独门的文书夹中。我把那么些局部叫什么好吧?对了就叫视图模型层VM吧!视图模型层中的类定义了一个给外部使用的绝无仅有接口来供C层调用。这样自己好不容易把一大一部分代码从C层中抽离出来了。我已经打响的实现了C层的更加瘦身,并抽象出了一个视图模型层了!(不过哪儿好像不对,视图模型层设计到了视图、模型、视图模型层三方面的交互和耦合)
    可是没有提到,反正我的C层进一步瘦身成功了!,我看看还好仍旧不好连续瘦身C层?

V和VM以及M之间的借助关系

  • 自家的洋洋视图的轩然大波是在C层中拍卖的,那我是不是足以把C层的事件处理也拿出去吧?
    干脆就拿出来吧。可是怎么拿出去啊?于是乎我又不停的搜寻,终于找到一个叫RAC的东西了,那些东西好哎,他可以负担处理视图的各种风波,以及可以承担连续的网络调用。等等。。。
    RAC就是有点晦涩难懂!难以学习,代码难以阅读和调剂。咋做?
    没有关联,只假如能将C层的代码瘦身这个又算怎么。。。大不断就是多趟一点坑,多搞五回培训就好了。
    嗯! 就这么办,这自己把这有的代码也放入到VM层里面去啊。

    。。。。呼!!!
    C层终于瘦身成功。然后我们看呀,我的C层里面确实是如何代码也未曾了。。。
    它不再处理视图的轩然大波了,因为事件让RAC给处理了、它也不处理视图的基础代谢和事情逻辑的调用了因为让视图模型MV给处理掉了、他也不处理数据的解析了因为让模型层给替换掉了。嗯。。。。我要给这种没有C层或者不需要C层的框架起个名字,叫什么好吧?
    就叫:MVVM吧。。。
    我的采纳可以毫无C层了,然后自己就奔走相告。将C层无用大白于天下。。

真的是这般吗?答案是NO!!!

第一自己想说的是一个佳绩的框架中各层次的拆分并不是大概的将代码举办分拣和细分,**层次的划分是横向的,而模块的分割则是纵向的
** 。
那其中涉及到了层次之间的耦合性和天职的划分,以及层与层之间的互相接口定义和章程,同时层内的筹划也应当具有中度的内聚性和结构性。而那么些计划的要求并不曾在所谓的MVVM中反映出来。

  • 首先要正确的了解MVC中的M是什么?他是数据模型吗?答案是NO。他的正确性定义是事情模型。也就是您具备事情数据和事情实现逻辑都应当定义在M层里面,而且工作逻辑的兑现和概念应该和实际的界面无关,也就是和视图以及控制之间从未此外的涉嫌,它是可以独立存在的,您依旧足以将工作模型单独编译出一个静态库来提供给第三方或者其他系统采用。在地点经典MVC图中也很清晰的叙述了那点:**
    控制负责调用模型,而模型则将处理结果发送通告给控制,控制再通报视图刷新。因而我们不可以将M简单的理解为一个个平淡的只有属性而尚未艺术的数据模型。其实这之中涉及到一个最中央的计划性标准,这就是面向对象的着力计划标准:就是什么样是类?类应该是一个个有所相同操作和见仁见智属性的对象的肤浅。
    我想前日其他一个系统里头都不曾出现过一堆只有数量而尚未主意的数据模型的会聚被定义为一个独门而肤浅的模子层来供我们使用啊。**
    我们不可以把一个保存数据模型的公文夹来作为一个层,这并不合乎横向切分的条条框框。所以说MVVM里面的所谓对M层的定义就是一个伪概念。

  • 地点我一度表达M层是工作模型层而非数据模型层,业务模型层应该封装所有的事务逻辑的实现,并且和切实视图无关。大家不可以将一个视图的表现逻辑绑死在一个事情处理逻辑之中,因为有可能存在一个政工逻辑有多种不同的展现模式,也可能界面呈现会趁着应用升级而转变,可是事情逻辑是绝对安静的。尽管是某个视图确实就跟这多少个工作是一环扣一环耦合的,也不应当做强耦合绑定。所以地点所谓的VM这种将视图的显得和作业的拍卖逻辑绑定在一块是老大稀松的主意,因为这么的计划形式已经完全违背了系统里面最中央的显得和促成应有分别处理规范。而且这种规划的盘算是和分层的视角是反其道而行之的。因为她出现了视图和业务的紧耦合和相互双向依赖问题,以及和所谓的M层也要紧耦合的存在。所以说MVVM里面所谓的VM层的概念也是一个伪概念。所谓的VM层这多少个中只可是是按页面举行的意义拆分而已,根本就谈不上所谓的层的定义。

  • 再来说说事件处理。经典的C层设计的目的是负责事件处理和调度,不论是按钮点击仍然UITableview的delegate以及ListView的Adapter都最好放在C层来处理,这也是符合C层最本色的定义:就是C层是一个担当调度和控制的模块,它是V层和M层的粘合剂,他的功效就是拍卖视图的事件,然后调用业务逻辑,然后接受工作逻辑的处理结果通告,然后再通告视图去刷新界面,这就是C层存在的意义。而且系统默认也是按这些形式设计的。而RAC的产出则将这部分的拍卖给活生生的代表掉了。也就是经过RAC所谓的响应式和触发式这种体制就能落实将事件的调度处理放在其他地点其他时候都能不负众望。这样做的目标使得我们可以疏散和释疑代码。但结果出现的问题吧?就是同一个单元调度处理逻辑和功力的构建完全放在了一个地点,但不同的单元逻辑的又分散在不同的地方,无法去分类统一保管和珍爱。由此你无法一下子就知道某个意义有着调度到底是什么样兑现以及在哪儿实现的。因为RAC将效用构建和事件处理完全粘合到一个大的函数体内部,并且是代码套代码的格局,这种艺术严重的毁伤了面向对象里面的构建和拍卖分离的设计形式理论。更麻烦的是其高昂的就学和珍爱资产,代码阅读了解困难,以及无处不在的闭包使用。试想一下那多少个对于一个初专家的话是不是噩梦?,一旦出了问题对于保障和代码调试是不是噩梦?而且使用不当就会油不过生循环引用的不得了问题。那样一来原本C层一个调度总管的天职被RAC来接管后,那一个处理将变得分散和无序,当我们要做一些集合的管住比如HOOK和AOP方面的事物时就变得不能动手了。
    不可否认的是RAC在处理连续调用以及各种响应方面有必然的优势。一个例子是大家或许有连续的六个跟服务器的网络请求,这时候用RAC举行这种拍卖能方便的解决问题。可是自己想说的是当存在这种情况时,大家更为应该将这种连接的网络调用在M层内部消化掉,而只给C层提供一个概括而便利的接口,让C层根本不需要关爱这种调用的连续性。由此可以说为了把C层的代码给消化掉而引入RAC的体制,不仅没有简化掉系统反而下跌了系统的可维护性和可读性。RAC机制根本就不符合用在事件处理中。大好的接纳和框架并不在代码的数码,而是完全系统的代码简单易读,各部分任务明确,容易保障的调节

—— MVVM被引入的根本原因是对M层的错误认识所引起的 ——

MVC中M层实现的清规戒律

说了那么多,可以总计出所谓的MVVM其实并不是一种所谓的框架或者格局,他只是一个伪框架而已,他只是将效率和拍卖按文件夹的法子展开了细分,最后的的结果是系统乱成了一锅粥。毫无层次可言,所独具的绝无仅有亮点是把C层的代码和效果完全弱化了。其实出现这种计划方法最根本的因由就是没有对M层举行不易的知晓定义和拆分。那么我们理应如何正确的来定义和筹划M层呢?下边是自家个人认为的几个准则(也许跟其别人的观点有出入):

  • 概念的M层中的代码应该和V层和C层完全无关的,也就是M层的对象是不需要依靠任何C层和V层的目标而单独存在的。整个框架的计划性最优结构是V层不依赖C层而单身存在,M层不倚重C层和V层独立存在,C层负责关联二者,V层只承担映现,M层持有数量和事情的切实实现,而C层则处理事件响应以及工作的调用以及通报界面更新。三者之间自然要明显的定义为单向依靠,而不应该出现双向依赖。下面是三层的倚重性关系图:

三层之间的单向依靠关系

除非当你系统规划的不同部分都是单向依靠时,才可能有利于的开展层次拆分以及各种层的法力独立替换。

  • M层要做到对作业逻辑实现的包裹,一般工作逻辑最多的是关联到客户端和服务器之间的工作交互。M层里面要水到渠成对应用的网络协议(HTTP,
    TCP,其他)、和服务器之间交互的数码格式(XML,
    JSON,其他)、本地缓存和数据库存储(COREDATA,
    SQLITE,其他)等有着事情细节的包裹,而且这么些事物都不可能透露给C层。所有供C层调用的都是M层里面一个个业务类所提供的积极分子方法来落实。也就是说C层是不需要知道也不应当了解和客户端和服务器通信所接纳的任何探讨,以及数据报文格式,以及存储方面的内容。那样的补益是客户端和服务器之间的通信协议,数据格式,以及地面存储的改变都不会影响其他的应用全部框架,因为提供给C层的接口不变,只需要提升和立异M层的代码就足以了。比如说大家想将网络请求库从ASI换成AFN就如若在M层变化就可以了,整个C层和V层的代码不变。下边是M层内部层次的定义图:

M层内部的卷入层次

  • 既是我们的利用是一个整机但又分模块,那么业务层内部也相应按效能模块举办协会划分,而不应有简单且平面的遵照和服务器之间通信的接口来进展业务层次的平面封装。我相信有许六人都是对M层的包装就是简单的按照和服务器之间的并行接口来概括的包装。下面的两种不同的M层实现的业务封装模式:

二种不同的M层封装实现

我们还是可以够进一步的对工作逻辑抽象出M层的接口和落实两局部,那样的一个功利是同等的接口可以有两样的落实格局,以及M层可以隐蔽分外多的其中数据和章程而不暴露给调用者知道。通过接口和贯彻分离大家还足以在不转移原来实现的基础上,重新重构业务部分的落实,同时这种形式也很容易MOCK一个测试实现,这样在进展调节时得以很简短的在实际实现和MOCK实现之间切换,而不用每一趟都和劳务器端实行相互调试,从而实现客户端和服务器之间的分级支付和调节。下边是一个荣升版本的M层系列布局:

据悉接口的M层实现

  • M层怎么样和C层交互的题目也急需考虑,因为M层是不需要领会C层和V层的存在的,那么M层在工作处理完毕后怎么去通知C层呢?方法有很多种:
    • 我们可以为M层的关照逻辑定义Delegate协议,然后让C层去落实这个协议,然后M层提供一个delegate属性来赋值处理事务公告的目的。
    • 大家也能够定义众多的NSNotification或者事件总线,然后当M层的事务处理完毕后方可发送通告,并且在C层实现文告的拍卖逻辑。
    • 咱俩得以用闭包回调或者接口匿名实现目的的款式来落实工作逻辑完成的打招呼效能。而且可以定义出标准:所有M层对象的点子的结尾一个参数都是一个专业的如下格式的block或者接口回调:

typedef void (^UICallback)(id obj, NSError * error);

这种格局其实在成千上万系统中有拔取到。大家可以参数考苹果的CoreLocation.framework中的地理地点反解析的类CLGeocoder的定义。还有某些的是在AFN以及ASI中的网络请求部分都是把成功和破产的拍卖分成了2个block回调,但是此地提出在给C层的异步通告回调里面不区分2个block来调用,而是一个block用2个参数来解决。因为有可能我们的拍卖中不管成功或者失利都可能有一部分代码是一般的,假使分别则会现出重复代码的题材。

MVC中M层实现的简约举例

末段我们以一个简易的用户体系的报到系统来促成一个M层。

1.定义标准的M层异步回调接口:

//定义标准的C层回调block。这里面的obj会根据不同对象的方法的返回而有差异。
typedef void (^UICallback)(id obj, NSError * error);

//这里定义标准的数据解析block,这个block供M层内部解析用,不对外暴露
typedef id (^DataParse)(id retData, NSError * error);

2.概念所有M层业务类的基类,那样在通用基类里面我们得以做过多甩卖。比如网络层的统一调用,加解密,压缩解压缩,我们还足以做AOP和HOOK方面的处理。

     @interface  ModelBase

           //定义一个停止请求的方法
           -(void) stopRequest;
           /**
             *定义一个网络请求的唯一入口方法
             * url 请求的URL
             * inParam: 入参
             * outParse: 返回数据解析block,由派生类实现
             * callback: C层通知block
             */
           -(void) startRequest:(NSString*)url  inParam:(id)inParam outParse:(DataParse)outParse  callback:(UICallback)callback;
     @end

3.概念一个用户类:

    @interface  ModelUser:ModelBase

        @property(readonly) BOOL isLogin;
        @property(readonly) NSString *name;

       //定义登录方法,注意这个登录方法的实现内部可能会连续做N个网络请求,但是我们要求都在login方法内部处理,而不暴露给C层。
       -(void)login:(NSString*)name  password:(NSString*)password   callback:(UICallback)callback;
        //定义退出登录方法
       -(void)logout:(UICallback)callback;
    @end

4.概念一个M层总序列统类(可选),那多少个类可以是单例对象:

    @interface ModelSystem:ModelBase

     +(ModelSystem*)sharedInstance;

    //聚合用户对象,注意这里是readonly的,也就是C层是不能直接修改用户对象,这样保证了安全,也表明了C层对用户对象的使用权限。
    @property(readonly)  ModelUser *user;  

    //定义其他聚合的模块

    @end

5.在C层调用用户登录:

  @implementation LoginViewController

    -(IBAction)handleLogin:(UIButton*)sender
   {
        sender.userInteractionEnabled = NO;
        __weak LoginViewController  *weakSelf = self;
       [[ModelSystem sharedInstance].user  login:@"aaa" password:@"bbb"  callback:^(ModelUser *user, NSError *error){

        if (weakSelf == nil)
               return;
       sender.userInteractionEnabled = YES;
       if (error == nil)
       {
              //登录成功,页面跳转
       }
       else
      {
            //显示error的错误信息。。
      }}];

   }

   @end

可以观望地点的C层的部分很是简单明了,代码也易读和容易理解。同时咱们还察看了C层跟本不需要明白M层的报到实现到底是怎么请求网络的,以及呼吁了多少个网络操作,以及用的什么协议,以及怎么着数据报文格式,所有的这整个都封装在了M层内部贯彻了。C层所要做的就是简简单单的调用M层所提供的办法,然后在callback中通报界面更新即可。整个C层的逻辑也就是几十行就能搞定了。

具体的模型层设计艺术请参见M层的筹划


迎接我们关注自身的github地址,关注欧阳大哥2013,关注自我的简书地址:http://www.jianshu.com/u/3c9287519f58

相关文章

网站地图xml地图