未来的C/S谁会是王道?

Question

经过长期的争论,说明B/S是永远不会替代C/S的,那么最具有传奇的delphi 已经风光不在,谁会是下一个Delphi呢,或者已经是了,我的leader是Delphi狂徒,我们这些80后的程序员，也不得不跟着做，delphi有很多优点，以前在学校长期在做JSP，就业后，只能跟着团队做delphi，也理解了C/S还是有很多值得称赞的地方、明显的感受到、未来的未来、C/S和B/S将永远共存，那么在C#和Java引领着B/S的发展的同时，谁会引领C/S呢 ？现在招聘DELPHI的已经很少了，而且网络上的 资源也少的可怜、C系列的开发效率好像慢（感觉哈、从没做过），下一个会像delphi一样的功能强大、且开发效率极快的的东东是什么呢，因为对C/S除了对delphi了解过，其他的一改不知，所以想问问各位对C/S有经验的高手说说、C/S的现状、C/S的未来、最好能说说在开发效率方面的特点。

Answer 1

  这个不好讲。我是搞DELPHI好几年了。感觉数据库这块PB更快。DELPHI暂时不会被淘汰。但如果我们靠他活下去
很难了。最好再学一门比如C#。

Answer 2

C#可以象delphi一样的快速开发吗？尤其是对数据库的操作？有专门用c#做CS开发的吗？他的很好用吗？希望 有经验的人多说说！

Answer 3

C#是搞WEB为主的。B/S的。C/S下你熟DELPHI就用DELPHI啊。

Answer 4

各位，想问一下，你说快三十的人再学delphi来的急不？

Answer 5

@starluck 
我也只能开发常用的普通开发，因为知道现在delphi已经快被淘汰，以后工作都不好找了，所以没有兴趣把delphi往更深的学，而且现在网上delphi的资源也非常少了，可以说是史上最差delphi学习时期，有问题没人回答，控件的版本老化的厉害，资讯没有了，感觉是要死的语言了，没有学好的气氛，我们就做个简单的EXCEL打印，都很难找到满意的控件，不管是华表，还是DEV，根本没有人乐意在这方面下功夫，整个delphi世界都快没有了，但觉的C/S还是有魅力所在，所以想请教各位，说说C/S的未来会是谁的世界！

Answer 6

因为知道现在delphi已经快被淘汰，以后工作都不好找了，SB一个

Answer 7

熊猫烧香就是用delphi做的吧单看这一点就知道delphi的厉害了

Answer 8

在没有能取代它的东西之前 delphi绝对不会被淘汰现在用delphi的少了
是因为B/S模式的兴起你不用delphi,难道还用VC不成现在我们公司里
VC程序员老说VC不行了
delphi程序员就说delphi不行了
其实都是杞人忧天一年前 我也觉得delphi前途并不明朗
现在搞了一年多.net
反而没这个感觉了

Answer 9

Delphi就来淘汰?天大的笑话~
偶从来不做Web和DB的,照样做开发,
Web这类都是上层的东西,中间件,服务器,驱动,照样需要人去做的,而且高门槛,才能保证饭碗~
Web很容易就能找到能做的人,即使做得不怎么好,也叫能做~而中间件,服务器,驱动这类东西,能做的人比例可少多了

Answer 10

我刚学会点C#，但是却上了DELPHI的船，希望DELPHI同仁们共创美好未来。

Answer 11

我晕哦,同学们,我只是想请教未来那们语言在C/S方面会象delphi一样成功,没有说delphi一定会淘汰,不过现在网络上找delphi的资源,还有delphi的职位是非常少，这个是存在的现状,我没想争论delphi会淘汰,更不想争论C/S,B/S谁更好,我只是想知道,现在或者未来,那门语言会最流行于C/S世界!

Answer 12

