3. Tips
1. The design of the View is the object performance implementation from the fundamental principle, which means the field of the View directly used by the UI could be defined so that the client could present when getting. Do not design the field expressing the middle status , the client has to wait for the next to make decision when getting a field data. This status management should be finished by the server.
2. From the theory, it is enough to have one SessionView definition. For the purpose of clear division, the multiple definition is acceptable. It should consider whether there is strict time sequence requirement in the usage because only the field set of the same View could guarantee the strict timing. (Please refer the manual for the detailed information.)
3. It does not mean that all the user data must be put in the SessionView. We should consider the change to express opportunity. Many datum do not need to present from the beginning to the end, such as some user data which only be used in some prompt window. The TemporaryView should be used in this condition. A TemporaryView is launched when opening a window to interact with it. This is a reasonable design. Once this design is used, the client removes some functions and the server cancels the relative View implementation. So the codes for the client and the server are clean.
4. The TemporaryView could subscribe the field of the SessionView, which is an interactive way between the View essentially. However, it is not the unique interactive way. The interaction could be implemented through binding multiple view to the same record of one table at the same time. The memory table could be defined if necessary.
5. When the Variable field of the View changes, the whole field is synchronized to the client. If this field is a large structure, such as the complex bean, it might result in a relatively large network cost. In this condition, the memory table could be used, associating the xbean by using bind wad. The notification of the change about the xbean is expressed in the field of the xbean, which means if a field is defined with the variable way and the type is the bean with 100 fields, when one field changes, this field and the other 99 fields are packaged and sent out together. If a xbean with 100 fields is bound, when a field changes, only this field is sent. Of cause, from the client, the whole bind field changes.
6. Except for some operations that is over frequent so that the transaction might seriously affect the performance, the other operations should be finished in the storage procedure to guarantee the transaction specific. From the server, the most operations could not be without the data. In addition, the map is frequently used in most application. The temporary table with the any type value also provides a part of map ability and transaction specification. Do not forget to destroy the object when using any.
7. The View is write only to the server and read only to the client. In the generated class code of the View of the server, the member variable could be added to save some status if necessary. It is important. The View is not the all.
8. The operation in the View is thread safe and no need to use extra locker. The operation in the same View strictly guarantees the time sequence and executes according to the order of v.setA, v.setB, so that the client gets the notification A before the notification B. However, there is an issue in the multiple threads environment. The two threads execute this order at the same time and the client could see the AABB order. If there is strict requirement for the atomicity of the field set of the same view, the client must see the ABAB order. It seems that v.setA, v.setB must execute in a lock context. Actually, the View provides the better solution: without locker, v.schedule(()->{v.setA，v.setB}).