2,748
社区成员
发帖
与我相关
我的任务
分享[讨论] FOXPRO8中应该废弃的功能模块！
[讨论] FOXPRO8中应该废弃的功能模块！
之所以说要废弃，只是因为觉得这些功能似乎已经没有什么实用功能了或存在的意义了，完全可以用更好的方法来实现它！！纯属个人观点，扔出来供大家讨论，共同进步，希望大家都发表一些自己的意见！
[1] 首当其冲应该扔掉的是[视图]，包括[本地试图][远程试图]
之所以要说首当其冲，就是因为试图本来就是一段SQL代码+DBSETPROP()的集合体
现在VFP8中有了CURSORADAPTER,功能非常强大，可以使用目前比较流行的几种数据连接（访问）方式，使用XML更是可以将VFP的身价提高一个档次，可以和.NET平台来交换数据，ADO的访问方式也是让人激动不已，最主要CURSORADAPTER是一个基本类，有自己的事件，方法，属性。可以完全脱离DBC来使用。整合了[本地试图][远程试图]，数据访问的方式从来没有这么酷！
就目前来说，CA的BUILDER是有点烂，可是试图编辑器其实就是个BUILDER,用这个更显别扭，虽然VFP8对VIEW BUILDER作了不少改动，比如查看SQL时可以看到DB属性，不过似乎已经没什么意义了！
[2] 接下来受害的就应该是[CONNECTION（连接）]了，因为在我看来CONNECTION就是为REMOTE VIEW而存在的，既然REMOTE VIEW都没必要了，那它也就跟着受害了！呵呵！这一点就不多说了！
[3] 关于这个该废弃的功能模块也许说出来大家会有点反感，不过也是正常的，它就是：自有表。
从出现数据库的时候我就发现自有表似乎已经没有存在的意义了！虽然说有时候做单表单或临时使用表的时候他提供了极大的方便，可以随时使用，自由存储。但自由表就如他的名字一样，比较自由，功能属性方面也没有数据库表那么强大，如果按一种标准化的概念来理解或评定自由表的话，那么它应该不伦不类！所以提出此点旨在希望大家应该逐步努力的去使用比较标准化的东西，即使现在又是自由表的使用和存储方面确实比数据库表方便的多，但在我看来自由表的寿命已经不长了。
[4] 在以前的FOXBASE和现在的FOXPRO语法中都有一个约定，就是可以使用最少4个省略的命令或函数来代替完整的。那在我看来这个功能现在已经开始出现问题了！因为出现这个功能的初衷是为大家写代码提供极大的方便，可以少些不少，确实博得了大众欢欣。可是随着VFP版本的不断更新，出现了越来越多的命令、函数、以及事件、方法、属性等，而原有的已经不太实用的命令函数又要照顾低版本的FOX,不可能随便废掉。那随便想一想就会知道4个字符已不足以来区分如此多的命令、函数。。。。（注：也许这也是VFP使用SYS()系列来扩充函数数量的原因吧！哈哈!），而且再看看哪种语言中有这个约定，这对于标准化也是极为不利的事情，所以我在想，VFP的[智能感应]功能推出的一方面的原因是这个功能是个迫切需要，因为其他语言基本都有了，而且使用确实方便，可以在一定程序上减少出错的几率！那另一方面就是VFP的开发组开始规范代码格式了，你写四个简略的代码，我尽量给你补全，哈哈！
所以给大家提个建议，写代码的时候尽量将代码写全，以免以后升级的时候新的VFP版本不能够识别！
[5] 逐步取消数据类型的模糊化处理和变量的不声明即可使用的这种处理方式（ 即使用数据类型的强制性约定，和变量的强制性声明）
这一点也是一个标准化走向的问题，我就不用说得太多了，大家自己体会吧！
上面所提到的这些该废除的项目，我的意思不是在现阶段来说已经没有什么用处而可能直接废掉，因为从低版本到高版本总有一个过渡的过程，各种新功能还有一个适应的过程，这些观点旨在希望大家从标准化的概念去理解一个编程语言。
以上只是个人观点，希望大家批评指正！
也希望大家积极发言，提出自己的看法！这样才能共同进步。
不才YASUR 2003年4月24 敬上！
之所以说要废弃，只是因为觉得这些功能似乎已经没有什么实用功能了或存在的意义了，完全可以用更好的方法来实现它！！纯属个人观点，扔出来供大家讨论，共同进步，希望大家都发表一些自己的意见！
[1] 首当其冲应该扔掉的是[视图]，包括[本地试图][远程试图]
之所以要说首当其冲，就是因为试图本来就是一段SQL代码+DBSETPROP()的集合体
现在VFP8中有了CURSORADAPTER,功能非常强大，可以使用目前比较流行的几种数据连接（访问）方式，使用XML更是可以将VFP的身价提高一个档次，可以和.NET平台来交换数据，ADO的访问方式也是让人激动不已，最主要CURSORADAPTER是一个基本类，有自己的事件，方法，属性。可以完全脱离DBC来使用。整合了[本地试图][远程试图]，数据访问的方式从来没有这么酷！
就目前来说，CA的BUILDER是有点烂，可是试图编辑器其实就是个BUILDER,用这个更显别扭，虽然VFP8对VIEW BUILDER作了不少改动，比如查看SQL时可以看到DB属性，不过似乎已经没什么意义了！
[2] 接下来受害的就应该是[CONNECTION（连接）]了，因为在我看来CONNECTION就是为REMOTE VIEW而存在的，既然REMOTE VIEW都没必要了，那它也就跟着受害了！呵呵！这一点就不多说了！
[3] 关于这个该废弃的功能模块也许说出来大家会有点反感，不过也是正常的，它就是：自有表。
从出现数据库的时候我就发现自有表似乎已经没有存在的意义了！虽然说有时候做单表单或临时使用表的时候他提供了极大的方便，可以随时使用，自由存储。但自由表就如他的名字一样，比较自由，功能属性方面也没有数据库表那么强大，如果按一种标准化的概念来理解或评定自由表的话，那么它应该不伦不类！所以提出此点旨在希望大家应该逐步努力的去使用比较标准化的东西，即使现在又是自由表的使用和存储方面确实比数据库表方便的多，但在我看来自由表的寿命已经不长了。
[4] 在以前的FOXBASE和现在的FOXPRO语法中都有一个约定，就是可以使用最少4个省略的命令或函数来代替完整的。那在我看来这个功能现在已经开始出现问题了！因为出现这个功能的初衷是为大家写代码提供极大的方便，可以少些不少，确实博得了大众欢欣。可是随着VFP版本的不断更新，出现了越来越多的命令、函数、以及事件、方法、属性等，而原有的已经不太实用的命令函数又要照顾低版本的FOX,不可能随便废掉。那随便想一想就会知道4个字符已不足以来区分如此多的命令、函数。。。。（注：也许这也是VFP使用SYS()系列来扩充函数数量的原因吧！哈哈!），而且再看看哪种语言中有这个约定，这对于标准化也是极为不利的事情，所以我在想，VFP的[智能感应]功能推出的一方面的原因是这个功能是个迫切需要，因为其他语言基本都有了，而且使用确实方便，可以在一定程序上减少出错的几率！那另一方面就是VFP的开发组开始规范代码格式了，你写四个简略的代码，我尽量给你补全，哈哈！
所以给大家提个建议，写代码的时候尽量将代码写全，以免以后升级的时候新的VFP版本不能够识别！
[5] 逐步取消数据类型的模糊化处理和变量的不声明即可使用的这种处理方式（ 即使用数据类型的强制性约定，和变量的强制性声明）
这一点也是一个标准化走向的问题，我就不用说得太多了，大家自己体会吧！
上面所提到的这些该废除的项目，我的意思不是在现阶段来说已经没有什么用处而可能直接废掉，因为从低版本到高版本总有一个过渡的过程，各种新功能还有一个适应的过程，这些观点旨在希望大家从标准化的概念去理解一个编程语言。
以上只是个人观点，希望大家批评指正！
也希望大家积极发言，提出自己的看法！这样才能共同进步。
不才YASUR 2003年4月24 敬上！
...全文
请发表友善的回复…
发表回复
cxmcxm 2003-04-30
- 打赏
- 举报
cursoradpter不能离开了数据环境,而数据库却可在任何地方使用.
流星尔 2003-04-27
- 打赏
- 举报
视图和自由表一段时间内还不能被取消。照顾到用户的习惯以及升级的难度。转变力度应该不能一步到位。而且自由表和视图我觉得又确实有比较方便的地方
yasur 2003-04-27
- 打赏
- 举报
呵呵！回楼上：
[1] 可以使用cursoradpter
[2] 如果多表单使用同一视图，那这种情况下你可以建立一个cursoradpter类来解决！一样方便！而且对资料进行了封装！脱离了数据库！试想，你建立的视图参数在运行时可以透过dbc文件看到。
[3] vfp的安全性有待进一步提高！
[1] 可以使用cursoradpter
[2] 如果多表单使用同一视图，那这种情况下你可以建立一个cursoradpter类来解决！一样方便！而且对资料进行了封装！脱离了数据库！试想，你建立的视图参数在运行时可以透过dbc文件看到。
[3] vfp的安全性有待进一步提高！
cxmcxm 2003-04-27
- 打赏
- 举报
1.视图用起来很方便,很多条件查询,我都用视图实现,因为视图建好后,在哪个表单想使用,只要拖进数据环境,要用到查询,只要将参数设好,再requery()即可得结果,比用sqlexec方便得多.
2.假如多个表单都用到同一视图,如果不用视图用curspradpter,建起来会麻烦很多.
3.对vfp数据环境,在7.0后use命令增加connectstring参数,数据环境的cursor没有相应属性与其对应,我觉得,如果有相应属性与其对应,可提高vfp的安全性.因连接的字符串数据库中,誰都可看到而现访问server端数据库.
2.假如多个表单都用到同一视图,如果不用视图用curspradpter,建起来会麻烦很多.
3.对vfp数据环境,在7.0后use命令增加connectstring参数,数据环境的cursor没有相应属性与其对应,我觉得,如果有相应属性与其对应,可提高vfp的安全性.因连接的字符串数据库中,誰都可看到而现访问server端数据库.
yasur 2003-04-24
- 打赏
- 举报
升级是麻烦了点！不过从视图到CA的转换是非常容易的事情！自己写一段代码就可以搞定！
我的意思当然不是现在就废掉，是在版本的不断升级和稳定的基础上逐渐将其淡化活干脆处理掉！
如果顾虑到版本升级的问题的话！其实这是个一直以来都难解决的问题！
就像FOXPRO中目前包含的许多函数、命令都是FOXBASE专用的，而现在已经根本用不到了！是想一想，如果VFP不断升级，而这些旧的功能依旧一直带着！系统的稳定性可想而知！
至于自由表的问题！我上面也提到了，他有许多好处，简洁，使用自由！可是从总体化的角度来考虑！他应该是个过渡角色！
我的意思当然不是现在就废掉，是在版本的不断升级和稳定的基础上逐渐将其淡化活干脆处理掉！
如果顾虑到版本升级的问题的话！其实这是个一直以来都难解决的问题！
就像FOXPRO中目前包含的许多函数、命令都是FOXBASE专用的，而现在已经根本用不到了！是想一想，如果VFP不断升级，而这些旧的功能依旧一直带着！系统的稳定性可想而知！
至于自由表的问题！我上面也提到了，他有许多好处，简洁，使用自由！可是从总体化的角度来考虑！他应该是个过渡角色！
zhongyj 2003-04-24
- 打赏
- 举报
废弃視圖和連接
太早了點,
1.目前有大量的C/S應用程序使用到了視圖,如果取消視圖應用程序升級的工作量將會是巨大的,一般用戶不會接受.
2.不管怎麼說VFP8是新東西,它的一些功能不可能在很少時間就使用的非常熟悉,升級的難度也會加大.
废弃自由表:
自由表能解決很多實際問題,很方便.
舉個例子:我以前寫過一個報表按鈕類,有各種功能其中一個功能,是將報表所需的數據保存到一個自由表里,這個功能也同樣可以將自由表中的數據匯入到當前報表數據中,不用產生報表數據,直接打印報表,用戶可以將這個產生的自由表email到任何地方,只要有程序文件就可以打印出報表,雖然用數據庫中的表也可以實現,但實現的方法就會變麻煩了.
其它兩點支持
太早了點,
1.目前有大量的C/S應用程序使用到了視圖,如果取消視圖應用程序升級的工作量將會是巨大的,一般用戶不會接受.
2.不管怎麼說VFP8是新東西,它的一些功能不可能在很少時間就使用的非常熟悉,升級的難度也會加大.
废弃自由表:
自由表能解決很多實際問題,很方便.
舉個例子:我以前寫過一個報表按鈕類,有各種功能其中一個功能,是將報表所需的數據保存到一個自由表里,這個功能也同樣可以將自由表中的數據匯入到當前報表數據中,不用產生報表數據,直接打印報表,用戶可以將這個產生的自由表email到任何地方,只要有程序文件就可以打印出報表,雖然用數據庫中的表也可以實現,但實現的方法就會變麻煩了.
其它兩點支持
