产线管理系统，如何做架构？

我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，有时候要打印（传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。

现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。

我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。

请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？

列一下需求：
3层架构
夸平台
能够运行本地程序，做一些交互
方便分布（产线电脑，有些是局域网，只能访问特定的服务器）
方便开发（个人建议能够接近Literate Programming，或者脚本式开发）
实时性好，产线作业员可等不了几秒。

我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。
我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？

评论

47 楼 cyberblue 2009-07-14  

zhanghonglun 写道

halida 写道

我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，有时候要打印（传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。

现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。

我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。

请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？

列一下需求：
3层架构
夸平台
能够运行本地程序，做一些交互
方便分布（产线电脑，有些是局域网，只能访问特定的服务器）
方便开发（个人建议能够接近Literate Programming，或者脚本式开发）
实时性好，产线作业员可等不了几秒。

我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。
我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？

我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点，
条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。
实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。
提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看
客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。
我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。
我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。
别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。

做数据库维护才有意思，工厂不大可能配备DBA，只能几个Developer轮流应付，每天等中午操作工都去食堂吃饭的时候飞奔到厂房，登录、运行脚本、Dump、保存、改名、登出，等都弄完了饭也凉了，後来改成COBOL风格的数据保存方式，数据库维护轻松多了，但是劳动量都转嫁给程序员了，代码量至少涨了30%。

不过劝楼主如果想在那家公司一直做下去的话，自己维护一套通信协议和通信套件还是很有必要的，现在互联网上的常用通信套件都不怎么高效，曾经问过tuxedo的授权价格，当时含了口水差点喷出来。

46 楼 jamiesun 2009-07-13  

python+pyqt+django+salalchemy

其实楼主你所想的方案已经很好了，代替delphi，我想没有什么比python+pyqt更合适了，swing不好，java qt也不好，c++ qt也不好，python+pyqt的生产效率是最高的，你若想先做个原型，他也是首选。运行本地程序，python比java要方便

django+salalchemy 无非是一个server的问题，不一定非用django+salalchemy，你可以有很多选择。server需要足够稳定，足够的并行处理能力，定义好接口，具体实现不一定限于python，java倒是一个不错选择。分布式不是问题

python+pyqt +（server） + oracle

假如你非常想推你的方案，你有两种选择：

1，加班加点的编码吧，把原型搞出来，用事实说话，本人的方案，可行！！！
2，你对做这个原型不够信心，那就写文档吧，google...查询尽可能多的资料，整出至少100页的文档，一定要图文并茂，一定要表现的煞有其事。对java，.net等主流方案做出比较，同时要得出结论：你的方案最佳。也许文档中一半的东西实际可能用不到，你也要写。你要让主管觉得你确实是为这事呕心沥血了，确实是很认真了。 那你就有希望推行你的方案了。

我有个朋友用了200页的文档说服主管让他负责一个省级boss系统的项目开发。而实际项目开发中并非完全按照文档所说。更没有用到texdo如此重量级的东东。

你要办实事，就千万别拿那些商业中间件来忽悠自己了


假如有幸，那么相信你的方案，搞定它。

对待遗留系统这个话题，随便扯扯可以扯几大筐的话出来。其实无非分两派，一派激进，一派保守，很难用对错来说明。作为激进者想要成功，需要足够的实力和魄力。你的观点和意见越激烈，你就要越沉着。无论是激进派还是保守派都需要全面的分析系统，分析可能存在的所有问题。保守派以为“稳定压倒一切”，激进派认为“不破不立”。

顺便说一句，楼主比较激进，很欣赏这一点，我不喜欢保守派，常常恨得咬牙切齿。只是他们常常是一些掌权者，无奈何。

我也是python pyqt的狂热分子，用过swing，swt，java qt ，全放弃了，比较一下，python pyqt爽就一个字。

当不得不借用一些java类库时，我也先假设是不是能直接用python来调用java类库，然后就google到jpype了，爽就一个字。

45 楼 zhanghonglun 2009-07-11  

hatedance 写道

貌似做mes的兄弟们都赶过来了，不如楼主建个mes的圈子？

呵呵，我是业余的，只是支援工厂的MIS 做过一个SFCS 系统。

44 楼 nwangwei 2009-07-11  

http://bbs.palmjob.net/2017/090603071622226-1.htm

