下一个项目是LAN中的B/S，用Delphi7还是JBuilder7？

B/S如果是专业一点得话，还是JBuilder，Delphi做Web都是做秀用的。

Delphi玩不转Web应用开发的，赶紧抱着JBuilder啃吧，一定要向对待你的情人那样，不要放过任何一个细节。

语言不是决定项目好坏的因素那种语言都有经典的成果，呵呵不过如果从目前的潮流来看
还是用JAVA吧，起码工资高一点

用delphi的intraweb 作出来绝对一流

我不懂，不过我相信chechy的答案。不过这么说来用delphi来作webserver不行？那起不是又要遗憾了，呵呵。

Delphi做Web的几大弱点：
1）调试复杂。做开发，不能调试，简直就是shit。
2）缺乏支持诸如Application，Session这样的强大对象（即使象WebSnap有Session，也只能支持一个简单类型，不能支持Class）。
3）缺乏对面向对象的良好支持。j2ee有servlet，.net有Page，Delphi有什么？光有那些控件，能做出什么东西来啊？稍微一变化就晕倒。

j2ee做b/s开发当然好，delphi在这方面还要努力，我们这些人就靠它了

Delphi6/7早就能调试Web程序了。
Delphi有WebBroker和Servlet完全相当。
WebBroker支持多种WebServer。
Delphi还有WebSnap
Delphi还有InternetExpress
Delphi还有ActiveForm，配合以Indy网络访问元件
Delphi还有IntraWeb。
但是要想作出比较花哨的Web界面，最好还要拥有DevExpress的EWF元件包。

对了，Delphi还能开发ASP的Active Server Object，也就是后台ASP开发。
在作Web界面方面，慎用WebSnap和InternetExpress。
Java相比之下差太远了。

1).net调试Web，微软的VS.NET和iis可以无缝整合。JBuilder调试Web，和Tomcat之间是无缝整合的。D6/d7呢？如果不用Delphi自带的东东，要和IIS整合，简直就是shit，动不动就要重启IIS。而用自带的Web调试，性能不够高，发布的时候要重新改写。
请问调试那个方便？
2）Java推出到现在就一个j2ee，.net也就是System.Web下面的类。而Delphi呢？D5是InternetExpress，D6是WebSnap，D7又是InterWeb。花样这么多，证明每一样都不成熟，而且每变化一次，就要人重新学一次，烦不烦？

自动重启IIS应该装一个第三方的OnCompilerHelper,就能够在编译之前自动重启IIS。比Java的Application Server快多了。
真是不比不知道。看看Delphi开发的Web界面吧!
http://www.chinajavaworld.net/non-cgi/usr/56/56_151_7.jpg
上述界面虽简单，实现起来可不太容易。

用Delphi开发ActiveX,嵌入浏览器，通过WebService访问Delphi开发的ISAPI，然后走数据库，在通过Delphi开发的工业设备422总线监听服务来控制下位机硬件。
http://www.chinajavaworld.net/non-cgi/usr/56/56_151_8.jpg

Delphi用好了，能够开发特别复杂的Web应用。只不过其中要穿越几个障碍。
要说Delphi的某些Web功能不尽理想，连我都非常有同感。
但要说Delphi的Web功能一无是处，那可就错了。

Delphi有自带吗？当初在Delphi的新闻组上，不要太多的人问这个问题，我觉得这个应该由Borland提供解决方案，而不是第三方公司。何况重启服务很耗费时间的。看看.net，从启动到调试，速度很快的。
另外，那个界面并不花俏啊，呵呵，何况界面上的事情应该是由html去做，程序员关心的应该是后面的逻辑代码怎么写。而如何写出高质量的代码，我觉得必须借助面向对象的强大功能，Delphi在这一方面恰恰很弱。把大量常用的操作封装起来，程序员只关心他需要的数据逻辑，这样非常省时间，提高效率。
.net和j2ee我都能实现，Delphi上我就搞不定。