不是很明白楼主的意思。C/S=Client / Server？这当中无非就只是一个通讯。你可以是同一线程内两部件（业务完全独立）之间的通讯，也可以是同一进程当中两个线程的通讯，也可以是同一平台下两进程之间通讯，也可以是同一网段内两进程之间的通讯，也可以是两个不同网段之间的两进程通讯，还有可能是异构网络之间的通讯。在这当中实际上有三个主体，一个是Client(客户，一个需求主体)，一个是Server(服务提供者，服务供应商)，还有一个是Middleware(中间件，一个中间媒体，为客户与服务提供者提供信息和内容交换的一个桥梁)。关键点并不在于你用什么语言去构造这个Client或者Server，而至关重要的是Middleware提供的接口，更利用哪一语言上面的应用，又或者哪门语言内建了更好更完善的机制，使得Client和Server与Middleware更贴切，更具保障。而Middleware是一个不断发展和完善的独立个体，它不仅仅只是一个虚媒体提供者，更是由硬件作为载体，从而它不可能跟某一种仅仅只是用来表达思维逻辑的编程语言相挂勾，或者所受限。即便佣有如此一门语言，那么这门语言也将是为特定Middleware所设计的，置后于Middleware的。这种局限性，远远地限制了语言的生命力，而语言本身为谋求发展，也不可能仅仅绑定其中，而更由于硬件的发展，硬件与软件之间的衔接相对复杂，导致的是该语言（假定存在）相当复杂。而形色的Middleware，本身的兼容问题，直接延长了语言本身的发展周期。这是远为不利，并且没有意义的。所以可以得到的一个结论是没有如此一种语言。然后我们把C/S理解得更为狭碍一点，那就仅仅只是当前最为方便快捷的网络环境。或者仅仅只是SOCKET通讯。那么需要的是什么？一个是对中间通道环境的认识，二是通用通讯接口本身的长短处。所需要的仅仅只是对SOCKET编程特性的了解和经验积累。这个跟语言本身是无关的，除非该语言本身受限，而无法去使用这些接口，这样的语言在讨论到C/S的时候应该不会有人去选择吧？！所以在这里面讨论语言并没有太多的意义。接着我们把C/S局限于Client直接访问数据库。数据库是一个数据管理器，同样也可以理解为一个客户与数据之间的中间件，我们仅仅只是去跟这个中间件联系，所以可以把所有两层都归结于类三层/多层的结构，但是由于习惯性，都把数据库与数据当成一个整体。那么我们所需要的就只是寻找一条从Client到DB的通道。而通道我们通常来讲，设计的时候并不会去关心，仅仅只是使用一种方式，能够达到Client与DB(Server)之间的通讯。而楼主关心的仅仅只是这个Client的设计（应该不会想着自己去设计DB），以及Service(服务提供者，或者也可以称之为Server，实际上它的设计跟Client是一样的，也同样不需要去管通道，只是执行规则即可），那这个设计所选择的语言，还有必要去如何考量？就目前的Delphi而言，之所以被理解为适合应用于C/S的设计。并不是说它本身与通道之间的融合，如何的贴节。而是提升了一个与语言本身无关的成品模型。而大家就按照这些模型，以及由这些模型衍生出来的可用资源，以及更多的是利用Delphi开发，并且与Delphi密切相关系的第三方资源。那么这里面的重点，就转变为这些资源，而不是Delphi这门语言。从而也就从对语言本身的考量转变为对资源的考量。也只有这个时候，对让人把视线移出语言平台，转向容纳资源的大众环境。未来的大众环境是不可预测的。优生劣汰，这是世界发展的法则。所以我们需要的是磨练我们的眼光去识别并选择更适合我们的资源以及资源环境。

Answer 13

讨论这个问题的价值不大
当你把软件分成C/S、B/S时，认识以经偏差了
Java、C#都支持开发C/S和B/S的程序，Delphi同样如此
C/S和B/S从来都没有形成过互相独立的阵营，
以后更是会互相融合，WPF、RIA这些技术，
目的就是为了让用户无论是C/S，B/S都能得到同样的用户体验

Answer 14

我觉得要速度的话,b/s肯定是比不上c/s的(目前),c/s不会被淘汰.那么各种c/s开发工具还是有用武之地的,再说现在的客户端配制这么高,为什么非要b/s呢???

Answer 15

Re:18楼为什么非要b/s呢???
=================================
个人遇到的问题，就是c/s程序在因特网环境下运行时，布署不方便，会遇到防火墙的问题。但B/S在这方面就好的多。

Answer 16

个人遇到的问题，就是c/s程序在因特网环境下运行时，布署不方便，会遇到防火墙的问题。但B/S在这方面就好的多。
======================================
难道C/S就不用使用80等开放端口来布署？

Answer 17

我也有 lz 一样的同感，我觉得Delphi还有欠缺的地方，那就是不能像脚本一样及时编译。

Answer 18

我也有   lz   一样的同感，我觉得Delphi还有欠缺的地方，那就是不能像脚本一样及时编译。
================
也有类Delphi的脚本。

Answer 19

什么JAVA，C#，还C/C++，最好还是学数据库，大大的来钱。