`
cloudtech
  • 浏览: 4578328 次
  • 性别: Icon_minigender_1
  • 来自: 武汉
文章分类
社区版块
存档分类
最新评论

自定义“TB_定位访问”子类

 
阅读更多

自定义“TB_定位访问”子类


在很多应用中,经常需要通过某个“特征值”从给定的数据对象(前台的数据集或后台的物理表)中得到一条(或一组)满足约束的记录,并在此基础上实现某种给定的后续功能,“TB_定位访问”就是要以最简洁的操作并经过标准化的封装设计实现这一系列的连续动作。
4.3.1.1 命题提出
对数据库的访问是实现过程中必不可少的实现过程,由于物理表可能是个庞大的记录集合,要想从中找到某个需要的目标记录并不是件容易的事。一般会通过某些事先知道的“特征值”并形成恰当的逻辑表达式,然后再通过逻辑条件达到记录搜索的目的。在项目的设计过程中,类似的数据方位需求太多了,所以就有必要封装一个专用的控件类来支持这种普遍存在的操作模式。
由于目标对象可能不同、访问方式不同、对速度的关注程度不同、得到数据后的处理方式不同等,我们首先要分析需求在应用场景中的表现形态与实现目标。
1)特征值与搜索方式:
1.使用的数据意义会随机变化,如助记码、编号、名称等;
2.执行搜索的方式会有所不同,如左匹配、精确匹配、模糊查找等。
2)关心的侧重点的要求不同:
1.关心反映速度,比如超市的收银台系统对速度就比较关心;
2.关心查找范围,在特征值模糊不清时对识别范围与匹配方式会更感兴趣。
3)搜索结果所存在的可能性:
1.对应的记录不存在:可能会导致操作的重复或改变操作逻辑等不同的后果;
2.记录唯一:操作目的达到;
3.一条以上的记录集:一般会导致记录选择的操作,可能从中选一,也可能从中选出一组。
4)实现数据方位的目的性:
1.通过特征值把指针定位到当前数据集中的一条记录,并作为操作对象;
2.通过被访问的数据刷新屏幕上的一个或一组控件,为操作员提供引用环境;
3.同步刷新其他可能存在的关联关系的数据集;
4.通过得到的数据集改写另外一个数据集或是插入到另外一个数据集。
5)数据源对象的类型不同:
1.本地化的数据集DateTabel;
2.Grid数据容器DataGridView。
这里提出的每个问题一般不会独立存在,所以不能进行粒度级别更小的封装,因为这些需求经常会以相关、连续的组合形态出现。因为命题所涉及的变化因素较多,所以每个问题的解决都需要“自定义属性”的配合,才有可能满足适应性方面的要求。
提示:我们可以把上述问题分解成两个不同的层次,一个层次以“定位访问”为实现目标,它所派生的子类“定位插入”则会在此基础上提供后续的数据处理过程。
4.3.1.2 设计构思
这个构思的路径较长,叙述起来比较麻烦,不便于理解。我们可以给出几个应用中的实际命题来说明这个设计所要达到的目的。
1)在维护或查阅大数据量的数据集时,希望能够通过简约的特征值快速实现指针定位;
2)在创建一张往来票据的时候,希望快速查阅往来法人并确定对方单位,同时需要用法人数据刷新屏幕上的相关的控件。
这个控件的设计主题大约包括四个构思阶段:
1)接收录入值:分析录入值的特征字,确定数据访问的相关参数与实现方式;
2)数据访问:根据录入的特征值及确定的方式实现对参照物理表的访问;
3)处理返回值:根据返回的记录数确定处理方式,最终得到其中一条记录;
4)实现操作目的:用得到的数据进行记录定位或数据刷新。
因为该控件继承了“ITF_绑定”接口,所以同样能够与字段实现绑定,还能够支持数据录入的有关功能。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics