对CTNetworking的理解和网络层的封装
现有的网络框架缺点：
1.通用配置都在tjHttpRequest里，弱业务和框架耦合
2.网络请求外接在userauthentication中，强业务也会和框架耦合，大部分请求在这个类里面，后期不好维护
3.网络请求和业务挂钩这样不便于移植，每个不同的app或者app中有着不同通用规则的接口不好修改和复用
4.controller里要是多个请求会使得控制器变得冗余
总结：网络框架层和业务耦合，框架不可移植
TJNetworking的优点：
业务下沉：
1.业务层和网络框架不耦合，方便网络框架移植和扩展
2.控制器发起请求时操作精简，使controller层代码不会因为网络请求变得冗余
3.离散型的交互方式，让每个请求都可单独管理请求或取消
4.提供interceptor方便切片管理
总结：网络框架层和业务解耦，框架可移植，扩展方便
TJNetworking核心代码介绍：
实现思路：父类只遵守协议，而协议不涉及具体的实现，子类遵守协议并实现协议来使得框架和业务解耦
TJNetworkingDefines：一些基本的协议定义和类型定义 TJServiceProtocol：主要处理网络请求中通用的一些要求
TJServiceFactory :将子类遵守协议的service和框架进行关联，TJServiceFactory不依赖子类service，TJServiceFactory相当于service的工厂
TJNetLogger： 主要用于日志打印
TJApiProxy： 主要用于框架层的网络请求，用于和基层的网络库进行交互，方便TJNetworking替换基层网络框架
TJURLResponse：网络请求的响应
TJAPIBaseManager：网络框架中的父类manager用于：子类继承并实现协议
目前框架还可以添加请求缓存。
一些可能疑惑：
1.离散型的网络请求，要是网路请求过多是不是要写多个manager ，是应该写manager ，因为每个manger对应一个请求会让请求易于维护和整个网络请求相关的业务清晰和易于管理，聚合型的写在一起会使得请求堆在一起，后期难以维护。
2.子类service针对每个不同的请求策略应该不一样，identity要和class一致
其他的可以看demo，目前还有一些细节未实现，可以一起再讨论
