无须关心外界与现实，顺着本心去输出，只感动与你同频的人。
我最早的时候，只知道MVC。模型、视图、控制器。把数据的管理与展示分开，方便开发与复用，通过控制器实现数据管理与展示之间的互动。
我5月份接手的代码，把视图显示和数据处理的代码都放在ViewController里面，显然连MVC的标准都达不到。
我之前会把数据单独一层来处理，并在数据层里实现数据的本地存储(持久化)。这一层通过被称为S层。所用架构就是常说的MVC S。
7月底，公司决定安排出时间对APP进行重写。使得我重新去考虑架构选择的问题。
以我自己过去的经验，不管是MVC还是MVC S，视图控制器部分因为要面对初期需求的频繁迭代，会在不知不觉积累下越多越多的业务逻辑代码。相应的视图数据转换代码也越来越多。慢慢就会使视图控制器(ViewController)越来越大，越来越难管理维护。
MVCS，通过把数据存储抽离，是对MVC的最简单的优化。
除了MVCS以外，我还关注到另外两个选择：1､业界广用的MVVM，2､比较年轻的VIPER。
VIPER通过Wireframe、Presenter、Interactor，把视图和数据辙底分离，实现了最好的代码模块化复用。同时，通过WPI的组合，可以在产品原型阶段就积极参与开发，将大大提高开发速度。
我们可以通过以下方式来理解MVVM与MVC/MVCS/VIPER之间的异同：
MVC: View/VC + Model
MVCS: View/VC + Store + Model
MVVM:View/VC + ViewModel + Model
VIPER: View/VC + Wireframe/Presenter / Interactor/Data Manager + Entity(Model)
从上面的列表，我们可以非常清晰地看到，不管是MVCS、MVVM还是VIPER，其实重点主要在于对VC代码的拆分上。
把原来全堆在VC的代码，拆分出来，成为独立的方便测试、维护、复用的单独的类。
一般而言，通过把代码放到不同类中，实现代码的物理分割和隔离，因为更容易阅读和理解，更容易测试，将有助于提高代码质量。
MVVM中的ViewModel就是把数据的展示逻辑从VC中拆分出来，数据经ViewModel处理后，将可直接用于View的显示。
相对而言，我还是更喜欢拆得更细的VIPER。通过Wireframe/Presenter/Interactor的封装，View、VC、Model将会得到更好的隔离和复用。
ＶIPER，通过View/VC/Wireframe/Presenter/Interactor/Data Manager 在纵向上完成完整的独立的业务用例。同时，通过Wireframe层的通信机制，完成不同业务之间的交互。纵向隔离后，只通过唯一一层进行交互，将使得代码更容易理解和组织。
后记(下面有聊家常为主，没时间没兴趣的朋友请直接忽略)：
8月22日(周六)中午12点到14点，上海陆家嘴国金中心三楼正斗餐厅，有一起来吃粥粉面饭点心的朋友吗？：）当然，我们AA哈：）30多一碗面，20多一碟肠粉，50多一个粥，20多一份牛肉烧卖。味道很正，价格还可以：）为方便联系，可加清醒疯子利炳根粉丝群：147043528
今天终于开始每组50次地做仰卧起坐了。一开始，我只是做10个就非常难受。现在一天4组做下来200个都完全可以很享受。
我相信技术也是一样的。不用担心一开始的起点有多低，只要天天去努力去积累，总会好起来的。
这也让我想到了，为老板工作，还是为公司工作，还是为家人工作的问题？
在我现在看来，根本不需要去思考这些问题，只需要每天踏踏实实提高一点点技术水平，会像健身一样，实打实地慢慢地把自己变得越来越强。
之所以开始每天都写技术博客，是因为投简历屡屡受挫后总结出来的解决方法。希望所有看到这篇文章的朋友也开始和我一起天天写技术博客，不要对自己要求太高，我给我自己定的标准是：每天100字：）
同样地，也希望所有看这篇文章的朋友都能去尝试建立自己的粉丝群。拥有一帮愿意听你说话的朋友，真的非常非常重要，我也从中收获了非常多。