代码的框架-MVVM

关于 MVVM，尽可能多的使用面向协议的思想来实现。

v 0.1 的MVVM(初始的构建)

v 0.2 的MVVM(失败的尝试)

v 1.0 的MVVM(稳定的版本)

v 1.1 的MVVM(面向协议的开始)

好架构的标准
- 代码整齐，分类明确，没有common，没有core
- 不用文档，或很少文档，就能让业务方上手
- 思路和方法要统一，尽量不要多元
- 没有横向依赖，万不得已不出现跨层访问
- 对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
- 易测试，易拓展
- 保持一定量的超前性
- 接口少，接口参数少
- 高性能

以此记录当前使用的项目构架

    ├── <CodeFeed>               项目构建内容
    ├── <PrefixHeader>           预编译部分
    ├── <Utils>                  仅本项目可用工具
    ├── <Supporting Files>       项目基本配置文件
    └── <Pods（或Carthage）>工程   通用工具

1. CodeFeed ——项目构建内容

其内部分

    ├── <EntityCode>        代码实体，主要页面的构建
    └── <PublicCode>        跳转的公共页面

内部以MVVM构架进行搭建，其下分为

    ├── <M>  数据模型集合
    ├── <V>  显示层集合
    ├── <VM> 业务模型集合
    └── <C>  存放'M、V、VM'的容器

其中

M层 以 瘦Model 为标准,仅用做数据的存取，其辅以ModelLayer用做数据的存取操作逻辑

V层 显示相关的功能组件

• 对于业务较少的 View,做简单的封装,仅暴露必要的接口以方便其展示数据的更新。
• 对于业务较多，逻辑复杂的 View,设计时需遵循 面向协议 的思想，将需要定制的 UI 和逻辑，通过 delegate和dataSource实现

VM层 负责逻辑操作，对View做定向的数据做绑定和定制

• 若View仅暴露一定的数据接口，则其为 View和对应的Model进行数据绑定；
• 若View使用面向协议的思想来设计，则实现其协议方法，实现View的定制

以上模型均以Index 做为访问内部诸项的索引

C层，存放’M、V、VM’的容器，实现数据、逻辑的定向绑定。

2. PrefixHeader -预编译部分

存放.pch文件及其它预编译的文件

例如：

• 宏的定义
• 常用类的引用
• UI原型的属性设置
• 类方法指针的混用
  ……

3. Utils -仅本项目可用工具

只适用于当前项目的工具（多项目通用的工具类，应当提取出去，在托管平台上进行维护）

根据功能可以细分为以下几种：

    ├── <Component>  完全内聚的功能组件（含有自己的M、V、VM的完整组件）
    ├── <Category>   添加便捷调用的拓展方法
    ├── <M>          通用的数据模型
    ├── <V>          通用的显示层
    └── <VM>         通用的业务模型

其M、V、VM的设计参考 codeFeed中的对应模块

4. Supporting Files -项目基本配置文件

存放APP的配置文件 info.plist、InfoPlist.strings、main.m、Appdelegate

5. Pods（或carthage）-通用工具

管理通用的工具类

如AFNetworking、Masonry、MJRefresh ……

Github地址