1.VIPER 从字面意思来理解,VIPER 即 View Interactor Presenter Entity Router(展示器(视图) 交互器 协调器 实体(数据) 路由器),迄今为止,划分责任的粒度是很好的选择.VIPER 在责任划分层面进行 了迭代,VIPER 分为五个层次: 展示器 -- 包含 UI 层面的业务逻辑以及在交互器层面的方法调用. 交互器 -- 包括关于数据和网络请求的业务逻辑,例如创建一个实体(数据),或者从服务器中获取一些数据.为了实现这些功能,需要使用服务.管理

第一篇文章对VIPER进行了简单的介绍,这篇文章将从VIPER的源头开始,比较现有的几种VIPER实现,对VIPER进行进一步的职责剖析,并对各种细节实现问题进行挖掘和探讨.最后给出两个完整的VIPER实现,并且提供快速生成VIPER代码的模板. Demo和轮子的github地址是:ZIKViper,路由工具:ZIKRouter.有用请点个star~ 两个实现展示了以下问题的解决方案: 如何彻底地解决不同模块之间的耦合如何在一个模块里引入子模块子模块和父模块之间如何通信如何对模块进行依赖注入面向

洋葱模型 洋葱模型,是从冰山模型上演变而来的,用来进行层次分析的模型,这是Redux的洋葱模型. action从最外层传入,层层传递直至核心后,经过逐层事件触发,再次被分发出来,执行后续操作. 洋葱模型如今已经广泛应用于各个领域,进行更直观清晰的分层剖析. The Clean Architecture Robert C·Martin是<Clean Code>的作者,我们习惯称他为Uncle Bob.2012年8月13日,他在他的个人Blog上,提出了著名的The Clean Architect

路由是实现模块间解耦的一个有效工具.如果要进行组件化开发,路由是必不可少的一部分.目前iOS上绝大部分的路由工具都是基于URL匹配的,优缺点都很明显.这篇文章里将会给出一个更加原生和安全的设计,这个设计的特点是: 路由时用protocol寻找模块 可以对模块进行固定的依赖注入和运行时依赖注入 支持不同模块间进行接口适配和转发,因此无需和某个固定的protocol关联 充分解耦的同时,增加类型安全 支持移除已执行的路由 封装UIKit界面跳转方法,可以一键跳转和移除 支持storyboard,支持

本文由CocoaChina译者lynulzy(社区ID)翻译 作者:Bohdan Orlov 原文:iOS Architecture Patterns 在 iOS 中使用 MVC 架构感觉很奇怪? 迁移到MVVM架构又怀有疑虑?听说过 VIPER 又不确定是否真的值得切换? 相信你会找到以上问题的答案,如果没找到请在评论中指出. 你将要整理出你在 iOS 环境下所有关于架构模式的知识.我们将带领大家简要的回顾一些流行的架构,并且在理论和实践上对它们进行比较,通过一些小的例子深化你的认知.如果对文

[编者按]本篇文章由 Jeff Gilbert 和 Conrad Stoll 共同编写,通过构建一个基础示例应用,深入了解 VIPER,并从视图.交互器等多个部件理清 VIPER 的整体布局及思路.通过 VIPER 构建 iOS 应用架构,提升应用质量,迎接应用构建的新机遇!本文系 OneAPM 工程师编译整理,这是本系列的第 2 篇文章. 用 VIPER 构建 iOS 应用架构(1) UIViewController 的确相当有用. 在 VIPER 下,视图控制器会恰当地做好它分内的事--控制

[编者按]本篇文章由 Jeff Gilbert 和 Conrad Stoll 共同编写,通过构建一个基础示例应用,深入了解 VIPER,并从视图.交互器等多个部件理清 VIPER 的整体布局及思路.通过 VIPER 构建 iOS 应用架构,提升应用质量,迎接应用构建的新机遇!本文系 OneAPM 工程师编译整理 众所周知,在建筑领域,我们塑造自己的建筑,而建筑也反过来影响我们.对于程序员来说,在构建软件方面这个道理也同样适用. 在编程的过程中,让代码具备可读性是非常重要的,除此之外代码还要具备明

在 iOS 中使用 MVC 架构感觉很奇怪? 迁移到MVVM架构又怀有疑虑?听说过 VIPER 又不确定是否真的值得切换? 相信你会找到以上问题的答案,如果没找到请在评论中指出. 你将要整理出你在 iOS 环境下所有关于架构模式的知识.我们将带领大家简要的回顾一些流行的架构,并且在理论和实践上对它们进行比较,通过一些小的例子深化你的认知.如果对文中提到的一些关键词有兴趣,可以点击连接去查看更详细的内容. 掌控设计模式可能会使人上瘾,所以要当心,你可能会对一些问题清晰明了,不再像阅读之前那样迷惑,

iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.下篇主要讨论做View层架构的设计的一些心法. 本门心法 重剑无锋,大巧不工. ---- <神雕侠侣> 这是杨过在挑剑时,玄铁重剑旁边写的一段话.对此我深表认同.提到这段话的目的是想告诉大家,在具体做View层架构的设计时,不需要拘泥于MVC.MVVM.VIPER等规矩.这些都是招式,告诉你你就知道了,然后怎么玩都可以.但是心

