可扩展性决定了项目能走多远，可复用行决定了项目走的是否轻快。
本文主要讨论1.0版本的项目在进行设计时对可复用性和可扩展性的思考，涉及了整个项目分层的所有层（想查阅分层相关部分的可以点这：项目总结--Version 1.0（一）和项目总结--Version 1.0（二））。
由于经验有限，做过多的扩展容易误导其他人，所以本文所做的一些讨论总结只限在本项目范围内进行，对这个项目在进行架构设计的时候遇到的问题和自己的一些想法在此做一些梳理和总结。
同样的，先从最底层－数据持久层开始说起。先看一下数据持久层的类结构图：
先分别说一下上述类的作用。
FBServerTool是一个单例，在程序运行的时候就进行初始化，这个类将手机端变成一个服务器，以供设备端对手机端的主动连接，在2.0版本中将此功能移除。
FBSocketTool同样是一个单例，也是在程序运行的时候进行初始化。这个类承担了两个功能，一是发送UDP包，二是提供一个TCP连接。
FBHTTPTool是一个封装了AFNetworking的类，它提供了访问web服务器常用的静态方法，类似AFN，使用了Block回调方式。
FBSOAPTool封装了SOAP协议，SOAP协议是数据交换协议的一种协议规范，基于XML。更具体详细的介绍可以看这：SOAP。通过这层封装，我们在使用SOAP协议的时候就可以不必关系具体的协议规范，像使用普通的HTTP来用即可。
FBWebservice包含了网络相关的宏定义，包括接口地址和Web Service使用的服务和方法。将相关的宏定义放在此处可以很方便的进行修改。
写到这大家应该能看出来某些地方感觉特别不爽，没错，我在开始2.0之前看这部分代码的时候也有这种感觉。到底哪出问题了呢？先看一下类名，＊＊＊Tool，第一眼看上去感觉这应该是一个工具类，里面的一些方法应该是类方法，但实际上，除了FBHTTPTool，FBSOAPTool，FBWebservice外其他类都是单例！这就有问题了，命名不规范，这会导致其开发者在用到我们这些类的时候需要进入类里面之后才能理解我们是如何设计的，而不能从名字来进行大概的推断哪些是单例，哪些是普通类或者相关的工具类。这在其他开发者分析项目，阅读代码的时候会增加不必要的时间成本。
另外，根据单一职责原则，FBSocketTool类的功能还应该继续进行拆分，在2.0版本中，这个类分成了两个类，一个负责UDP报文收发，一个负责TCP报文收发。
然后就是FBHTTPTool，这个类在2.0的版本中变化挺大的，由之前的类方法变成实例方法。这个类负责将AFN封装然后向上层提供简单的POST和GET方法，网络访问的结果在Block中进行处理。
FBSOAPTool和FBWebservice比较简单，在两个版本中几乎没有变化，在此就略过不谈了。
以上是NET模块的部分，接下来说一下DAO。这个模块最重要的就两个部分，一个是第三方库FMDB，另外一个是JKDBModel。FMDB是一个非常优秀的第三方库，极力推荐大家使用学习。JKDBModel是在FMDB之上又进行封装了的一个轻量级的小框架，和苹果自家的Core Data使用的ORM（对象关系映射）技术比较像，它将类名和数据表，属性和表字段进行映射，能够自动创建数据库和数据表，自动添加新增的表字段，避免了繁琐的SQL语句书写（虽然有时还是需要些一部分，但已经大大减少工作量了）。源码比较简单，大家可以拿来看看，学习一下，作者的思路还是很棒的。
最后说一下数据缓存这一块，这个地方应该是我的硬伤所在，整个项目看着最不顺眼的地方就是它了，在设计这一块的时候没有敢设计的很复杂，只是实现了基本的功能，所以数据缓存这一块还需要花时间专门研究一下。设计思路可以看一下前面的这篇文章。
我在进行着一层各个模块的设计的时候尽量的去避免了模块之间横向的访问，模块与模块之间需要遵循一套严格的规范来相互访问，不要让模块之间有太大的耦合度。保持各个模块的独立性才能在将来扩展的时候能够比较优雅的实现。在设计NET和DAO这两个模块的功能的时候，本着单一职责原则（重复好几次了，希望大家也能够记住，这个原则对代码的可复用性非常重要），不要让一个类承担过多的指责，将粒度划分的足够小我们才能很好的复用这些已有的功能。
欢迎加入【iOS/Swift/OC开发交流群|127183325】交流学习