数据使用准则

1. 从服务器返回的数据永远是不可靠的。
2. 从文件读取的数据永远是不可靠的。
3. 从数据库读取的数据永远是不可靠的。
4. 总结来说，外部的数据永远是不可靠的，它会以任何突破你想象的形式出现，就像这个残酷的现实世界一样。
5. Repository是数据外围，任何类型的数据存取细节(比如 网络/文件/数据库)都应该封装在Repository中，Repository是内部业务逻辑访问和操作外界数据的唯一接口。
   
   • Repository为了解析数据所使用的原始Data类永远不能被内部业务逻辑直接使用。
   • 内部业务逻辑必须通过DataMapper将Repository返回的原始Data类对象转化为业务data类对象（即使两者的结构一模一样，也禁止复用）。
   • 原始Data类和业务data类的名称及结构不必保持一致，业务data类应该也必须从业务逻辑的角度对原始Data进行重组和删改。
   • 业务data必须加”Model”后缀来表征其业务data类的身份。
   • DataMapper是内部业务逻辑的数据守卫，DataMapper要保证转化过的业务data是安全的，有效的，可用的(对于无效数据，也需要返回一个空的Collection/对象)。
   • 内部业务逻辑在使用业务data时不必再考虑安全性(比如预期之外的null)。
   • DataMapper转化原则:
     
     • null String统一转化为空字符串或者某些特殊的字符串(具体业务类型决定)。
     • 对于实现了DataCheckValid接口的类，一定要行使checkDataValid来检测和排查无效数据对象(DataCheckUtil)。
     • Map中不能有key或者value为null的entry。
     • List中不能有null的item。
     • 尽量避免有null的存在，如果确实有，要证明在业务逻辑上的合理性。
     • 对于数值可以做限制，比如价格，可以限制在一个范围内。
   • DataMapper命名建议为”业务/模块名称 + DataMapper”。
   • DataMapper建议在业务模块中进行实例化。
   • 业务data类对象每个public成员变量和getter都要加@Nullable/@NonNull。
6. 设置的保存和读取也需要遵从Repository原则，不能暴露细节(比如Pref)。