发布真正企业级开发平台 (100分)

这个东东我用过了。感觉不错。优点powerz和楼主都说了。我想对于初学者来说，不想用这个东东，也许是你想学更多的东东（最终为了什么呢。赚钱还是。。这样多快呀。哈哈）。所以不想用它。对于有一点点知识的人（比如说我）就比较适合用这个东东了。太方便了。问候大家了。[]

（继续）......，有的人就发言了，“真正的高手肯定自己全部搞定，而不会用一个不熟悉的东西”，但是据我了解，撇开那些整天高谈阔论的伪高手不谈，一个真正的高手对于别人的东西，比如网上流传的各种报表控件什么的啦，他们不会采取排斥的态度，他们真正做到的是，怎么样让那些别人的东西更好地融入到自己的应用系统中去，实际满足用户的需求；另外，当一个高手自己把想要的功能用插件的方式实现在本系统(de)的一个菜单或者按钮或者让本系统(de)的其它插件开发者调用，那么所有本系统上运行的数据库表都立刻可以使用这个功能，在这个时候，这个系统就不能不说是他的努力后成果的一部分了，也可以按那些惯于狭隘思维的人说的，“这不是别人的东西，这是我做的东西了”。其实程序员哪一天不会接触到新的东西，所以当一个程序员不愿接触新生事物的时候，他离成功就越来越远了，不是吗？......

说说我的看法吧
这个软件的本意是想把界面设计和数据库设计分开
是一种二层设计的方法，不过考虑到界面的多样性和实际功能的多种变化
简单的分离是不可取的
从某种意义上说，三层的结构是比较合理的
界面设计、业务逻辑和数据库
像本软件这样企图将界面和业务逻辑统一封装、感觉并不合理
尤其是采用BDE,感觉过于古老，
还有就是无法卸载（设计者很有水平）

（继续）......，文章中间穿插回答一些问题，这才是交流嘛。又有人问本系统是否收费，其实正如在前面都已经讨论过的，只有面对最终用户才会有收费的问题，对于插件开发者和业务逻辑开发者来说，是不存在收费问题的，不但不存在收费的问题，我们还努力使本系统成为他们自己的东西，让本系统成为大家的努力成果，你可以通过插件开发控制本系统的各个细节（比如你写的插件本身可能就是你原来的一个已经成型的信息系统稍微改一改，只是通过本系统菜单调用或者调用本系统插件，不知道这样说是不是说清楚了），所以只要你参与进来了，这就成为你自己的东西的一部分，当最终用户购买的时候，你的插件开发工作（当然，如果真的只是自己一个已经成型的特定应用系统改一改的模块，可能用得到你的插件的用户就很有限了）就会得到应得的报酬，越多人使用，你就越受益。另外，目前所有想使用本系统的最终用户，因为他自己的业务流程肯定需要自己在本系统上定义出来，所以我们会按业务逻辑开发者来看待，所以也没有收费的问题，当他的特定行业业务逻辑成型并投入使用成功之后，使用者还可以通过与我们合作销售他的特定行业业务逻辑来得到收益。......

实话说吧，现在我们做的这个东西，你这个平台一点忙都帮不上
因为和普通的业务根本不一样

（继续）......，再回答一个提出的问题，有人说到“系统想把界面设计和数据库设计分开，考虑到界面的多样性和实际功能的多种变化简单的分离是不可取的”，面对这个问题，很抱歉我们没有解释清楚或者还没有谈到，根本原因还是提问者不了解本系统所导致的，在我们提供足够多的技术细节之后，我相信这个问题会迎刃而解的。确实界面的多样性是无法避免的，但是如果注意到本系统的各种界面全部都是一个个插件，甚至包括主窗口在内，所以，当遇到当前界面插件还无法满足特定用户需求的时候，做为一个积极的程序员，他要做的就是总结这种需求的规律性界面及功能需求，并用开发工具设计出相应的插件，当他做到这一点的时候，他就是一个真正的插件开发者了，而本系统的功能又向前跨越了一大步，所实现的插件功能也不是由一家特定用户来独享了，他开发的插件也将因为类似的用户的广泛采用而得到巨大的回报，当大家一起来努力的时候，就可以让本系统适应各种不同用户的多样性需求了。......