OS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.上篇主要讲View层的代码结构.布局,以及一些最佳实践的讨论. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修

iOS客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答iOS应用架构中的种种问题,本文是其中的第二篇,主要讲View层的组织和调用方案.中篇主要讨论MVC.MVCS.MVVM.VIPER等架构在iOS开发中的应用. 关于MVC.MVVM等一大堆思想 其实这些都是相对通用的思想,万变不离其宗的还是在开篇里面我提到的那三个角色:数据管理者,数据加工者,数据展示者.这些五花八门的思想,不外乎就是制订了一个规范,规定了这三个角色应当如何进行数据交换.但同时这些也是争议最

当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在这时候必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修改的余地就已经非常之小了.因为它跟业务关联最为紧密,所以哪怕稍微动一点点,它所引发的蝴蝶效应都不见得是业务方能够hold住的.这样的情况,就要求我们在实现这个架构时,代码必须得改得勤快,不能偷懒.也必须抱着充分的自我怀疑态度,

iOS从2007年诞生至今已有近10年的历史,10年的时间对iOS技术圈来说足够产生相当可观的沉淀,尤其这几年的技术分享氛围无论国内国外都显得异常活跃.本文就iOS架构这一主题,结合开发圈里讨论较多的几种主流方式,再配以博主自己的理解,做下现状分析.给自己做下知识梳理的同时,也期望能引入新的思考. 架构的定义 过去6年多几乎绝大部分时间都浸淫在iOS平台,翻阅过不少关于架构的文章,发现众人对架构的理解颇有些差异,总体来说可分为四类: 第一类:精简型应用架构 这类架构的文章分析主要还是围绕MVC展

前言 <iOS应用架构谈 开篇>出来之后,很多人来催我赶紧出第二篇.这一篇文章出得相当艰难,因为公司里的破事儿特别多,我自己又有点私事儿,以至于能用来写博客的时间不够充分. 现在好啦,第二篇出来了. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在这时候必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修改的余地就已经非常之小了

一) 我们可以定义一个好的架构应该具备的特点: 任务均衡分摊给具有清晰角色的实体 可测试性通常都来自与上一条(对于一个合适的架构是非常容易) 易用性和低成本维护 二) 传统的MVC模式.:三个实体间相互都有通信,而且是紧密耦合的.这很显然会大大降低了三者的复用性,而这正是我们不愿意看到的. MVP的好处就是解除view与model的耦合,使得view或model有更强的复用性. MVVM和MVP模式看起来非常像: MVVM将ViewController视作View 在View和Model之间没有

iOS 客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答 iOS 应用架构中的种种问题,本文是其中的第二篇,主要讲 View 层的组织和调用方案.下篇主要讨论做 View 层架构的设计的一些心法. 本门心法 重剑无锋,大巧不工. ---- <神雕侠侣> 这是杨过在挑剑时,玄铁重剑旁边写的一段话.对此我深表认同.提到这段话的目的是想告诉大家,在具体做 View 层架构的设计时,不需要拘泥于 MVC.MVVM.VIPER 等规矩.这些都是招式,告诉你你就知道了,然

iOS 客户端应用架构看似简单,但实际上要考虑的事情不少.本文作者将以系列文章的形式来回答 iOS 应用架构中的种种问题,本文是其中的第二篇,主要讲 View 层的组织和调用方案.上篇主要讲 View 层的代码结构.布局,以及一些最佳实践的讨论. 当我们开始设计 View 层的架构时,往往是这个 App 还没有开始开发,或者这个 App 已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做 View 层架构,基于这个时机的特殊性,我们在必须清楚认识到:View 层的架构

前言 <iOS应用架构谈 开篇>出来之后,很多人来催我赶紧出第二篇.这一篇文章出得相当艰难,因为公司里的破事儿特别多,我自己又有点私事儿,以至于能用来写博客的时间不够充分. 现在好啦,第二篇出来了. 当我们开始设计View层的架构时,往往是这个App还没有开始开发,或者这个App已经发过几个版本了,然后此时需要做非常彻底的重构. 一般也就是这两种时机会去做View层架构,基于这个时机的特殊性,我们在这时候必须清楚认识到:View层的架构一旦实现或定型,在App发版后可修改的余地就已经非常之小了

https://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/Introduction/Introduction.html iOS 是基于 UNIX 内核,Android是基于 Linux内核,他们之间有共性和区别 iOS的系统架构分为四个层次: 核心操作系统层(Core OS layer):Core OS 是位于iOS系统架构最下面的一层是核心操作系统层,它

根据多年的iOS开发经验,常用的iOS开发架构有:MVC.MVVM.CDD等,在这里我就不一一列举了. 做一个项目一般首先要搭建主流框架界面:常见的有TabBar控制器可以切换子控制器,上面又有Navigation导航条这个主流框架,还有一个就是用左右侧滑来控制自控制器的主流框架. 接下来就是搭建项目主框架 1.先搭建tabBarController(下面有一条) 2.再搭建NavigationController(上面有一条,并且每个子控制器的不一样) 思考开发方式 1.storyboard搭