对RCP的优缺点说了点描述。

43 楼 hatedance 2009-07-11  

貌似做mes的兄弟们都赶过来了，不如楼主建个mes的圈子？

42 楼 zhanghonglun 2009-07-10  

halida 写道

zhanghonglun 写道

halida 写道

我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，印（<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。

现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。

我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。

请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？

列一下需求：
3层架构
夸平台
能够运行本地程序，做一些交互
方便分布（产线电脑，有些是局域网，只能访问特定的服务器）
方便开发（个人建议能够接近Literate Programming，或者脚本式开发）
实时性好，产线作业员可等不了几秒。

我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。
我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？

我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点，
条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。
实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。
提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看
客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。
我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。
我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。
别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。

楼上说的是。
程序出问题都要在10分钟内搞定的，不然产线就停在那里。

有的时候要出货，集卡已经等在仓库门口，可能司机还在狂按喇叭，这时候如果出货功能卡住了，或者产品还在线上包装，但QA 不能做了，靠，急死你啊。反正换系统，特别是核心系统是有挺大风险的。
经济景气时，或者有紧急订单在处理时，产线是8h×3 运转的，估计当机超过10 分钟，MIS 就要集体记大过，奖金也可能没戏了，还无话可说～

41 楼 eclipse2008 2009-07-10  

<p>如果想做个跨平台的产品可以这样 <br>前端UI eclipse rcp <br>后端业务封装成 web service <br></p>
<p>这个可以参考一下 <a href="http://ca.nstl.gov.cn/appCase/content.asp?contentid=261690">汽车行业MES系统中的现场点客户端应用</a></p>
<p> </p>
<p> </p>

40 楼 halida 2009-07-10  

zhanghonglun 写道

halida 写道

我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，有时候要打印（传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。

现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。

我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。

请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？

列一下需求：
3层架构
夸平台
能够运行本地程序，做一些交互
方便分布（产线电脑，有些是局域网，只能访问特定的服务器）
方便开发（个人建议能够接近Literate Programming，或者脚本式开发）
实时性好，产线作业员可等不了几秒。

我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。
我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？

我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点，
条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。
实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。
提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看
客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。
我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。
我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。
别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。

楼上说的是。
程序出问题都要在10分钟内搞定的，不然产线就停在那里。

39 楼 zhanghonglun 2009-07-09  

halida 写道

我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，有时候要打印（传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。

现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。

我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。

请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？

列一下需求：
3层架构
夸平台
能够运行本地程序，做一些交互
方便分布（产线电脑，有些是局域网，只能访问特定的服务器）
方便开发（个人建议能够接近Literate Programming，或者脚本式开发）
实时性好，产线作业员可等不了几秒。

我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。
我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？

我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点，
条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。
实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。
提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看
客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。
我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。
我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。
别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。

38 楼 shrpcn 2009-07-04  

MES 制造执行系统, Delphi 就完全可以了啊。
还有Linux+WINE ， WINE里面的系统如果是Windows ， 仍然是需要购买许可的。

37 楼 halida 2009-06-30  

chenlixun 写道

至少需要富客户端,交互性、用户体验较好!

你的需求我不知道你是怎么弄出来的？就这样的需求能弄出什么架构出来。
不知道你的架构是不是同我们所说的架构！

客户端推荐用SWING,
要跨平台推荐用JAVA,
方便开发推荐用JAVA,
实时性用JAVA也不会有问题，

方便分布是什么意思？不太明白~

这些都是语言，只要接口定义清楚，用什么语言都可以，
但是系统怎么架构，用什么系统来处理中间层，是个困难的选择。

36 楼 chenlixun 2009-06-30  

至少需要富客户端,交互性、用户体验较好!

你的需求我不知道你是怎么弄出来的？就这样的需求能弄出什么架构出来。
不知道你的架构是不是同我们所说的架构！

客户端推荐用SWING,
要跨平台推荐用JAVA,
方便开发推荐用JAVA,
实时性用JAVA也不会有问题，

方便分布是什么意思？不太明白~

35 楼 墓里活人 2009-06-26  

先交钱，后听课！

34 楼 hatedance 2009-06-26  

halida 写道

hatedance 写道

