博文
就部件技术一些问题答redsms
|||
redsms：您好！
您深夜3点还在计算机上，真是难得。另外看了您的信也十分佩服，您所做的大量工作确实很有意义，从实用的角度来说非常有价值。我们都是希望能将数据库应用系统的开发工作简单化，提高开发效率与质量，从而进一步促进计算机的应用。目前还是金融危机时期，每一次经济危机都要靠技术进步来解决，一次大的经济危机往往会依靠技术进步产生新的产业，形成新的就业群，最终促进社会的进步。目前，为满足人们衣食住行等物质生活需要的产业已高度发展，生产力极大提高，某些产品在我国已趋向饱和。而为满足人们精神需要、提高生活质量、提高工作效率的产业方兴未艾，其处于最前沿的信息产业更还处于发展高峰期，离到达顶峰还很遥远。1969年美国国防部高级研究计划署ARPA资助建立了世界上第一个分组交换试验网ARPANET，1980年，TCP/IP协议研制成功，但直到1990年，互联网长期得不到广泛的应用。其原因是计算机应用太多太复杂了，环境与条件相异性也太巨大了，无法用简单的方法实现数据通信与信息共享。直到有了万维网（WEB），所有通信都统一为WEB形式传送，互联网才猛然飞快发展。这之后，从网格计算与点对点通信到云计算或框计算，人们一直在探讨怎样用更简单的方式实现更大规模的信息共享，使得计算机应用面更加普及与广泛。从这些年信息技术发展历程看，使用简单、操作方便的产品对于信息技术的广泛应用是具有深远意义的，只有这样的产品才能使信息技术应用更加普及，更加扩展。我想我们的研究是符合这一大方向的。我们的研究是希望在处理结构化数据的管理系统设计时，能找到一些容易使用的具有即插即用特性的部件，从而使管理信息系统的开发与维护尽可能简单与方便，这些部件要足够丰富，能尽量覆盖大多数信息系统的需要。我们提出的方法是不孤立地一个个地看各个应用系统的需求，而是围绕数据库与开发语言展开设计，面向一个虚拟的系统进行设计。我们认为，一个应用系统实际等于数据库+人机界面+数据处理程序，因此，简化系统设计，需要考虑的是怎样用最简单的方法将数据库、人机界面、数据处理程序联系起来，如何满足各种应用中对人机输入界面及输出界面的需要，首先是界面的物理构成，其次是数据规范化与一致性问题（包括代码问题与历史数据利用）、提高输入效率的问题（包括派生数据处理、异构数据整合、视图等问题）、保证输入正确性的问题（例如数据实体完整性、参照完整性、域完整性、数据安全性（也包括视图问题）、并行数据应对问题等）……。在这些问题中，而界面的物理构成是变化最多、模型化最困难的部分。根据我们的经验，当界面的物理构成变化时，会对全模块设计带来影响，后面一些问题的解决将需要不同的实现方法。因此，只用简单的一或几个界面生成的类是无法胜任的。部件的设计主要的是开发与使用简单化，科学家的任务不是让技术变得深奥难懂难使用，而是相反，要让复杂的东西得到简化。其方法一般是忽略次要因素，建立模型，找出对简化后的模型通用的方法。目前需要考虑的是，面临复杂多变的界面，什么是次要因素，如何建立模型，如何能满足应用的需要，如何才能使应用最简单。在应用系统开发中，如果"不编代码建立系统"肯定最简单，"不编代码建立系统"的模块具有最好的即插即用性，在应用于开发应用系统时效率最高，出错的可能性也最小。相当一部分应用模块如果能不编代码实现时，系统开发的成本将降到最低。另外，目前软件维护的费用在软件成本中所占比例越来越高，已经超过了开发费用，使用即插即用性好的软件也能最好适应环境的变化与需求的变化，能大大减少维护的费用。当前应用对系统稳定性、适应性、可扩展性要求越来越高，"不编代码建立系统"的软件毫无疑问能最好满足这样的需要。我们也承认，不编代码实现的系统决不可能满足所有系统的需要，只能用来实现一些简单且不复杂的系统。因此，“不编代码实现”构建系统不是我们的终极目标或全部目标。但是研究“不编代码实现”仍然十分有意义，一个方面是有大量“不编代码”就可以应用的模块毕竟是一个进步，毕竟可以为提高系统开发效率、降低维护成本、提高系统适应性与可扩展性产生积极作用。另一方面，当许多不编代码实现的模块设计出来后，大家会发现，在其原码的基础上略加修改与变化以实现更多的需求与更复杂的应用是可能的，它使另外一些模块设计变得简单与容易，因此，关于“不编代码实现”的课题无论从理论还是技术角度看都是有意义的。
您提到的另外一些问题，有些很有见地。但我要就其中几个问题谈谈我的想法，中间可能会有很微妙的分歧，供探讨吧。
“系统每一个界面都采用固定封闭程序来完成，如果使用一段时间后，用户提出在原界面中增加一个新功能，不知将如何方便实现”？实际上部件设计过程中也是将界面生成与处理分离的，因此，有些能够通过参数改变的功能需求，可以只通过改变参数实现，如果是全新的功能，通过增加按钮就可以实现。例如你举例提到的需要增加“新短信”功能，在我们的部件中只需要在数据表中增加“信件”与“回复”二个字段，无须对系统作任何变动就能达到目的。如果要求高一点，在参数表中给出不同的权限，性能会更好些，都不需要修改程序代码而自动实现。当然，如果遇到更复杂的修改要求，例如需要某种统计输出功能，希望还基于某一部件实现，那就不能不动程序了，但可以从其他部件中将有关按钮程序复制过来，或者再简单修改一下，就能实现，也将比较方便。
“万能查询界面，感觉不需要象您课题组的模块提供太多种类强大的查询”。虽然实际需要的大量查询需要的功能并不复杂，但是，考虑到能满足各种需求，我们的设计必须考虑各种变化。这就如设计一个全能的开发平台，对任何微小的需求都要考虑一样。例如，SQL语言是数据库通用语言，其设计就不能只考虑一部分应用，哪怕其应用率非常高。SQL语言中的查询语句，并不是只根据大多数需求来设计，不是单纯强要大家按其内容去规范化，而是考虑了尽可能多地去满足需求，虽然太复杂的需求也只能放弃，但是只要能用一条语句实现的查询它都想法实现。我们的设计只是将界面变化与SQL语句联系起来，使得建立实际系统时如果要用到SQL语句，都有界面的配合，都不需要大动干戈地去编写程序。再考虑到简单应用的界面应简单，复杂应用的界面要胜任，这才设计了大量的查询部件。简单的单条件查询部件尽量满足各类单条件查询的需要，从按字段查询到根据SQL语句进行的统计查询都能实现。其中简单的操作一般用户都能做，复杂的要程序员操作。比较复杂的查询界面内容肯定复杂，但我们也尽量求取解决方案，各个部件设计从简到难按SQL语句层次展开，满足不同层次用户的不同需求。
“采用一键一码的动态检索技术”是需要的，我们在根据某字段模糊查询的维护部件及单查询部件中也提供了该方法，可以根据输入的英文字符或汉字模糊查找，但不是根据拼音查找。
“我认为字典只有两种，一种为历史字典，对历史上已输入的数据罗列就可以了，不必形成固定独立的字典表，增加维护难度。如果是预定义字典，比如职称，职务，可点‘重定义字典’按钮维护预设字典表。两种字典的区别是是否要‘重定义字典’，即维护字典表。” 这和我们的处理基本一致，我们在所有的维护程序中都考虑了这一问题，关于使用字典或历史数据的方法有二大类，一种是统一用列表框显示供选数据，一种是用下拉组合框显示数据。又分为四种，一种是只显示代码字典表内容并只能点击供选，绝对保证数据的规范性与标准性。另一种是可以显示代码字典表内容且在参数表中不申明代码表时提供历史数据供选并只能点击供选，这种方式既提供代码的规范化，也有一定灵活性，当遇到代码中没有的码时，不是非要退出当前的操作，先去做代码表维护操作，再回过头来输入数据，对提高效率有好处；第三种是只显示代码字典表内容但可以点击供选也可以键盘输入，第四种是可以显示代码字典表内容且在参数表中不申明代码表时提供历史数据供选可以点击供选也可以键盘输入。其方法可以由用户通过参数任意设置任意组合，这样可以更多地满足用户需要。
“不采用教科书中预先固定ODBC连接串的形式，采用更为灵活的SPT动态连接方法，需要连接串来定义数据库类型和位置。” 在我们的系统中二种方法都使用了，如果是一般应用，采用建立ODBC数据源的方式，这样比较简单，容易为用户接受，便于普通用户操作。如果涉及在远程数据库中建立新表的操作，例如建表、数据表结构维护、数据导入导出等，则采用SPT动态连接方法实现，设计了比较简单的界面使得用户操作起来也很简单。
“本界面管理哪些字段，及英文字段对应的中文名称。在界面中比如列表的表头，万能查询，万能字典中不能出现英文字段名，用户会看不懂，出现英文字段名的地方，必须用中文名称替换”。这是基本问题，我们大多采用建立字典表的方法解决，某些只涉及字段名变换，在查询、导入导出中还要求对相包容的数据类型、宽度、小数位等结构变化也能自动适应，使自动解决异构数据的处理问题，这些问题的解决，有些要求建立字典表（例如名称的改变），也有许多采用自适应方法实现。
“通过一个集成的界面类和三个设置表，十分钟就可以构建一个表从录入至打印的全部功能。主要工作在于对表单对应的设置表录入各种参数，并且微调界面中各控件的位置及宽度，屏蔽一些功能，继承发展一些特定需求”。 以上内容利用部件只几秒钟就实现，只要在参数表中设置就可以了。如果要可视化地微调界面也十分简单，需要的时间依调整工作量大小而定。如果涉及代码表、派生数据、数字化调整界面、安全性、域完整性等问题，需要时间会多一点，但几分钟一般也可搞定。
“程序主框架的集成主界面”考虑很好。目前我们只想设计出设置尽量简单、参数尽量规范统一，控制在一、二十个以内的简单部件。你在该集成界面中提到的几个问题在部件中都有简单的考虑：（1）屏幕大小问题。我们部件屏幕大小采用分三个等级自适应调整；（2）是否有登录界面问题。我们部件统一为有登录；（3）字体大小问题。我们部件只有少数设了改变字体与大小，没有改变分辨率功能；（4）忽略一切错误与并行调用问题。我们部件统一设为忽略一切错误、全都可以多次调用反复运行，可以并行用在相同对象上；（5）备份与恢复问题。我们设计了导入导出（包括新生与复制）部件，可以实现数据备份与恢复；你所提到的问题中也有部件未考虑的问题，例如背景、单位等问题。这些问题需要增加参数总量才能解决。
“课题组是否能引入一个商业级的程序员，更好地表达思想。感觉贵课题组提供的例程，界面美观上、功能实用上似乎达不到生产需求。有些界面显得繁杂，带有一些生产中肯定不会使用的功能。” 这个意见很好，不过，我们由于得不到任何支持，目前只能停留在理论研究阶段，我们只想通过目前的设计说明我们的思想，希望大家能认识到部件不是不可实现的。另外，我们希望当前实现的软件能成为一个优秀的教学工具，以它为基础构建数据库课程的教学实验平台。在任何工作中，良好工具都是提高效率与质量的利器，我们学校采用这一套工具用于数据库课程与管理信息系统课程的教学，比较好地提高了教学效果。目前大多数学校都不开VFP了，要用这套工具于教学中，就要求不会VFP不影响它的应用。这也是我们研究不写代码建立应用系统的一个原因。
“不需要为了追求完善强大的功能，而摆出太多按钮和控件。贵课题中一些例程中有些界面具有大量的按钮，作为程序员的我都不知所措，估计评审专家肯定更加头晕”。这个意见有必要进行商榷。我们希望通过尽可能地在一个界面中容纳足够多的按钮，而在设计使用时通过选择参数实现不同功能，目的是既覆盖应用，又减少部件总量，使得总的应用尽可能简单，要求部件在建立界面时自动适应功能变化的需要。我们认为这是我们设计中的一个亮点。
“关于用类来开发通用系统比固定的表单开发来得更灵活”。用类来开发通用系统实际是面向对象的基本思想。但是，技术在不断进步之中，现在已经出现了构件与部件的设计，它们是软件复用理论与技术的进步与发展，目的是提高效率、提高质量，并使开发变得简单。而用类来开发实际系统，设计难度没有显著降低、“效率提高”也没有到大家期望的高度。
“似乎不能过于宣传代码一字不写就能建立新系统。有些师兄拿九十年代末的雅奇MIS试图一字不编程就想制作一个管理系统。后来都发现仅能做一个很简单通用系统，一但和行业挂钩，许多行业的统计分析都无法实现。例如林业上有些报表必须要借助EXCEL的VBA二次开发才可以实现，如图12。交通上许多报表必须对矩阵迭代计算。有做过特定行业软件开发评审专家听到这样不编程构建系统的宣传肯定觉得不现实。我认为提法上，描述成为可二次开发高集成软件开发平台，似乎更合理些”。关于这一问题我前面已经提到了。“代码一字不写就能建立新系统”只是一种希望设计过程尽可能简单的一种研究，目的不是所有系统都不编代码实现，但是如果有许多应用或应用的许多模块能“代码一字不写”肯定对系统设计、维护与应用大众化有帮助，研究是有意义的。“代码一字不写就能建立新系统”毕竟在技术上需要研究与考虑许多新问题，从理论上讲也是有意义的，从实用上讲对提高系统整体开发效率也肯定是有意义的。
“现在申请课题，在核心刊物上发表论文，许多专家对VFP有偏见，一看到vfp开发的就通过不了，您的课题组可试试C#，感觉这个语言和VFP、和JAVA有许多共性。很多VFP程序员同时也掌握了C#开发语言。而且C#可以开发C/S，B/S的项目。B/S项目显然是未来发展趋势，如果设计B/S的软部件系统，我一直在思考如何实现B/S下的C#通用部件的开发，感觉难度超过了C/S。B/S类的通用模块能让评审专家感觉前景宽广。我还没机会看到贵课题组编写的java通用部件系统，所以不太清楚贵组的JAVA通用系统在b/s应用的开发情况”。 这是非常中肯的意见。我们的部件系统基本上未在B/S模式下实现，在JAVA环境中只研究设计了基于C/S模式的部件，这是由于语言的背景的差异造成的，是还需要加强研究的。也要辨证地去看这一问题，关于VFP，我在有些文章中已经提及，它是很有优势的，如果我国、我国的专家们都跟着微软的鞭子转，对于我国应用的发展是不利的。我还要说，微软放弃他们用大量美金购入又经营十多年的VFP是不得已的，从某种意义来讲，他们已经被我们的部件打败了，我们研究的丰富的部件在几乎所有开发工具上都优于VFP原配的开发工具，都更具有实用性。我国不利用我们已经取得的优势去发展我们自己的应用与产业是我国科技的悲哀。另外，B/S模式的简单使得研究了十多年而没有进展的互联网得到广泛的应用，从而成一统天下。但是，什么都变成WEB也太简单了，是不可能满足所有应用需求的。如果能有适应面较大的简单的技术与方法，将使能同时发挥服务器与客户机作用的C/S模式更有吸引力，而我们的部件技术，未尝不会是网络中处理结构化数据的一种可选方案呢。
关于“复杂表格”问题，我们的部件还不能直接生成，但不是不可实现的。你所举的例子目前可以利用交差表程序生成格式文件，再手工修改表头实现。相对EXCEL，采用数据库的方法，当一个格式文件修改好后，可以长期的使用，其优越性也是十分明显的。
以上只是我个人的意见，可能十分主观与片面，存在许多错误，欢迎进一步地给予批评。非常感谢您的意见，许多内容都让我受到启发，希望今后能多多联系与探讨，促进软件复用技术的发展。
祝好！
https://blog.sciencenet.cn/blog-2551-251643.html
上一篇：基于VFP部件库最小系统网络版研究
下一篇：VFP部件库最小系统网络版使用说明书
您深夜3点还在计算机上，真是难得。另外看了您的信也十分佩服，您所做的大量工作确实很有意义，从实用的角度来说非常有价值。我们都是希望能将数据库应用系统的开发工作简单化，提高开发效率与质量，从而进一步促进计算机的应用。目前还是金融危机时期，每一次经济危机都要靠技术进步来解决，一次大的经济危机往往会依靠技术进步产生新的产业，形成新的就业群，最终促进社会的进步。目前，为满足人们衣食住行等物质生活需要的产业已高度发展，生产力极大提高，某些产品在我国已趋向饱和。而为满足人们精神需要、提高生活质量、提高工作效率的产业方兴未艾，其处于最前沿的信息产业更还处于发展高峰期，离到达顶峰还很遥远。1969年美国国防部高级研究计划署ARPA资助建立了世界上第一个分组交换试验网ARPANET，1980年，TCP/IP协议研制成功，但直到1990年，互联网长期得不到广泛的应用。其原因是计算机应用太多太复杂了，环境与条件相异性也太巨大了，无法用简单的方法实现数据通信与信息共享。直到有了万维网（WEB），所有通信都统一为WEB形式传送，互联网才猛然飞快发展。这之后，从网格计算与点对点通信到云计算或框计算，人们一直在探讨怎样用更简单的方式实现更大规模的信息共享，使得计算机应用面更加普及与广泛。从这些年信息技术发展历程看，使用简单、操作方便的产品对于信息技术的广泛应用是具有深远意义的，只有这样的产品才能使信息技术应用更加普及，更加扩展。我想我们的研究是符合这一大方向的。我们的研究是希望在处理结构化数据的管理系统设计时，能找到一些容易使用的具有即插即用特性的部件，从而使管理信息系统的开发与维护尽可能简单与方便，这些部件要足够丰富，能尽量覆盖大多数信息系统的需要。我们提出的方法是不孤立地一个个地看各个应用系统的需求，而是围绕数据库与开发语言展开设计，面向一个虚拟的系统进行设计。我们认为，一个应用系统实际等于数据库+人机界面+数据处理程序，因此，简化系统设计，需要考虑的是怎样用最简单的方法将数据库、人机界面、数据处理程序联系起来，如何满足各种应用中对人机输入界面及输出界面的需要，首先是界面的物理构成，其次是数据规范化与一致性问题（包括代码问题与历史数据利用）、提高输入效率的问题（包括派生数据处理、异构数据整合、视图等问题）、保证输入正确性的问题（例如数据实体完整性、参照完整性、域完整性、数据安全性（也包括视图问题）、并行数据应对问题等）……。在这些问题中，而界面的物理构成是变化最多、模型化最困难的部分。根据我们的经验，当界面的物理构成变化时，会对全模块设计带来影响，后面一些问题的解决将需要不同的实现方法。因此，只用简单的一或几个界面生成的类是无法胜任的。部件的设计主要的是开发与使用简单化，科学家的任务不是让技术变得深奥难懂难使用，而是相反，要让复杂的东西得到简化。其方法一般是忽略次要因素，建立模型，找出对简化后的模型通用的方法。目前需要考虑的是，面临复杂多变的界面，什么是次要因素，如何建立模型，如何能满足应用的需要，如何才能使应用最简单。在应用系统开发中，如果"不编代码建立系统"肯定最简单，"不编代码建立系统"的模块具有最好的即插即用性，在应用于开发应用系统时效率最高，出错的可能性也最小。相当一部分应用模块如果能不编代码实现时，系统开发的成本将降到最低。另外，目前软件维护的费用在软件成本中所占比例越来越高，已经超过了开发费用，使用即插即用性好的软件也能最好适应环境的变化与需求的变化，能大大减少维护的费用。当前应用对系统稳定性、适应性、可扩展性要求越来越高，"不编代码建立系统"的软件毫无疑问能最好满足这样的需要。我们也承认，不编代码实现的系统决不可能满足所有系统的需要，只能用来实现一些简单且不复杂的系统。因此，“不编代码实现”构建系统不是我们的终极目标或全部目标。但是研究“不编代码实现”仍然十分有意义，一个方面是有大量“不编代码”就可以应用的模块毕竟是一个进步，毕竟可以为提高系统开发效率、降低维护成本、提高系统适应性与可扩展性产生积极作用。另一方面，当许多不编代码实现的模块设计出来后，大家会发现，在其原码的基础上略加修改与变化以实现更多的需求与更复杂的应用是可能的，它使另外一些模块设计变得简单与容易，因此，关于“不编代码实现”的课题无论从理论还是技术角度看都是有意义的。
您提到的另外一些问题，有些很有见地。但我要就其中几个问题谈谈我的想法，中间可能会有很微妙的分歧，供探讨吧。
“系统每一个界面都采用固定封闭程序来完成，如果使用一段时间后，用户提出在原界面中增加一个新功能，不知将如何方便实现”？实际上部件设计过程中也是将界面生成与处理分离的，因此，有些能够通过参数改变的功能需求，可以只通过改变参数实现，如果是全新的功能，通过增加按钮就可以实现。例如你举例提到的需要增加“新短信”功能，在我们的部件中只需要在数据表中增加“信件”与“回复”二个字段，无须对系统作任何变动就能达到目的。如果要求高一点，在参数表中给出不同的权限，性能会更好些，都不需要修改程序代码而自动实现。当然，如果遇到更复杂的修改要求，例如需要某种统计输出功能，希望还基于某一部件实现，那就不能不动程序了，但可以从其他部件中将有关按钮程序复制过来，或者再简单修改一下，就能实现，也将比较方便。
“万能查询界面，感觉不需要象您课题组的模块提供太多种类强大的查询”。虽然实际需要的大量查询需要的功能并不复杂，但是，考虑到能满足各种需求，我们的设计必须考虑各种变化。这就如设计一个全能的开发平台，对任何微小的需求都要考虑一样。例如，SQL语言是数据库通用语言，其设计就不能只考虑一部分应用，哪怕其应用率非常高。SQL语言中的查询语句，并不是只根据大多数需求来设计，不是单纯强要大家按其内容去规范化，而是考虑了尽可能多地去满足需求，虽然太复杂的需求也只能放弃，但是只要能用一条语句实现的查询它都想法实现。我们的设计只是将界面变化与SQL语句联系起来，使得建立实际系统时如果要用到SQL语句，都有界面的配合，都不需要大动干戈地去编写程序。再考虑到简单应用的界面应简单，复杂应用的界面要胜任，这才设计了大量的查询部件。简单的单条件查询部件尽量满足各类单条件查询的需要，从按字段查询到根据SQL语句进行的统计查询都能实现。其中简单的操作一般用户都能做，复杂的要程序员操作。比较复杂的查询界面内容肯定复杂，但我们也尽量求取解决方案，各个部件设计从简到难按SQL语句层次展开，满足不同层次用户的不同需求。
“采用一键一码的动态检索技术”是需要的，我们在根据某字段模糊查询的维护部件及单查询部件中也提供了该方法，可以根据输入的英文字符或汉字模糊查找，但不是根据拼音查找。
“我认为字典只有两种，一种为历史字典，对历史上已输入的数据罗列就可以了，不必形成固定独立的字典表，增加维护难度。如果是预定义字典，比如职称，职务，可点‘重定义字典’按钮维护预设字典表。两种字典的区别是是否要‘重定义字典’，即维护字典表。” 这和我们的处理基本一致，我们在所有的维护程序中都考虑了这一问题，关于使用字典或历史数据的方法有二大类，一种是统一用列表框显示供选数据，一种是用下拉组合框显示数据。又分为四种，一种是只显示代码字典表内容并只能点击供选，绝对保证数据的规范性与标准性。另一种是可以显示代码字典表内容且在参数表中不申明代码表时提供历史数据供选并只能点击供选，这种方式既提供代码的规范化，也有一定灵活性，当遇到代码中没有的码时，不是非要退出当前的操作，先去做代码表维护操作，再回过头来输入数据，对提高效率有好处；第三种是只显示代码字典表内容但可以点击供选也可以键盘输入，第四种是可以显示代码字典表内容且在参数表中不申明代码表时提供历史数据供选可以点击供选也可以键盘输入。其方法可以由用户通过参数任意设置任意组合，这样可以更多地满足用户需要。
“不采用教科书中预先固定ODBC连接串的形式，采用更为灵活的SPT动态连接方法，需要连接串来定义数据库类型和位置。” 在我们的系统中二种方法都使用了，如果是一般应用，采用建立ODBC数据源的方式，这样比较简单，容易为用户接受，便于普通用户操作。如果涉及在远程数据库中建立新表的操作，例如建表、数据表结构维护、数据导入导出等，则采用SPT动态连接方法实现，设计了比较简单的界面使得用户操作起来也很简单。
“本界面管理哪些字段，及英文字段对应的中文名称。在界面中比如列表的表头，万能查询，万能字典中不能出现英文字段名，用户会看不懂，出现英文字段名的地方，必须用中文名称替换”。这是基本问题，我们大多采用建立字典表的方法解决，某些只涉及字段名变换，在查询、导入导出中还要求对相包容的数据类型、宽度、小数位等结构变化也能自动适应，使自动解决异构数据的处理问题，这些问题的解决，有些要求建立字典表（例如名称的改变），也有许多采用自适应方法实现。
“通过一个集成的界面类和三个设置表，十分钟就可以构建一个表从录入至打印的全部功能。主要工作在于对表单对应的设置表录入各种参数，并且微调界面中各控件的位置及宽度，屏蔽一些功能，继承发展一些特定需求”。 以上内容利用部件只几秒钟就实现，只要在参数表中设置就可以了。如果要可视化地微调界面也十分简单，需要的时间依调整工作量大小而定。如果涉及代码表、派生数据、数字化调整界面、安全性、域完整性等问题，需要时间会多一点，但几分钟一般也可搞定。
“程序主框架的集成主界面”考虑很好。目前我们只想设计出设置尽量简单、参数尽量规范统一，控制在一、二十个以内的简单部件。你在该集成界面中提到的几个问题在部件中都有简单的考虑：（1）屏幕大小问题。我们部件屏幕大小采用分三个等级自适应调整；（2）是否有登录界面问题。我们部件统一为有登录；（3）字体大小问题。我们部件只有少数设了改变字体与大小，没有改变分辨率功能；（4）忽略一切错误与并行调用问题。我们部件统一设为忽略一切错误、全都可以多次调用反复运行，可以并行用在相同对象上；（5）备份与恢复问题。我们设计了导入导出（包括新生与复制）部件，可以实现数据备份与恢复；你所提到的问题中也有部件未考虑的问题，例如背景、单位等问题。这些问题需要增加参数总量才能解决。
“课题组是否能引入一个商业级的程序员，更好地表达思想。感觉贵课题组提供的例程，界面美观上、功能实用上似乎达不到生产需求。有些界面显得繁杂，带有一些生产中肯定不会使用的功能。” 这个意见很好，不过，我们由于得不到任何支持，目前只能停留在理论研究阶段，我们只想通过目前的设计说明我们的思想，希望大家能认识到部件不是不可实现的。另外，我们希望当前实现的软件能成为一个优秀的教学工具，以它为基础构建数据库课程的教学实验平台。在任何工作中，良好工具都是提高效率与质量的利器，我们学校采用这一套工具用于数据库课程与管理信息系统课程的教学，比较好地提高了教学效果。目前大多数学校都不开VFP了，要用这套工具于教学中，就要求不会VFP不影响它的应用。这也是我们研究不写代码建立应用系统的一个原因。
“不需要为了追求完善强大的功能，而摆出太多按钮和控件。贵课题中一些例程中有些界面具有大量的按钮，作为程序员的我都不知所措，估计评审专家肯定更加头晕”。这个意见有必要进行商榷。我们希望通过尽可能地在一个界面中容纳足够多的按钮，而在设计使用时通过选择参数实现不同功能，目的是既覆盖应用，又减少部件总量，使得总的应用尽可能简单，要求部件在建立界面时自动适应功能变化的需要。我们认为这是我们设计中的一个亮点。
“关于用类来开发通用系统比固定的表单开发来得更灵活”。用类来开发通用系统实际是面向对象的基本思想。但是，技术在不断进步之中，现在已经出现了构件与部件的设计，它们是软件复用理论与技术的进步与发展，目的是提高效率、提高质量，并使开发变得简单。而用类来开发实际系统，设计难度没有显著降低、“效率提高”也没有到大家期望的高度。
“似乎不能过于宣传代码一字不写就能建立新系统。有些师兄拿九十年代末的雅奇MIS试图一字不编程就想制作一个管理系统。后来都发现仅能做一个很简单通用系统，一但和行业挂钩，许多行业的统计分析都无法实现。例如林业上有些报表必须要借助EXCEL的VBA二次开发才可以实现，如图12。交通上许多报表必须对矩阵迭代计算。有做过特定行业软件开发评审专家听到这样不编程构建系统的宣传肯定觉得不现实。我认为提法上，描述成为可二次开发高集成软件开发平台，似乎更合理些”。关于这一问题我前面已经提到了。“代码一字不写就能建立新系统”只是一种希望设计过程尽可能简单的一种研究，目的不是所有系统都不编代码实现，但是如果有许多应用或应用的许多模块能“代码一字不写”肯定对系统设计、维护与应用大众化有帮助，研究是有意义的。“代码一字不写就能建立新系统”毕竟在技术上需要研究与考虑许多新问题，从理论上讲也是有意义的，从实用上讲对提高系统整体开发效率也肯定是有意义的。
“现在申请课题，在核心刊物上发表论文，许多专家对VFP有偏见，一看到vfp开发的就通过不了，您的课题组可试试C#，感觉这个语言和VFP、和JAVA有许多共性。很多VFP程序员同时也掌握了C#开发语言。而且C#可以开发C/S，B/S的项目。B/S项目显然是未来发展趋势，如果设计B/S的软部件系统，我一直在思考如何实现B/S下的C#通用部件的开发，感觉难度超过了C/S。B/S类的通用模块能让评审专家感觉前景宽广。我还没机会看到贵课题组编写的java通用部件系统，所以不太清楚贵组的JAVA通用系统在b/s应用的开发情况”。 这是非常中肯的意见。我们的部件系统基本上未在B/S模式下实现，在JAVA环境中只研究设计了基于C/S模式的部件，这是由于语言的背景的差异造成的，是还需要加强研究的。也要辨证地去看这一问题，关于VFP，我在有些文章中已经提及，它是很有优势的，如果我国、我国的专家们都跟着微软的鞭子转，对于我国应用的发展是不利的。我还要说，微软放弃他们用大量美金购入又经营十多年的VFP是不得已的，从某种意义来讲，他们已经被我们的部件打败了，我们研究的丰富的部件在几乎所有开发工具上都优于VFP原配的开发工具，都更具有实用性。我国不利用我们已经取得的优势去发展我们自己的应用与产业是我国科技的悲哀。另外，B/S模式的简单使得研究了十多年而没有进展的互联网得到广泛的应用，从而成一统天下。但是，什么都变成WEB也太简单了，是不可能满足所有应用需求的。如果能有适应面较大的简单的技术与方法，将使能同时发挥服务器与客户机作用的C/S模式更有吸引力，而我们的部件技术，未尝不会是网络中处理结构化数据的一种可选方案呢。
关于“复杂表格”问题，我们的部件还不能直接生成，但不是不可实现的。你所举的例子目前可以利用交差表程序生成格式文件，再手工修改表头实现。相对EXCEL，采用数据库的方法，当一个格式文件修改好后，可以长期的使用，其优越性也是十分明显的。
以上只是我个人的意见，可能十分主观与片面，存在许多错误，欢迎进一步地给予批评。非常感谢您的意见，许多内容都让我受到启发，希望今后能多多联系与探讨，促进软件复用技术的发展。
祝好！
https://blog.sciencenet.cn/blog-2551-251643.html
上一篇：基于VFP部件库最小系统网络版研究
下一篇：VFP部件库最小系统网络版使用说明书
