项目总结--Version 1.0（二）
欢迎加入【iOS/Swift/OC开发交流群|127183325】交流学习
上篇主要介绍了三层中的数据持久层，这一篇来详细说一下剩下的两层：业务逻辑层和表示层。
业务逻辑层相对于其他两层来说更能体现整个项目的扩展性和可伸缩性，这一层对表示层和数据持久成起着承上启下的作用，由于表示层的变动比较频繁，所以业务逻辑层需要精心的设计，以便能够承载将来的业务需求的频繁变化。
下图是业务逻辑层功能模块的划分。
AppManager是一个单例，它在这一层是一个比较特殊的存在，也是一个挺不好的设计，违反了单一职责原则。AppManager功能比较杂乱，既承担了部分Controller的跳转的功能，又承担了部分模块的初始化，还有一些通知转发的功能。这个类需要在以后的版本中重新设计，尽量避免设计出类似的“上帝类”。
业务逻辑层的模块是按功能来划分的。例如，用户相关的注册登陆和用户信息的修改都属于User模块，远程遥控相关的属于RemoteControl模块，文件传输相关的属于FileTransfer模块，网络视频语音属于VOIP模块，等等。模块和模块之间是相对独立的，尽量避免模块之间的相互访问，这样可以减少模块间的耦合度，需求发生改变的时候不至于产生大范围的影响。
相关的数据模型是进行上下两层数据流动的载体。业务逻辑层将表示层的相关请求进行消化处理，封装成对应的数据模型，在对这些数据进一步处理后传到数据持久层进行处理。使用数据模型可以对数据结构进行规范，也为将来的扩展做好准备。拿User数据模型来说，刚开始User的属性较少，有登陆必须的昵称和密码。表示层将昵称和密码传给业务逻辑层发起登陆请求后，业务逻辑层用表示层的昵称和密码创建一个user对象，然后对这个user对象进行相关的操作，比如向数据持久层发起数据持久化的请求。项目进行一段时间后，产品经理对这个用户进行了一些扩展，比如增加用户的性别，年龄等等，如过不用数据模型的话，我们可能会在所有用到用户信息的地方增加这些新增的属性，而数据模型，只要在user类里增加相应的属性就可以了，极大的方便了以后需求的更改。另外，使用数据模型还有一个好处，就是在使用某一个属性的时候用点语法就可调用，还可以添加注释，标识当前的属性的用途。
在设计这一层的时候，1.0版本和2.0版本有很大的差别，主要就在Block和Delegate的选择上。1.0版本更多的使用了Block，2.0版本用的Delegate比较多，关于这一块是怎么来选择的会在后面专门拿出一部分来说，这里还是重点说一下项目分层相关的。但是，请记住，这两者不能完全相互替代对方，个有个的优越点，算是相互补充吧。
下面是模块和视图的一个对应关系。
可以看出，如过各模块之间的耦合度能尽量的低的话，我们在需求改变时，功能模块的增减修改时会很方便，业务逻辑层的伸缩性和扩展性比较好。另外，业务逻辑层和表示层使用了Delegate进行解耦，使得业务逻辑层的可移植性保持的比较良好。这在2.0版本的时候就可以看出来，如过没有对这一层的重构的话，这一层是可以直接拿来用的，需要修改的仅仅是表示层。
最后是表示层，这一层没有什么特别要说的，因为表示层是变化最无常的一层，产品需求的更改最终的体现就是视图交互的更改。但也不是说表示层就可以随意设计了，我们还是要遵守单一职责原则和最少知识原则。单一职责原则，意思是在进行自定义控件的时候尽量让控件只做它应该做的事情；最少知识原则意思是对内要高内聚，对外要低耦合，功能的实现过程对调用它的对象来说是透明的。这样我们就能尽可能的对代码进行复用，而不用重复的实现类似的功能。