我认为WebSnap设计的不好。但我觉得这并不影响Delphi的Web开发能力。因为这方面Delphi的路四通八达。Delphi开发Web的优势主要体现在组件和工具的强大上。

to chechy(简简单单的活)
我给大家看的界面可不是比花哨的。界面的花哨完全是DreamWeaver和PhotoShop、FireWorks的事情。可不是Delphi和Java所为。我让大家看的是界面的模式。可是你光看热闹，没看门道。
你要是做过在数据库中动态存储一个树形结构，在Web中还原成可点击的TreeView，你就知道做这种东西的难度了。
另外，Web表格的层状展开也是一个难点。在Delphi中我把这些封装成已有的对象，能够方便的调用，并针对特定的东西做成了IDE插件工具，专门针对特别棘手的Web界面模式的制作。
你说“而如何写出高质量的代码，我觉得必须借助面向对象的强大功能，Delphi在这一方面恰恰很弱。”你是根据什么知道的Delphi在这一方面恰恰很弱呢?你了解Delphi到什么程度呢?你考察过Delphi在面向对象方面的各种体现吗?
要知道，Delphi的面向对象思想直接催生的C#啊！到现在，VS.net有很多东西还难以和Delphi相比呢!

1）你说的东西我恰恰做过，呵呵，我实现的方法非常简单。
2）Web的层次展开如果全部取数据不仅要求代码难度，而且浪费效率。如果局部取数据就变得非常Easy，而且效率也很高。
3）我领悟面向对象是通过Delphi的，我读得最多得书也是Delphi。Delphi 2/4/5/6 Developer's Guild。我对VCL的架构很熟悉，应该是精通Delphi的控件设计、MIDAS、Open Tools API。
4）C#是Delphi和Java的杂种，我不否认这一点。但是C#比Delphi好很多。
5）Delphi在Web方面确实很弱，没有成熟的东西。对XML的支持力度不够，还有RTTI的特性远远不如Java和.net，这使得plug-in技术很难得到应用。

不过看了你说的这些，我也不得不承认我确实忽略了一些因素。在Delphi中基础构架有待巩固。那个设计WebSnap的人似乎还没有我们这些人水平高，迫使很多东西不得不自己从底层实现。如果以现成的Delphi的东西为基础进行Web程序的开发，那Delphi确实不强。除了WebBroker这个老经典以外，无论是WebSnap,还是InternetExpress，都很差劲(以非常严厉的眼光衡量)。
但是，要是深入一步进行开发，也就是说抛弃Delphi现有提供的上层Web功能，只用其中的基础部分，自己构造很多上层功能，那还说的过去。我自行开发IDE插件辅助Web开发，发现这样一来，Delphi的开发能力倒十分凶悍。所以，开发Web应用我一般都将WebBroker,少许的WebSnap和占主要地位的EWF元件集混合起来进行Web程序的制作。Delphi有个好处就是制作辅助开发工具很方便，可以做出五花八门的工具来。在Web领域也是这样。
Web的层次展开确实是得局部取啊，否则做成层状干什么？就是让明细数据在用户的下一步点击之后才查询出来。
拿Delphi现有版本和C#比是不合理的。因为虚拟机运行机制的代价换来的就是全新的语言、开发环境的特性。等Delphi.net出来之后Delphi.net和C#Builder，以及VS.net之间才具备可比性。RTTI特性是与语言的高级程度有直接关系的。新一代的虚拟机型语言它们的rtti特性当然要上一个层次了，这确实是Delphi需要加强的地方。但是Delphi好在能够方便的访问底层，目前又有大量的第三方控件，虽然制作插件的接口复杂些，但攻克之后，做出的东西比较厉害。
对了，作为交流，请使用我开发的D6/C6插件：YExperts。
http://expert.csdn.net/Expert/topic/1765/1765310.xml?temp=.5508234

