我之前待的项目组将具有聊天功能的app改造成即时通讯IMSDK，跟环信，融云这种IMSDK最大的不同就是用户体系由SDK维护，减少开发人员在项目中引入聊天功能的工作量，现在调动到新的项目组，目前主要负责接入IMSDK及相关UI界面的重写，由IMSDK的开发人员角色转换到宿主角色，这种感觉挺奇妙的，让我可以更清楚从使用者思考IMSDKAPI设计的合理性和易用性，接下来我想谈谈这几个月使用IMSDK的一点心得。
IMSDK的优势在于IM本身维护一套DB数据库的管理，使用者只需调用相关的API即可，不用自己维护DB数据库的数据更新和管理，但是这样也有一个问题，但数据不满足项目要求，无法直接增加数据库字段，SDK并没有开放操作数据库的接口，如此一来，有两套方案：
方案1：
从IMSDK的API层获取到数据模型，再根据项目需求将需要的字段存到自己建立的表中，自己维护DB层数据，优势在于数据库自己管理，可以根据项目需求增加相应的字段，思路简单，处理起来也比较容易，但是缺点在于抛弃了IMSDK的数据库自身管理的优势，并且需要维护自身数据和IMSDK数据库的同步更新，容易出错，后期随着业务发展将会更加复杂，不便于后期维护和扩展。因此我采用了另一套方案：
我建立了数据加工层，左边是IMSDK的项目结构，右边是我们主项目的结构。整体思路是尽可能的使用IMSDK的维护好的数据库，在IMSDK数据库无法满足要求才会建立相应的DB层，在数据加工层中将IMSDK的model层和主项目的model层进行的数据处理，抛出加工好的model层供ViewController调用，viewController不必关心数据加工层的具体细节，只需要获取相应的model数据更新UI层即可，实现数据跟界面的隔离。整套设计思路来说，最大层度的利用了IMSDK维护好的数据库，不必关心IMSDK中的数据管理和数据更新，我只需维护好主项目的DB层数据更新即可，这样有利于后期的维护和扩展，也减少数据维护的工作量。
目前项目中的第一期需求已经基本完毕，整个方案的设计也是在不断摸索中，整体思路是数据跟UI隔离，尽量使用IMSDK维护好的数据，整套方案的设计还需经受项目版本迭代，才能证实是否是一套合理的方案，如果后期有更好的方案设计，我以后再补充。
