vfp高级有关问题
vfp高级问题
用vfp如何制作COM组件？
------解决方案--------------------
define class xx as session OLEPUB
……
然后编译成多线程或单线程DLL即可。
------解决方案--------------------
<VFP编写DLL>
http://blog.csdn.net/apple_8180/article/details/2318555
想开机运行，需要写个程序调用这个DLL。
你要实现什么功能？
------解决方案--------------------
网上搜索的：
大家也许明白了COM实际上解决了应用程序的整合，您可以在客户不知不觉中，使用了好多其他语言的优势，很简单的完成任务。别人看到的还是程序的主界面，不会有其他窗口跳出来影响画面；调用exe文件时，很难控制它的运行进程和运行结果，就像“断了线的风筝”！现在有了COM组件，您可以完全摆脱这个局面了，调用它的方法、设定它的属性、响应它的事件，成了自身的一部分。COM扩展了VFP的应用范围，现在我们可以简单的把VFP程序分布到各种场合（商业、工业、互联网...），与其它系统无缝的集成在一起!
COM技术带来新的思路，不同语言的程序员可以在一起工作，不同模块可以被做成独立的组件，这样更容易维护，升级软件时就只要替换部分的组件。这里我想到了国内现在比较流行的软件开发业务——为财务软件做接口，很多客户希望自己的MIS系统与财务软件连在一起，数据共享。现在的做法是“硬连接数据库，直接操作数据”，这样很不好——财务数据得不到保全、系统的二次开发变得只有财务软件公司能做，因为数据库的结构、业务的记录只有他 们清楚。如果财务软件包是一套组件，财务软件只是这一组件的实现，那么这种二次开发就变得安全、容易了。
COM也有缺陷。我认为最主要的是版本问题，就是人们常说的“Dll Hell”，常用ActiveX控件的人对这种问题一定是有体验的，COM也一样。比如，控制Word的代码就要很小心Word的版本，甚至是语言种类， 不然的话保不准程序就会出错……COM的另外一个缺点就是COM组件的运行效率，主要是在被建立实体对象的时候显得有点慢，这个问题我们可以通过“早期绑定”、连接池来解决，即使不能很好的改善，我认为这个问题也是无关痛痒的，毕竟COM的好处太大了……
VFP与三层构架
按正常的逻辑，写COM必定要写三层应用，实际上要把VFP配置在三层结构的中间层编写COM是唯一的方法，但是各位务必明白COM组件并非只能用于三层构架，上文我提到的各种应用基本上不属于三层应用的范畴。
三层构架把整个软件系统分为用户界面、商业逻辑、数据存储这三个层次。三层构架的特色在于用户界面不直接与数据库打交道，所有客户请求都必须通过中间层组件更新到数据库。
这样有两大好处：头一个好处就是商业逻辑代码的统一维护，再一条好处就是解决大量用户同时访问数据库的问题。
把所有的商业逻辑都写在中间层里，这样当商业逻辑变化时就可以之更新中间层的程序，对客户界面不产生影响。这是一种理想，笔者认为用户界面设计与数 据关联性很大，大家在设计单层结构、双层结构时应该是有这个体会的：怎样的数据源就必须有怎样的界面与之相配；三层应用中用户界面与中间层打交道，同样界 面就必须跟着中间层走，如果中间层的商业逻辑明显变化用户界面是不可能不变的。于是代码的统一维护并没有带来各类用户界面相对稳定，这样代码的统一维护只 是一个诱人的果子，吃了也不见得甜。
三层结构最诱人的地方在于解决大量用户同时访问数据库的问题。我们知道当前最好的Oracle 数据库可同时支持500个连接，不幸的是实践证明当活动连接达到这个数目时，数据库服务器往往是承担不起的。500个请求同时访问数据库，这在Web领 域、在大型企业都是很细松平常的事情。解决之道，无非是减轻某一时刻数据库服务器的压力，在进一步说就是分配工作到不同的数据库服务器、让客户请求排队等 候，别一窝蜂的挤到数据库那里，这就是动态负载平衡和排队机制，那么谁来完成这项工作呢？用户界面是理所当然不可能的，数据库已经很吃力了当然也不能再麻 烦它了，只有中间层可以胜任。现在的MTS、COM+就是这样的工具，VFP的组件支持MTS、COM+，于是将我们的编写的组件放在MTS、COM+中运行，我们就享用到了MTS、COM+的特性，一切不需要我们操心。
微软为什么强调VFP在Web服务器的应用
Web服务组件是最典型的中间层应用，它的特色是用户界面通过组件与服务器的交互的次数较少，例如在客户端我们查询一批数据，中间层得到请求检索数据库返回光标并即时产生HTML文档返回给客户，完成后就可以释放组件。同样这个行为，在单层、两层应用中可能就很复杂，可能我们需要对查询结果进行维护，再更新到服务器，再刷新光标……Web应用下的数据库强调是的查询——根据复杂的逻辑产生查询结果，而对数据的维护不太看中。（这就是为什么Web专用数据库MySQL不支持事务处理、存储过程的原因吧……）
对于这种应用，作为专业的数据库开发程序，VFP可以说是手到擒来、不在话下的，开发起来也没有什么难度，所以微软强调Visual FoxPro在Web上的应用是很有道理的。
还有一种三层应用就是企业级应用，它的特点就是利用三层结构实现两层或单层结构下的应用程序，同时利用三层构架解决商业代码的维护和大量数据访问的 问题。可以想象这种企业级的应用对开发组件的要求是很高，在国外往往有专业的公司开发这类组件，用户只需根据实际应用做二次开发。据我所知，Delphi 的第三方产品中就有这样的东西，价格异常昂贵，比Delphi还贵很多……
VFP同样也能开发这样的组件，只是难度问题……处于商业角度，微软不提VFP在这方面的应用是有道理的，毕竟与其它工具相比我们没有什么优势……
用vfp如何制作COM组件？
------解决方案--------------------
define class xx as session OLEPUB
……
然后编译成多线程或单线程DLL即可。
------解决方案--------------------
<VFP编写DLL>
http://blog.csdn.net/apple_8180/article/details/2318555
想开机运行，需要写个程序调用这个DLL。
你要实现什么功能？
------解决方案--------------------
网上搜索的：
大家也许明白了COM实际上解决了应用程序的整合，您可以在客户不知不觉中，使用了好多其他语言的优势，很简单的完成任务。别人看到的还是程序的主界面，不会有其他窗口跳出来影响画面；调用exe文件时，很难控制它的运行进程和运行结果，就像“断了线的风筝”！现在有了COM组件，您可以完全摆脱这个局面了，调用它的方法、设定它的属性、响应它的事件，成了自身的一部分。COM扩展了VFP的应用范围，现在我们可以简单的把VFP程序分布到各种场合（商业、工业、互联网...），与其它系统无缝的集成在一起!
COM技术带来新的思路，不同语言的程序员可以在一起工作，不同模块可以被做成独立的组件，这样更容易维护，升级软件时就只要替换部分的组件。这里我想到了国内现在比较流行的软件开发业务——为财务软件做接口，很多客户希望自己的MIS系统与财务软件连在一起，数据共享。现在的做法是“硬连接数据库，直接操作数据”，这样很不好——财务数据得不到保全、系统的二次开发变得只有财务软件公司能做，因为数据库的结构、业务的记录只有他 们清楚。如果财务软件包是一套组件，财务软件只是这一组件的实现，那么这种二次开发就变得安全、容易了。
COM也有缺陷。我认为最主要的是版本问题，就是人们常说的“Dll Hell”，常用ActiveX控件的人对这种问题一定是有体验的，COM也一样。比如，控制Word的代码就要很小心Word的版本，甚至是语言种类， 不然的话保不准程序就会出错……COM的另外一个缺点就是COM组件的运行效率，主要是在被建立实体对象的时候显得有点慢，这个问题我们可以通过“早期绑定”、连接池来解决，即使不能很好的改善，我认为这个问题也是无关痛痒的，毕竟COM的好处太大了……
VFP与三层构架
按正常的逻辑，写COM必定要写三层应用，实际上要把VFP配置在三层结构的中间层编写COM是唯一的方法，但是各位务必明白COM组件并非只能用于三层构架，上文我提到的各种应用基本上不属于三层应用的范畴。
三层构架把整个软件系统分为用户界面、商业逻辑、数据存储这三个层次。三层构架的特色在于用户界面不直接与数据库打交道，所有客户请求都必须通过中间层组件更新到数据库。
这样有两大好处：头一个好处就是商业逻辑代码的统一维护，再一条好处就是解决大量用户同时访问数据库的问题。
把所有的商业逻辑都写在中间层里，这样当商业逻辑变化时就可以之更新中间层的程序，对客户界面不产生影响。这是一种理想，笔者认为用户界面设计与数 据关联性很大，大家在设计单层结构、双层结构时应该是有这个体会的：怎样的数据源就必须有怎样的界面与之相配；三层应用中用户界面与中间层打交道，同样界 面就必须跟着中间层走，如果中间层的商业逻辑明显变化用户界面是不可能不变的。于是代码的统一维护并没有带来各类用户界面相对稳定，这样代码的统一维护只 是一个诱人的果子，吃了也不见得甜。
三层结构最诱人的地方在于解决大量用户同时访问数据库的问题。我们知道当前最好的Oracle 数据库可同时支持500个连接，不幸的是实践证明当活动连接达到这个数目时，数据库服务器往往是承担不起的。500个请求同时访问数据库，这在Web领 域、在大型企业都是很细松平常的事情。解决之道，无非是减轻某一时刻数据库服务器的压力，在进一步说就是分配工作到不同的数据库服务器、让客户请求排队等 候，别一窝蜂的挤到数据库那里，这就是动态负载平衡和排队机制，那么谁来完成这项工作呢？用户界面是理所当然不可能的，数据库已经很吃力了当然也不能再麻 烦它了，只有中间层可以胜任。现在的MTS、COM+就是这样的工具，VFP的组件支持MTS、COM+，于是将我们的编写的组件放在MTS、COM+中运行，我们就享用到了MTS、COM+的特性，一切不需要我们操心。
微软为什么强调VFP在Web服务器的应用
Web服务组件是最典型的中间层应用，它的特色是用户界面通过组件与服务器的交互的次数较少，例如在客户端我们查询一批数据，中间层得到请求检索数据库返回光标并即时产生HTML文档返回给客户，完成后就可以释放组件。同样这个行为，在单层、两层应用中可能就很复杂，可能我们需要对查询结果进行维护，再更新到服务器，再刷新光标……Web应用下的数据库强调是的查询——根据复杂的逻辑产生查询结果，而对数据的维护不太看中。（这就是为什么Web专用数据库MySQL不支持事务处理、存储过程的原因吧……）
对于这种应用，作为专业的数据库开发程序，VFP可以说是手到擒来、不在话下的，开发起来也没有什么难度，所以微软强调Visual FoxPro在Web上的应用是很有道理的。
还有一种三层应用就是企业级应用，它的特点就是利用三层结构实现两层或单层结构下的应用程序，同时利用三层构架解决商业代码的维护和大量数据访问的 问题。可以想象这种企业级的应用对开发组件的要求是很高，在国外往往有专业的公司开发这类组件，用户只需根据实际应用做二次开发。据我所知，Delphi 的第三方产品中就有这样的东西，价格异常昂贵，比Delphi还贵很多……
VFP同样也能开发这样的组件，只是难度问题……处于商业角度，微软不提VFP在这方面的应用是有道理的，毕竟与其它工具相比我们没有什么优势……