LZ你真幸运，遇到我这个专家了。
产线管理系统是个土名字，专业叫MES。
我们公司的老系统也是delphi+oracle,不过比你们高级一点，用了delphi的3层架构（即不用在客户端配odbc)。其实这个架构挺好，如果你们愿意买windows的话。
如果想省钱，我看可以用java。但也可以用B/S，flex等。打印的问题可以专门做个小小的打印服务程序来连接打印机，开放web服务接受打印内容。

那么请问delphi的3层架构具体的细节呢？
表示层和业务逻辑层之间是什么协议？
业务逻辑层怎么实现和架构？

delphi3层架构当年可是很流行的，好像是delphi5开始的，本质就是所谓的DCOM。你完全可以去搞几本书来看看细节，我现在觉得就是一种远程调用方式而已。业务逻辑层就是所谓的中间层，跟数据库打交道，为客户端服务。一般中间层独立部署在一个应用服务器上，留个端口侦听。

我自己喜欢用java或者。net做开发，所以业务逻辑用基本用java做。delphi客户端可以通过webservice可以调用后台。

不说了，说不完。你自己google一下，结果一大堆。

33 楼 halida 2009-06-26  

hatedance 写道

LZ你真幸运，遇到我这个专家了。
产线管理系统是个土名字，专业叫MES。
我们公司的老系统也是delphi+oracle,不过比你们高级一点，用了delphi的3层架构（即不用在客户端配odbc)。其实这个架构挺好，如果你们愿意买windows的话。
如果想省钱，我看可以用java。但也可以用B/S，flex等。打印的问题可以专门做个小小的打印服务程序来连接打印机，开放web服务接受打印内容。

那么请问delphi的3层架构具体的细节呢？
表示层和业务逻辑层之间是什么协议？
业务逻辑层怎么实现和架构？

32 楼 hatedance 2009-06-26  

LZ你真幸运，遇到我这个专家了。
产线管理系统是个土名字，专业叫MES。
我们公司的老系统也是delphi+oracle,不过比你们高级一点，用了delphi的3层架构（即不用在客户端配odbc)。其实这个架构挺好，如果你们愿意买windows的话。
如果想省钱，我看可以用java。但也可以用B/S，flex等。打印的问题可以专门做个小小的打印服务程序来连接打印机，开放web服务接受打印内容。

31 楼 lobbychmd 2009-06-26  

python、ruby 相关文章、书籍忽悠的也不少，让你看了一下觉得用起来好爽啊，仿佛久旱逢甘露，他乡遇故知。。。

然后慢慢发现其实实际当中有不少地方还是没做到位的， 执行效率啥的还是偏慢的， bug 还是不少的。。。，想做个报表，嘿，就是没delphi 方便。。。

其实程序设计语言并不是全部，即使语言有不足的地方，围绕着这种语言开发出来的类库、框架、比较烂但是能正常工作的程序、和这种语言对应的很多开发模式、甚至针对语言不足设计出来的hook，都是属于这种语言的财富，

别轻易丢掉你的财富。。。

30 楼 wing5jface 2009-06-26  

楼主的串口通信操作是使用类似EPOSN小票指令操作，还是用厂家只提供DLL API呢？
若属于前一种做跨平台的话用，用java SWT,SWING或python都不成问题的。若属后一种情况就要认真考虑的了。

29 楼 王者之剑 2009-06-25  

我觉得再复杂的系统都可以采用由局部到整体的方式进行改进。

你可以先将某台机器上的某个小程序用跨平台语言重写，这样你一边熟悉语言一边改进。

架构没有办法空谈的吧，首先要熟悉你的业务。

我的建议是使用多进程。
例如扫描，这是一个单独的程序，它的输出就是一个条码，这个输出可以被其他进程获取
这样，只要一个很简单的通讯协议，这个扫描程序用什么语言来写，处理扫描结果的程序用什么语言来写，根本就不重要了。

28 楼 matt.u 2009-06-25  

刚才把楼主的帖子又看了一下，这个Delphi+Oracle的项目，需要Desktop、需要打印、需要串口通信，而且从使用习惯和开发习惯上来说，用.NET来顶替当然是最合适不过的。

不过Delphi也可以快速开发三层架构啊，对于你的老系统来说，我觉得是应该把老技术用好，转向任何一个平台都会带来一定的风险。

Delphi技术其实挺好的，只是败在一些公司策略和市场策略上。