T
Traveller
Unregistered / Unconfirmed
GUEST, unregistred user!
提要：本文主要论述MIDAS对数据感知控件缺点的弥补，以及数据感知控件体系的合理性。
什么是数据感知控件
数据感知控件就是能够“自动”在数据库与用户之间交换数据的控件。它能够将用户的输入存入数据表，也能接收数据表的变更通知并刷新显示。
数据感知与设计模式
从设计模式的角度讲，数据感知控件主要应用的是中介者(Mediator)模式和观察者(Observer)模式。
中介者：
如果没有数据集的存在，用户对某些控件的值进行修改之后就必须负责更新其他所有相关控件，这个时候，控件之间的关联复杂度是n*n；通过引入数据集，使所有控件都只需要知道数据集的存在，而不需要知道其他控件，这样控件之间的耦合度就降低到n。
观察者：
数据集是实体数据，而控件都是观察者，计算、业务逻辑校验与存储由数据集来完成，而显示和格式化以及基本的输入校验则由数据感知控件来完成。数据敏感控件作为观察者注册到数据集的通知列表中，在数据变化的时候数据集就根据注册进来的通知列表逐个通知观察者刷新显示。
数据感知与OO
数据显示与输入两个职责可以分成：读取数据库、数据加工、格式化、接收输入、缓存、字段有效性校验、记录有效性校验、刷新显示、写入数据库等一系列操作，在纯OO方式下，需要一系列的类（这里最少得3个类才够）来配合完成，而传统的不用数据感知控件的编程方式下，这些操作其实全都在窗体里或者一个单独的单元里面写代码，这种方式完全是过程式的编码，最多只能说基于对象，离面向对象还有很大的距离。各种操作全都写在一个类里面，内聚度很差。
根据通用职责分配模式(GRASP)，读取、缓冲和写入数据库应该分配给一个对象（具体应用中，缓冲也可以单独分配一个对象）；校验应该分配给一个或两个对象；格式化、接受输入、显示需要分配给一个对象；数据加工（业务逻辑）需要分配给一个对象。
而在数据感知控件体系中：读取、写入是由数据集来完成的；缓冲是由内存表（比如ClientDataset、kbMemTable等）来完成的；数据校验作为数据集的一个事件来完成（复杂系统中必须改进为单独的类）；格式化、接收输入、显示则由数据感知控件来完成；数据加工没有提供具体支持，不过这本来就属于业务逻辑的范畴，控件体系中并非必须提供。
数据感知与复用
如果和Frame配合使用，则数据感知控件的复用程度是非常高的，一个信息表单可以作为一个元素进行复用，它能够完成数据显示和数据输入两项主要功能，而通过事件，可以对具体的行为进行定制。
数据感知的优点
数据感知的优点就是不用写太多对状态进行控制和对数据进行解释的代码，这些都可以由数据感知控件来完成，我们所要写的就是数据校验和数据加工两个和业务逻辑紧密相关的部分。而Delphi也提供了灵活性，让你可以自由掌握使用事件还是使用单独的类来完成，不过，我倾向于写单独的类，这样才够“专业”。
数据感知的缺点
数据感知的缺点其实主要是由于传统的数据感知控件体系中缺乏缓冲功能的导致的，表现在：1.直接连接数据库导致支持的用户数量有限；2.修改数据之后就会自动存入数据库，缺乏进行自己处理的机会；3.受数据库结构限制，往往无法提供必要的灵活性。
而基于MIDAS技术的ClientDataset控件提供了数据缓冲功能，可以先将数据下载到客户端、断开连接、修改、批量提交，这样问题1已经不复存在。在ClientDataset将数据提交到物理数据库之前，程序有机会对ClientDataset中缓冲的数据进行处理，并且可以自由选择是更新到数据库还是暂时存储在本地（即公文包），问题2也得到了解决；ClientDataset可以作为一个完全不连接物理数据库的自定义内存数据集，相当于在内存中提供了一个通用的结构来缓冲数据，应用程序可以从数据库读取数据，并且进行加工，然后存储到这个内存表中，而由于这个内存表也是数据集，数据感知控件并不需要知道他们之间的差别，当数据处理逻辑发生变化的时候，对数据感知控件完全影响，有效的阻止了变更的扩散。
数据感知的前景及应用
事实上，在C#等新型的语言及其类库中，数据感知是最受欢迎的特性之一，而基于Java的B/S结构很少有数据感知控件是因为系统的分布性很高，而浏览器的客户端又无法提供足够强大的功能，这也是B/S结构不适合进行大量数据录入的重要原因之一。
什么是数据感知控件
数据感知控件就是能够“自动”在数据库与用户之间交换数据的控件。它能够将用户的输入存入数据表，也能接收数据表的变更通知并刷新显示。
数据感知与设计模式
从设计模式的角度讲，数据感知控件主要应用的是中介者(Mediator)模式和观察者(Observer)模式。
中介者：
如果没有数据集的存在，用户对某些控件的值进行修改之后就必须负责更新其他所有相关控件，这个时候，控件之间的关联复杂度是n*n；通过引入数据集，使所有控件都只需要知道数据集的存在，而不需要知道其他控件，这样控件之间的耦合度就降低到n。
观察者：
数据集是实体数据，而控件都是观察者，计算、业务逻辑校验与存储由数据集来完成，而显示和格式化以及基本的输入校验则由数据感知控件来完成。数据敏感控件作为观察者注册到数据集的通知列表中，在数据变化的时候数据集就根据注册进来的通知列表逐个通知观察者刷新显示。
数据感知与OO
数据显示与输入两个职责可以分成：读取数据库、数据加工、格式化、接收输入、缓存、字段有效性校验、记录有效性校验、刷新显示、写入数据库等一系列操作，在纯OO方式下，需要一系列的类（这里最少得3个类才够）来配合完成，而传统的不用数据感知控件的编程方式下，这些操作其实全都在窗体里或者一个单独的单元里面写代码，这种方式完全是过程式的编码，最多只能说基于对象，离面向对象还有很大的距离。各种操作全都写在一个类里面，内聚度很差。
根据通用职责分配模式(GRASP)，读取、缓冲和写入数据库应该分配给一个对象（具体应用中，缓冲也可以单独分配一个对象）；校验应该分配给一个或两个对象；格式化、接受输入、显示需要分配给一个对象；数据加工（业务逻辑）需要分配给一个对象。
而在数据感知控件体系中：读取、写入是由数据集来完成的；缓冲是由内存表（比如ClientDataset、kbMemTable等）来完成的；数据校验作为数据集的一个事件来完成（复杂系统中必须改进为单独的类）；格式化、接收输入、显示则由数据感知控件来完成；数据加工没有提供具体支持，不过这本来就属于业务逻辑的范畴，控件体系中并非必须提供。
数据感知与复用
如果和Frame配合使用，则数据感知控件的复用程度是非常高的，一个信息表单可以作为一个元素进行复用，它能够完成数据显示和数据输入两项主要功能，而通过事件，可以对具体的行为进行定制。
数据感知的优点
数据感知的优点就是不用写太多对状态进行控制和对数据进行解释的代码，这些都可以由数据感知控件来完成，我们所要写的就是数据校验和数据加工两个和业务逻辑紧密相关的部分。而Delphi也提供了灵活性，让你可以自由掌握使用事件还是使用单独的类来完成，不过，我倾向于写单独的类，这样才够“专业”。
数据感知的缺点
数据感知的缺点其实主要是由于传统的数据感知控件体系中缺乏缓冲功能的导致的，表现在：1.直接连接数据库导致支持的用户数量有限；2.修改数据之后就会自动存入数据库，缺乏进行自己处理的机会；3.受数据库结构限制，往往无法提供必要的灵活性。
而基于MIDAS技术的ClientDataset控件提供了数据缓冲功能，可以先将数据下载到客户端、断开连接、修改、批量提交，这样问题1已经不复存在。在ClientDataset将数据提交到物理数据库之前，程序有机会对ClientDataset中缓冲的数据进行处理，并且可以自由选择是更新到数据库还是暂时存储在本地（即公文包），问题2也得到了解决；ClientDataset可以作为一个完全不连接物理数据库的自定义内存数据集，相当于在内存中提供了一个通用的结构来缓冲数据，应用程序可以从数据库读取数据，并且进行加工，然后存储到这个内存表中，而由于这个内存表也是数据集，数据感知控件并不需要知道他们之间的差别，当数据处理逻辑发生变化的时候，对数据感知控件完全影响，有效的阻止了变更的扩散。
数据感知的前景及应用
事实上，在C#等新型的语言及其类库中，数据感知是最受欢迎的特性之一，而基于Java的B/S结构很少有数据感知控件是因为系统的分布性很高，而浏览器的客户端又无法提供足够强大的功能，这也是B/S结构不适合进行大量数据录入的重要原因之一。