iOS开发 - 抛开表面看本质之iOS常用架构(MVC,MVP,MVVM)

简介: iOS开发 - 抛开表面看本质之iOS常用架构(MVC,MVP,MVVM)

前言


既然是看本质,那我们今天要说的内容肯定不是常规的大家在网上都能搜到的内容,所以,我们今天就来说说别人没有写过的东西。具体来给大家讲讲什么是iOS架构,什么是我们常说的MVC,MVP,MVVM。


在开始之前,想吐个槽。现在这面试动不动就问架构,有几个人是真正把架构玩明白的?我们按照网上别人写的博客说一遍,又融入了自己的几分理解?我们要明白的一点是:架构服务于人,而不是人服务于架构。


让很多人来讲架构,MVC,MVP,MVVM,说的都千篇一律,网上查到的内容也大相径庭,可能很多人讲完之后也没有明白这些架构具体要怎么写才能符合它的名字。其实很多人已经在使用这些架构了,只是自己不知道而已,这就是因为没有对架构有一个清晰的认知。


今天,我们打破这一现象,不讲概念,不画图,我们就来聊聊,什么是iOS下常用的MVC,MVP,MVVM,和什么情况下用这些架构。


1.MVC


博主不是个按套路出牌的人,你所熟知的model,view,controller博主一概不讲,博主要讲的就是:龙头凤尾猪肚子。


model和view通不通信,我们也不管,管那么多干嘛?我们要明白,代码服务于人,我们要根据具体的需求和代码表现来选择适合的传值和交互方式,MVC只是因为大多数的代码都写在了viewDidload下,或者说在viewController内,这才导致了我们所说的龙头凤尾猪肚子。


那么什么情况下会用MVC呢?简而言之,什么情况下都会用,这不等于废话吗?当然不是,现在,请你忘记所谓的架构和便捷方式,现在,你是一个新手了,你只知道AFNetworking请求数据,UIViewController创建页面,UIView创建视图,其他的东西,你一概不知道,这时候,一个MVC的基础架构就已经存在了,啥都不管,一股脑都在UIViewController里面调用和实现,各种全局参数和实例方法满天飞。数据在UIViewController里请求,拿到数据后直接去改变UIView上的参数,我们俗称:刷新UI。


非常好,这时候,你已经实现了一个很重的MVC架构的页面,按照此模式,你已经可以在MVC上一骑绝尘了。那么现在,还有人不知道什么是MVC框架么?还有人不会用MVC框架吗?


2.MVP


这龙头凤尾猪肚子的形容成为现实,领导和新来的开发看着我们写的代码陷入了沉思,内心大喊着MMP,如果这时候眼神能杀人,你已经死了无数次,脾气不好的可能直接就怼你了,脾气好的可能会质疑一下,然后建议你改一改代码方式,这个算是比较友好了。


那么MVC框架真的一无是处吗?


当然不是,假设你要写一个关于我们的界面,写一个只有一个联系方式的页面,你不用MVC框架还留着过年吗?甚至于任何一个简单的固定数据的页面,这时候谁要去用MVP,以至于MVVM框架,我只能说:请便!


永远记住一句话:框架服务于人,人服务于业务,所以一切框架最终都要服务于业务,我们的目的很简单,解耦,解耦,还是解耦,这样的简单页面,MVC足以应付,且几乎不存在解耦的问题,如果有,也可以通过简单的方式来解决,这可能会涉及MVP,因为一旦数据做中转,那可能就是MVP的范畴,但是别忘了,MVP变种于MVC,但MVC并不过时。


所以问题来了,什么是MVP?


我们可以简单理解为:MVP就是将庞大的Controller中的业务逻辑抽离到一个单独的类中的一种实现方式,这里面自然包括了UIVIew的布局,当然,MVP绝不仅限于此。所以,我们来思考下另一个问题:P层可不可以存在多个?可不可以?可不可以?快速给出答案,懵不懵?我们所看的固定式解说从没提到过这个问题,网上搜了一下,也没找到,起码没有很容易找到这个问题。


那么到底MVP中的P层可不可以有多个呢?我们假设可以吧,这样我们就可以给每一个呈现在屏幕上的UIView一个单独的P层来管理这一个UIView,这样是不是P层的压力也小了很多呢?这时候有一个新的问题,布局的时候怎么保证不同的P层内UIView的位置不出现问题呢?我们想想现在的布局方式:


1)绝对布局,frame的y和height写成固定的,这样就可以解决多个P层的问题(我们要先明确一点,P层内是包含了所管理的UIView的布局和所有的需要判断业务逻辑的,可能还包含了网络请求的Model的调用和数据的绑定,也就是UI刷新,这一点很重要);


2)相对布局,加约束,这样的话貌似就不是很好处理了,基于这种方式,我们考虑把UIView的创建和P层的创建写在同一级,这样好像可以解决了,就是不知道会不会有人说这违背了MVP的原则,大家给给意见,个人认为可以,只要具体的实现和逻辑是放在P层内的,我觉得这种方式反而可以对P层瘦身。


基于以上两条,大家对P层可以有多个的问题怎么看?网上搜的时候,看到有Android的文章讲解多个P层的情况,那么我认为iOS也是可以的。


接下来我们要说的通信问题就成了多个P层之间存在的另一个问题,那么下一个问题就是,关于P层的通信问题,他们如何实现通信?


在搜到的相关内容中,都是说P层和model,和view进行双向通信,这里也有个明显的问题,没有实现双向绑定,如何实现双向通信?其实这个表述有误,关于P层的通信,虽然可以实现双向,但却并不是双向绑定的,不能做到model改变之后自动改变view的能力,这属于双向绑定的范畴。


model和view的通信:model通过在P层的刷新,最终返回到P层,P层再通过view暴露出来的接口(接口的概念来源于Java,iOS本没有接口这一概念,起码这么多年,博主没见过这种说法,多是从外界引入的概念,我们理解为暴露出来的方法即可),去刷新UIView。


view和model的通信:UIView在用户的操作下,完成了某一个状态,比如点赞,评论,这时候需要通知model获取数据,UIView在P层封装着,而点赞操作在P层下的UIView下的某一层,这里就是反向传值的运用,传到哪?传到P层,P层再去调用数据,数据再回到P层,P层再刷新UIView的UI,关于反向传值,我们常见的有三种方法,一是通过协议代理,二是通过传值block,三是通过Notification,除此之外貌似没有其他有效的方法了,当然,你可以选择观察者的KVO,但是在这种层级结构下似乎不是很友好,关于这个问题,我们在MVVM中再讨论。


以上是关于传值的路径问题,MVP没有我们想象的那么难,其实你早已运用到自己的项目中,P层不局限于某一种命名方式,某一种结构形式,你要按照这个思想,你可以任意操作,只有新手才会完全按照某种制式去写代码,老司机们,你们觉得呢?


3.MVVM


说起来MVVM,通常的说法是:在MVP的基础上做双向绑定,即为MVVM,VM层即是P层的另一种叫法,不过是做了双向绑定。


双向绑定即是数据的变化在回调中直接刷新UI,UI刷新之后直接去拿数据并进行UI刷新。总之,UI的刷新离不开数据的变化,数据的变化离不开UI刷新,这样的过程可以通过回调自动完成,而不需要再调用繁复的方法,此为双向数据绑定。


MVVM,博主还是推荐大家使用RAC来做双想绑定,还有其他的方式,大家可以自行选择,关于RAC的具体使用,大家自己去查看API即可,不是什么太难的东西。


MVP我们提到了KVO,但却没有推荐,原因是没有对其进行友好的封装,而在MVVM中,实现这种机制的条件就是观察者模式,所谓的监听,这才是实现双向绑定的本质。所以RAC全称是RACObserve,大家明白这个问题的根本就行,后期自己学习。


4.总结


总之,写代码呢,一定要思路清晰,将不同的模块分区管理,做到高聚合,低耦合,做到这点,就无关乎框架什么事情了,管你是用什么架构,我们的目的只有一个,那就是实现可移植,在此基础上,三种框架你可以随心所欲的去切换使用,没有最好的框架,只有最好的程序猿。


博客写的好不好,你说了算,有问题,有质疑,欢迎评论区留言讨论。