（继续）......，再回答一个问题，有人说到“现在我们做的这个东西，你这个平台一点忙都帮不上，因为和普通的业务根本不一样”，我想，不光是提出问题的这位网友是这样，我相信每个项目开发组要做的东西都一定是世界上独一无二的东西，就象你的这个系统一样，跟普通的业务根本不一样，但是，我想，首先你肯定是用某种开发工具吧，而这种开发工具应该包含在我前面所论述的那些可以开发插件的开发环境中吧，那么你一定就从技术上不存在与本系统集成的问题了，也就是本系统可以调用你的东西，而你的东西也可以调用本系统的任何插件；其次，就是怎么集成的问题，你的业务和普通的根本不一样，但是总还是一些数据库表吧，在这些库表上的业务逻辑如果通过研究归纳之后，一定可以发现，有相当一部分内容其实是可以用通用方式实现的，而那些确实和普通业务不一样的业务逻辑，你只用在你的开发工具上实现那些有限的特定业务功能为几个插件，你不就可以得到一个可以立刻享用本系统其它现成功能并可以不断扩充的应用系统了？当用户提出更多需求或者需求发生变化的时候（往往是不可能避免的，居然还有些资深程序员天真地认为完善的前期需求调查可以规避这种现象，我想，至少在中国是不可能的），你是否可以只用简单地改变业务逻辑定义或者改变代码量很少的插件来适应用户的需求呢？甚至当用户提出一种新的报表格式或者授权方案的时候，你可能发现现有系统已经具有了相关的功能，你要做的只是教他们怎么操作而已。另外，当你参与到插件开发者行列中的时候，你就会发现，你根本不会继续保留以前那种不断为特别的用户需求去定制特定程序代码的恶习了（不可否认，这往往是一个软件系统生命周期走向终结的致命因素），你会不自觉地甚至是千方百计地去找到这个用户特定需求的规律性内容并主动用可以重用的功能插件来实现，而这个新设计的插件因为有丰富的可扩充语法（直接调用本系统语法插件即可）或者配置对话框而可以适应一批已经出现或者还未出现但可以预见会出现的用户需求，那么你这个项目就离成功不远了，而当你发现这些插件在其它用户那里也可以适用的时候，你所获得的成就感和回报是你以前不可能想象到的。对于一些思维比较偏执（并非贬义）的同行们，我可以这样来解释一下，首先读过了上面的讨论并给予充分了解之后，应该可以得到这个结论，“这样的系统是确实是可以存在的”，那么，我要说的就是，我们的工作就是向这个目标在前进。......

作者的思路可取
实际未必可行
想向最终用户收费
最后还是转嫁到开发人员或公司的身上
难！！！

（继续）......，又有人提到，“最后还是转嫁到开发人员或公司的身上”，其实这个问题很值得讨论。首先要说的是，目前本系统的使用是不收取费用的。那么回到那个问题，我们可能会向开发人员或者开发公司收费吗？我们是这样考虑的，开发方相对于最终用户群来说，是属于极少数的概念的，那么向相对来说极少的开发公司或者开发人员来收费，就算收到多高的一个数额，我们都不可能得到满足自身发展的资金和空间的（borland就是一个典型的例子，出了好的开发工具，却必须艰难度过财务危机），而且本系统产生效益的最终地点是在最终用户的实际日常使用当中，当他们的需求不可避免地发生变化和更新的时候，快速适应需求变化的特点为他们产生了高额的回报，所以从最终用户收费才能体现这个价值链的正确走向，做为开发公司和开发人员来说，当他们一旦降低了开发成本的时候，市场竞争环境之下一定会因价格减低而尽量让利于最终用户（别忘了我是个程序员），所以，做为开发方来说，只会有开发和维护成本的下降而不会有被收取额外费用的负担，所以只会是三方收益，实现三赢。......

