读反革命攻城狮博客汲取养分

读反革命攻城狮博客汲取养分

博客原地址:iOS应用架构谈

架构主要考虑的事情:

  • 调用网络API
  • 页面展示
  • 数据的本地持久化
  • 动态部署方案

View层

UIViewController的结构应大致如下

image

要点

  1. 所有的成员变量都已Property属性存在。
  2. 属性修饰第一应为非原子性,用strong、weak取代retain,assign。
  3. ViewController内的方法顺序应一致。
  4. 布局直接在ViewDidload中约束。属性初始化交给Get方法。
  5. 由于属性较多所以set和get方法应该放置最后比较合适。
  6. 遇到复杂tableView 应该将DataSource单独剥离。参考更轻量的ViewController 或者我的Demo
  7. 除静态页面可使用SB其他最好使用Masonry。
  8. 尽量不要派生ViewController,如有需要可使用Category + AOP (Method Swizzling(Aspects) /NSObject load函数) Demo

MVC

M应该做的事:
  1. 给ViewController提供数据
  2. 给View/Users/yangbin/Documents/Code/YBQRCode/QRCode/Info.plistController存储数据提供接口
  3. 提供经过抽象的业务基本组件,供Controller调度
C应该做的事:
  1. 管理View Container的生命周期
  2. 负责生成所有的View实例,并放入View Container
  3. 监听来自View与业务有关的事件,通过与Model的合作,来完成对应事件的业务。
V应该做的事:
  1. 响应与业务无关的事件,并因此引发动画效果。
  2. 点击反馈(如果合适的话,尽量还是放在View去做)等。
  3. 界面元素表达

MVCS(瘦Model)

基于MVC衍生的一套架构,从ViewController中拆出Store专门用来数据存取。

MVVM(胖Model)

基于MVC衍生的一套架构,基于成熟的RAC。从ViewController中拆出ViewModel负责数据加工并通过通知机制让View相应ViewModel的改变。

详情请参考objcn.io第13期

image

VIPER

还没有看

image

设计心法

  • 第一心法:尽可能减少继承层级,涉及苹果原生对象的尽量不要继承,参考资源
  • 第二心法:做好代码规范,规定好代码在文件中的布局,尤其是ViewController
  • 第三心法:能不放在Controller做的事情就尽量不要放在Controller里

Mediator模式

解决Controller之间依赖度过高,所以可以通过一个中间类Mediater来实现一个页面到达另一个页面的需求。这样所有的页面只需要依赖Mediater即可。核心是通过反射机制完成。Demo

--------------             --------------             --------------
|            |             |            |             |            |
| Buisness A |             | Buisness B |             | Buisness C |
|            |             |            |             |            |
--------------             --------------             --------------
              \                   |                  /
               \                  |                 /
                \                 |                /  通过Mediater来召唤页面
                 \                |               /
                  \               |              /
                  --------------------------------
                  |                              |
                  |            Mediater          |
                  |                              |
                  --------------------------------
                                  |
                                  |
                                  |
                                  |
                                  |
                  --------------------------------
                  |                              |
                  |              App             |
                  |                              |
                  --------------------------------

当A业务需要调用B业务的某个页面的时候,将请求交给Mediater,然后由Mediater通过某种手段获取到B业务页面的实例,交还给A就行了。在具体实现这个机制的过程中,有以下几个问题需要解决:

  1. 设计一套通用的请求机制,请求机制需要跟业务剥离,使得不同业务的页面请求都能够被Mediater处理
  2. 设计Mediater根据请求如何获取其他业务的机制,Mediater需要知道如何处理请求,上哪儿去找到需要的页面

另附几篇谈及Mediater的博客

bang's blog

反革命攻城狮

蘑菇街 App 的组件化之路

ReviewCode

什么样的工程师是好攻城狮?

  1. 每天都在学习,新技术新思想上手速度快,理解速度快

    做不到这点,你就是码农

  2. 业务出身,或者至少非常熟悉公司所处行业或者本公司的业务

    做不到这点,你就是运维

  3. 熟悉软件工程的各种规范,踩过无数坑。不会为了完成需求不择手段,不推崇quick & dirty

    做不到这点,你比较适合去竞争对手那儿当工程师

  1. 及时承认错误,不要觉得承认错误会有损你的身份

    做不到这点,公关行业比较适合你

  2. 不为了炫技而炫技

    做不到这点,你就是高中编程爱好者

  3. 精益求精

    做不到这点,(我想了好久,但我还是不知道你适合去干什么。)

不明白的地方

AOP,横向依赖,跨层访问。

最后感谢Casa:

大神微博

大神博客


by: queuey
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容