博看文思好的架构不是设计出来的而是进化而来的.docxVIP

博看文思：好的架构不是设计出来的，而是进化而来的！ 写在前面 从 2011 年底开始学习 iOS 开发，到现在也已经快 3 年了，虽然中途没有一直进行 iOS 的开发（总是在Android 和 iOS 间切换），但始终没有离开，而我现在的工作也一样，在 iOS 和 Android 间来回游走，正如我博客的 slogan 一样， “In AndroidiOS”。其实对我来说，两个平台没有绝对的好坏，我都喜欢、我都热爱。有人会说，同样的产品在不同平台做两次不会觉得厌烦吗？这个问题我会给出肯定的回答，不会！因为如果你真的喜欢你所做的产品，做多少次都不会觉得烦，每一次的复盘都是一次改进的过程，很多创新都是在重复的工作中产生的。在技术层面，同一套思想用不同的技术来实现，本身就是一个加强对不同平台技术巩固和理解的过程，技术本来就是来承载和表现业务的，在实现业务的过程中加强对业务的理解、实现对业务的创新，这或许也就是堆代码和写程序的区别吧！我的 iOS 工程结构：接下来，我就简单介绍下我做 iOS 项目时使用的工程结构。首先要说的是，这只是我的工程结构，并不是规范，或许它存在很多问题和不规范的地方，我只是把它分享出来，给大家提供一个参考，也希望收到大家的一些反馈来帮助我改进！ 项目结构 下图是我做 iOS 项目的一个常用工程结构，整体模式还是按照 MVC 的结构，只是在每一层做了一些细分处理，下面就简单介绍下。 iOS iOS 工程中没有像 Java 那样非常严格的分包机制，不过在 iOS 工程中我们也可以通过 Group 的方式在工程中实现逻辑分包，这样更有利于我们组织和管理代 码，使工程结构更清晰和易于理解。在我的工程结构中，主要有如下 group： Application Application：这个 group 中放的是 AppDelegate 和一些系统常量及系统配置文 件；Base：一些基本父类，包括父 ViewController 和一些公用顶层自定义父类，其他模块的类一般都继承自这里的一些类；Controller：系统控制层，放置 ViewController，均继承于 Group Base 中的 BaseViewController 或 BaseTableViewController； 件； Base：一些基本父类，包括父 ViewController 和一些公用顶层自定义父类，其 他模块的类一般都继承自这里的一些类； Controller：系统控制层，放置 ViewController，均继承于 Group Base 中的 B aseViewController 或 BaseTableViewController； View：系统中视图层，由于我比较喜欢通过代码实现界面，所以这里放的都是继 承于 UIView 的视图，我将视图从 ViewController 中分离出来全部放在这里，这 样能保持 ViewController 的精简； Model：系统中的实体，通过类来描述系统中的一些角色和业务，同时包含对应 这些角色和业务的处理逻辑； Handler：系统业务逻辑层，负责处理系统复杂业务逻辑，上层调用者是ViewCo ntroller； Storage：简单数据存储，主要是一些键值对存储及系统外部文件的存取，包括 对 NSUserDefault 和 plist 存取的封装； Network：网络处理层(RTHttpClient)，封装了基于 AFNetworking 的网络处理层， 通过 block 实现处理结果的回调，上层调用者是 Handler 层； lper)，对外提供基于 Model 层对象的调用接口，封装对数据的存储过程。 lper)，对外提供基于 Model 层对象的调用接口，封装对数据的存储过程。 Utils：系统工具类(AppUtils)，主要放置一些系统常用工具类； Categories：类别，对现有系统类和自定义类的扩展； Database：数据层，封装基于 FMDB 的 sqlite 数据库存取和管理(RTDatabaseHe Resource：资源库，包括图片，plist 文件等； 以上是对我的工程结构中各个 group 的介绍，通过以下登录模块的系统类图，可以比较直观的看到这种工程结构的全貌。 整体来看分为三大块，黄色区域的模型和业务逻辑层（M），蓝色区域的视图层 （V），红色区域的视图控制器层（C），其中，黄色区域实现了对业务逻辑和数据处理的封装，对应他们的上层 ViewController，可以实现非常简单的接口调用，将业务复杂性从ViewController 中抽离出来，通过模块化的方式，保证Vi ewController 的可读性和可维护性。 保持 ViewController 简单