一、取数虚模式

对于列表方式数据查询，应用框架统一使用虚模式进行取数。

1.意图：

在数据量较大的情况下，进行分批取数，减少网络流量，加快响应速度。

2.动机：

在信息系统中，数据查询是最常用的操作，但如果查询结果数据量很大情况下，一方面会增加网络传输的数据量，另一方面是一个耗时的过程，客户会出现一个可能较长时间的等待。这两方面都会降低软件的可用性。

为解决这个问题，我们使用虚模式。如果列表中定义了主键，则先取前100条数据，然后在后台获取所有的数据ID值。如果没有定义主键，则使用top 100等方式来获取。后一种方式不推荐使用。

3.适用性：

在数据量较大情况下非常有效。

如果是海量数据，如查询结果很大，比如100000条以上，所有的ID获取也是一个不小的数据量与耗时过程，这时需要进行特殊处理。

4.应用：

ListUI中使用。

5.缺点及注意事项：

因为大于100条数据时，会启动一个后台线程来取数。在大并发情况下会出现N*2的数据请求量。

二、操作状态提示模式

对于操作提示，应用框架统一了提示方式。如果界面中有状态条，则在状态条中提示；如果没有状态条，则为对应框方式处理。

1.意图：

在状态条中进行统一信息提示。

2.动机：

在企业信息管理系统中，用户与系统的交互非常多。在用户操作过程中，一些非法的提示、成功完成操作，不成功的操作，我们传统的做法是给用户一个对话框提示，显示这些信息。但这样一来，我们会增加用户的无意义的操作，中断用户的连续操作，对用户非常不友好。

为了解决这类问题，对于一些系统的提示，采用状态条进行统一的提示，减少用户的一些无意义的操作。用户仅在状态栏就可以获取系统信息。

3.适用性：

对用户的一些常用而且连续的操作界面，我们这种模式大大方便用户的交互。

对于无状态栏或信息较多的情况无能为力。

4.应用：

CoreUI,EditUI

5.缺点及注意事项：

对于模式对话框，目前由于没有显示状态栏，所以此模式不生效

三、后台操作模式

对于长时间的耗时操作，应用框架统一了处理机制，当前界面锁定，状态栏进度条提示。但用户可切换到其他业务界面继续操作。

1.意图：

长时间操作进行多线程处理，不影响其他任务。

2.动机：

在企业应用管理系统中，有一些长时间的操作功能，如过账、结账等功能。这时传统的做法会让用户等待，直到操作完成。这样用户这段时间内基本上对系统不可操作，大大降低了用户的可用性。

为了解决这个问题，框架采用了对某些功能使用多线程机制，对于耗时操作新起一个线程来运行。这样其他任务还可以继续使用，增加了用户体验。

3.适用性：

对于一些操作提供了方便。

长时间操作的当前操作页签会锁定，直到系统完成后释放。

4.应用：

CoreUI

5.缺点及注意事项：

如果业务系统的状态在锁定之后控件完成一些状态改变，当后台操作完成后的状态恢复不生效。需要特别注意处理。

四、快速定位模式

对于列表方式数据查询，业务系统可定制定位字段，应用框架根据定制字段在列表中自动定位。

1.意图：

对于大数据量情况下，快速定位到用户期望操作的数据下。

2.动机：

对于大数据量的列表，框架已经使用了虚模式，但用户要在列表中找一条符合条件的数据，就可能需要拉动滑动条来查看，这对于用户来说是一件不愉快的事。

为了解决这个问题，我们对常用的列使用了快速定模式，方便用户来进行查找操作。

3.适用性：

用户可快速地在列表中找到符合条件的记录。

4.应用：

ListUI

5.缺点及注意事项：

由于此定位方式是基于表格查找方法，最差的情况上，把所有虚模式的数据取回来后发现没有匹配项，这时提示用户没有找到。这种情况下效率最差。

五、表头排序模式

对于列表浏览界面，可通过单击表头来实现使用表头字段进行重新的全排序。

1.意图：

对于列表数据，用户可自由地重新排序他希望的列。

2.动机：

对于大数据量的列表结果，通常我们做过滤时会让用户指定排序的列。但在结果查询后，用户也希望可以在结果集中进行重新排序，而不是进行重新过滤后指定排序字段。

为了解决这个问题，我们允许用户对指定的表列头进行排序，而不需要重新在过滤中指定排序字段。

3.适用性：

用户可对结果集进行快速的重新排序。

4.应用：

ListUI表头排序。

5.缺点及注意事项：

如果表格中有列为Query中没有的，会出错。

六、界面状态管理模式

对于新增、查看、编辑状态进行了统一处理。

七、数据绑定模式