目录
相关文章
|
2天前
|
存储 前端开发 数据可视化
在实际项目中,如何选择使用 Flux 架构或传统的 MVC 架构
在实际项目中选择使用Flux架构或传统MVC架构时,需考虑项目复杂度、团队熟悉度和性能需求。Flux适合大型、高并发应用,MVC则适用于中小型、逻辑简单的项目。
|
2天前
|
存储 前端开发 调度
Flux 与传统的 MVC 架构模式区别
Flux是一种用于构建用户界面的架构模式,与传统的MVC架构不同,它采用单向数据流,通过Dispatcher统一管理数据的分发,Store负责存储数据和业务逻辑,View只负责展示数据,使得应用状态更加可预测和易于维护。
|
2天前
|
API 持续交付 开发者
后端开发中的微服务架构实践与挑战
在数字化时代,后端服务的构建和管理变得日益复杂。本文将深入探讨微服务架构在后端开发中的应用,分析其在提高系统可扩展性、灵活性和可维护性方面的优势,同时讨论实施微服务时面临的挑战,如服务拆分、数据一致性和部署复杂性等。通过实际案例分析,本文旨在为开发者提供微服务架构的实用见解和解决策略。
|
8天前
|
缓存 运维 监控
后端开发中的微服务架构实践与挑战#### 一、
【10月更文挑战第22天】 本文探讨了微服务架构在后端开发中的应用实践,深入剖析了其核心优势、常见挑战及应对策略。传统后端架构难以满足快速迭代与高可用性需求,而微服务通过服务拆分与独立部署,显著提升了系统的灵活性和可维护性。文章指出,实施微服务需关注服务划分的合理性、通信机制的选择及数据一致性等问题。以电商系统为例,详细阐述了微服务改造过程,包括用户、订单、商品等服务的拆分与交互。最终强调,微服务虽优势明显,但落地需谨慎规划,持续优化。 #### 二、
|
8天前
|
监控 安全 Serverless
"揭秘D2终端大会热点技术:Serverless架构最佳实践全解析,让你的开发效率翻倍,迈向技术新高峰!"
【10月更文挑战第23天】D2终端大会汇聚了众多前沿技术,其中Serverless架构备受瞩目。它让开发者无需关注服务器管理,专注于业务逻辑,提高开发效率。本文介绍了选择合适平台、设计合理函数架构、优化性能及安全监控的最佳实践,助力开发者充分挖掘Serverless潜力,推动技术发展。
19 1
|
3天前
|
设计模式 人工智能 API
后端开发中的微服务架构实践与挑战#### 一、
本文将深入浅出地探讨微服务架构在后端开发中的应用实践,分析其带来的优势与面临的挑战。通过具体案例,展示如何有效地构建、部署和管理微服务,旨在为读者提供一份实用的微服务架构实施指南。 #### 二、
|
4天前
|
监控 API 持续交付
后端开发中的微服务架构:从入门到精通
【10月更文挑战第26天】 在当今的软件开发领域,微服务架构已经成为了众多企业和开发者的首选。本文将深入探讨微服务架构的核心概念、优势以及实施过程中可能遇到的挑战。我们将从基础开始,逐步深入了解如何构建、部署和管理微服务。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的见解和实用的建议。
13 0
|
3月前
|
开发框架 前端开发 .NET
ASP.NET MVC WebApi 接口返回 JOSN 日期格式化 date format
ASP.NET MVC WebApi 接口返回 JOSN 日期格式化 date format
45 0
|
6月前
|
开发框架 前端开发 .NET
ASP.NET CORE 3.1 MVC“指定的网络名不再可用\企图在不存在的网络连接上进行操作”的问题解决过程
ASP.NET CORE 3.1 MVC“指定的网络名不再可用\企图在不存在的网络连接上进行操作”的问题解决过程
184 0
|
6月前
|
开发框架 前端开发 JavaScript
JavaScript云LIS系统源码ASP.NET CORE 3.1 MVC + SQLserver + Redis医院实验室信息系统源码 医院云LIS系统源码
实验室信息系统(Laboratory Information System,缩写LIS)是一类用来处理实验室过程信息的软件,云LIS系统围绕临床,云LIS系统将与云HIS系统建立起高度的业务整合,以体现“以病人为中心”的设计理念,优化就诊流程,方便患者就医。
75 0