（继续）......，继续我们的讨论，这次站高点看远点，讨论一下快速原型法这个软件工程的话题，当然，作者保证不会让你读得太难受。这几年，有人居然这样说，“中国的程序员只有技巧，没有软件工程”，我听了大为惊讶，难道真的是这样吗？其实上网搜一下软件工程关键字，各个网站非常热闹，完全不象“没有软件工程”的样子，那么真正的我们的开发者在实际项目中是怎么应用软件工程理论的呢？失败的无外乎两种情况，第一种情况是，作为比例相当大的那些中小型软件项目，一个开发组可能只有几个人或者十几个人，他们各个身兼多职，一专多能，可惜项目预算和期限太紧，见了客户几面就回来开始写程序，写了又见客户，见了又变需求，变了又改程序，改了再见客户，见了再变需求……，仿佛就是个死循环，没办法竟然只有让客户在需求报告上签字，想通过堵住用户的嘴来制止需求的变化，把风险完全推到客户身上，最后项目拖期或者亏本也是见怪不怪了；另外一种情况相反，一些大型或者中型项目里，资金充足，领队的都是有学术头衔，或者至少学历较高的什么人，项目初期专门集中大家搞什么建模，用什么rational rose什么的建模工具，画什么ER图，流程图，这图那图，然后打印出一厚本材料和客户面对面逐一讨论，占用大量用户的正常工作时间不说，还把客户搞得七荤八素，晕头转向，最后竟然还抱怨客户素质太低，无法沟通等等；以上这些现象常常发生，那么，怎么样才能避免这种现象呢？我们认为，目前为止，快速原型法依然是一种被最广泛地采用并最平滑有效的软件工程方法之一，但是实施快速原型法必须要有合适的手段才能发挥其积极的作用。首先当然不能纸上谈兵，客户不是计算机专业人员，看不懂这图那图，听不懂各种计算机术语，只有实际使用一个可以使用的软件，才能提出具体建议和反馈，其次，如果立刻编写代码来定制客户的业务逻辑程序，必然走向前面所述的那种死循环，因为很多程序员都明白，“客户动动嘴，我们跑断腿”，一句话可能整个系统结构都要大改，那么有没有可以经得起以上考验的快速原型法思路呢？我们认为，在需求获取之后，先花两天时间使用本系统为客户定制一套可以立即使用的业务系统，通过用户使用后的沟通和快速交互修改业务逻辑定义，可以在一到两周内得到一个基本稳定的业务系统，然后针对有特别定制要求的少数模块（比如收银模块等所谓独一无二需求的模块，在一套系统中这样必须定制的模块只占整个系统代码量的很少一部分）按已经确认的表字段结构编制定制的程序代码插件，最终以最小的代价实现双赢的目标。需要补充一点的是，在我们面对一些客户的时候，在大部分需求通过本系统定义业务逻辑来满足用户需求并得到用户接受之后，用户仍有几个很简单很容易用代码实现的定制界面，我们仍然会极力劝用户使用通用界面而不是花一两个小时用代码来定制界面，这已经成为一种习惯，而且往往用户都会接受我们的观点，最终例外的只有一两个类似刚才所提到的收银界面等需要全键盘操作的界面，这些不用客户提我们都会定制的，而且花不了多少分钟。还要补充一点，在大量试用了本系统定制业务逻辑产生的应用系统之后，用户在提出需求变更的时候，往往都是按照现有通用界面的模式来提出的需求，而实现需求变更的过程往往只是改一改定义好的部分业务逻辑即可，开发方和客户之间在本系统之上建立了一种沟通的共同语言和模式，开发成本获得了根本性的控制，经过我们测算，即使在试运行两个星期之后只保留使用本系统快速原型法已经定型的数据库表字段结构，并完全不采用本系统，重新用开发工具编制定制代码系统，总开发时间仍旧可以减低到传统方式的50%以下。......

报错误
在默认的数据库连接创建表时出错。(deDbInfo)
用不了

to mstar:请与我联系：16217849

牛人， 本人现在也进行系统框架的尝试，一般来说，主要有两种方式：一、MVC方式（模式/视图/控制器），优点降低系统维护的复杂度，但应付不了多视图多文档的要求；二、document/view，优点：解决了多视图多文档的难题，主要是VC++的MFC采用，但增加了系统的复杂性和维护的困难。两者都可以实现了界面和业务逻辑的分离。
两种方式都可以进行常用模块的预设置（比如：用户权限、日志等），建立不同的生产线（工厂）进行装配各种配件。
不知道楼主是采用哪种方式？

　　你用的是wise installtion做的安装程序，在安装结束之前如果选安装完成后直接运行程序就会报错，提示说找不到？？.exe文件。
　　请改一下脚本，在“退出”事件中把　　？？.exe　　改成你的实际文件名就可以了，这个BUG估计是汉化时产生的错误，试试吧！　：）

to keyb：谢谢你的指导，已经改正。
的确我是第一次用这个打包，由于时间只是大概看了一下，因为不是那里的高手，所以打的不尽人意，请各位谅解。
包括还有一个问题解决不了：打DBE的时候，当安装类型为部分BDE32安装时，不能自动创建我的别名，请各位指教。
上面ycxy说采用BDE,感觉过于古老，其实这个问题大富翁也有大把的人争论过这个问题，还是有很多人连ORACLE数据库时愿意用BDE，所以我们保留了它，特别是用老版本的oracle,我也觉得比较稳定，当然我们是同时支持ADO和BDE，支持二层结构和三层结构的框架。
谢谢各位参与讨论。

感觉还没到发布这一步，应该还是内部测试的 α 版，还有很多路要走！
其实这就是前段时间炒作的比较厉害的平台了，有很久了，也没见出什么象样的，科思的算一个比较可以的，有时间的话，看看！
建议：
1、将项目管理集成进来；
2、系统太过发散，收敛点；
3、对数据的管理缺乏自动化；
4、对业务的管理应该向导化；
5、报表应该是业务单据的附属；
就讲这么多了，希望早日看到你的完整的系统！

关于别名创建的问题，我建议你应该是程序中直接动态创建别名。这样做远比由安装程序创建要可靠。同时，你还应该在启动程序之前检测BDE或ADO是否已经安装，已经别名是否已经被创建。这样的代码在网上很容易获得。

首页打不开[!]

粗略看了一下，离实用还很远，不知楼主有没有到过2ccc.com去过，形式和该论坛上的什么框架的差不多，就象上楼们说的，初学者不懂用，高手不屑于用。
客户的需求永远不是不同的，永远都在变，想用一个平台来一网打尽，是不可能的，如果能做出这样的平台，ms公司和boland公司早就做了，还用程序员吗？不过在一定范围内的应用来做还是可以的，不过包括得太多反倒是累赘和不现实。
不当之处请楼主见谅。