3. Tips

1. View的设计上最根本原则是面向表现，也就是说尽可能定义UI直接可用的View的字段，客户端拿到就能表现；尽量不要设计表示中间状态的字段，客户端拿到一个字段数据还得等待下一个才能做出决策，这样的状态管理功能尽可能由服务器完成。

2. 理论上说SessionView定义一个就够。如果为了达到清楚划分的目的，可以定义多个，这时候需要注意使用上有没有严格时序的需求，因为同一View的字段设置才能保证严格时序。（手册中基本概念一节）

3. 并不是说用户所有数据都必须放SessionView, 必须考虑表现时机的问题, 很多数据都不是从头至尾都需要表现, 比如某些用户数据也就在某个弹出窗口使用一下。这种情况应该使用TemporaryView, 打开窗口就启动一个TemporaryView与之交互。这是一种合理设计, 一旦应用改版, 客户端取消某些功能, 服务器直接取消某些对应View实现，两边的代码都可以处理得非常干净。

4. TemporaryView可以订阅SessionView的字段，本质上是一种View之间的交互形式，但是这不是唯一交互形式。多个View同时bind某个table的同一记录也可以实现交互，如果有需要可以为此专门定义内存表。

5. View的Variable字段发生改变，整个字段被同步到客户端，如果这样的字段是一个大结构，比如复杂bean，可能造成比较大的网络开销。这种情况可以考虑使用内存表，使用bind方式与一个xbean关联起来，xbean的改变通告发生在xbean的字段层面上。也就是说，如果variable方式定义一个字段，类型为100个字段的bean，其中1个字段变化，这1个字段连同其余99个字段都会一次性打包发送；如果bind一个100个字段的xbean，其中1个字段变化，仅这1个字段被发送，当然了，客户端看起来，还是整个bind字段发生变化了。

6. 除了某些可能调用过于频繁，使用事务可能严重影响性能的操作外，其它操作尽量在存储过程中完成，确保事务特性。毕竟在服务器看来绝大多数操作都离不开数据库。另外，map在绝大多数应用里频繁使用，使用value为any类型的临时表，同样提供了部分map能力，还能附带事务特性，使用any的情况下不要忘记对象的销毁问题。

7. View对服务器而言只写，对客户端而言只读。服务器端View的生成类中，如果有需要可以添加自己的成员变量保存某些状态，这一点非常重要，不能忘记了，以为View就是全部。

8. View上的操作全部线程安全，不需要额外加锁。同一View上的操作严格保证时序，按照v.setA，v.setB的顺序执行，客户端一定看到A早于B通告。但是在多线程环境下这里存在一个问题，两个线程同时执行这样的序列，客户端可能看到AABB的序列。如果对同一view的字段集合层面上的原子性有严格要求，也就是说客户端必须看到ABAB序列，似乎就只能使用锁了，在锁的环境下执行v.setA，v.setB。事实上View提供了更好的解决方法，不需要加锁，v.schedule(()->{v.setA，v.setB});