在Delphi中，倒是以第三方的EWF为主导，以WebBroker和WebSnap为基础进行Web开发，这种开发模式生产率和开发效果能超过VS.net和Java，这得感谢那些强有力的元件。如果是Intranet，还可以辅助以ActiveForm技术。IntraWeb和EWF差不多，只是界面上土了点。
总起来讲，Delphi中的Web开发手法应该说是“奇门功法”，或者说是“另类方法”。也就是说，那些比较厉害的Delphi的Web开发方法都没有走开发工具的默认方式，而是独辟蹊径走了旁道--要么运用了强有力的第三方控件，要么自己开发了特殊的辅助工具，要么运用了非官方认可的程序写法等等。
在开发Intranet的Web程序上，我经常制作ActiveForm，上面使用Midas之WebConnection与服务器连接，利用MidasLib将Midas.dll编译进ocx，服务器端用COM+的RemoteDataModule，通过httpsvr.dll在http上发布。这样制作Web程序几乎功能和界面都不受限制，要什么功能只有想不到，没有做不到。但这种方法和正统Web开发模式相比有耍赖之嫌。不过要真开发这种方式的Web程序，开发人员要绕些圈子，涉及到WebServer动态取OCX文件版本号，ASPack压缩OCX文件，为OCX添加数字签名等琐事。
将Delphi的Active Server Object功能也运用到Web开发中非常好，它和前端的ASP脚本相配合，刚柔相济，非常灵活。

回头看了一下楼主的问题，我忽然想起了一个有趣的东西，那就是可以将Delphi和JBuilder混合在一个Server中协同开发。方法是，取Borland Enterprise Server 5.2作为服务器平台，关闭IIS，开启BES的Apache Server。所有的网页都发布到BES的Apache中，同时用Delphi开发Apache的DSO；同时用JB开发Servlet/JSP发布到BES的Tomcat中。这里面Apache默认端口为80，Tomcat为8080,天然和谐共存，不是很好?
不过也有人习惯于IIS+Tomcat并存，也可以采用上述方法。

1）说道开发工具的插件，Borland的Open Tools API还算不错。不过BUG也是满天飞。新一代的VS.NET也应该具有插件技术，但是相关的文档太少。怎么说Delphi还有一本“Hidden Path In Delphi 3”这样的经典书籍。
2）ActiveXForm应该是个好东东，这一点Borland做的甚至比Microsoft还要好。但是也有以下缺陷。和数据库打交道一定得用MIDAS技术，否则就意味着客户端需要安装BDE。而连接方式只能用Socket或者HTTP两种方式。此外，Windows没有预装Borland的那些bpl，意味着下载一个ActiveX是相当恐怖的。另外，给ActiveX做数字签名也是一件头痛的事情。
还有MIDAS在Web上的表现时好时坏，不是每台机器都能OK的。
3）ASO是对ASP的补充，不过新的ASP.NET，已经非常强大了，再也不需要ASO这样的东西来补充了。同时ASO也有非常难于调试这个问题。

C#Builder应该是除了VC#.NET之后的又一种开发工具。不过竞争是非常残酷的，VC#.NET非常优秀，Borland除非能出奇兵，否则很困难。另外，Microsoft公司的模仿能力非常强。
Delphi.NET应该是.net家族的新语种，Object Pascal。应该说，借助了.net framework的强大动力，Delphi.NET在Web上的开发和C#就不分伯仲了。但是Object Pascal自身必须做大的改良，否则难于适应新的环境。比如说Attribute。从Delphi.net Preview看，Object Pascal是有这方面的改革的。

这个帖子我得收藏，那个插件我有机会看看，现在单位得机器都严禁安装Borland公司得任何产品了，只能在家看。同样，我也正在开发一个插件，完善了，还要公布一下。
在.net上，我觉得C#是完全针对.net设计得，所以最纯。VB，VC++就不能实现C#得某些特性。不知道Object Pascal是否存在缺陷。此外，有Anders在，C#得编译速度不会比Delphi差。

调试易

下一个项目是LAN中的B/S，用Delphi7还是JBuilder7？

解决方案 »