NET重要技术思考——原文在《程序员》杂志第六期

.NET Remoting

       从COM(Component Object Model)时代到DCOM(Distributed COM)，微软扮演了一个推动者的角色。如果说COM提供了一个Windows平台上的对象通讯技术，并且逐渐成为应用程序之间彼此通讯及互动的技术主流，那么DCOM则是解决了计算机的通信和互动技术。

COM的着眼点是在于同一台计算机上不同应用程序之间的通讯需求，跨到另外一台计算机之外，就不是一开始COM所设想到的领域。所幸跨程序的通讯和跨计算机的通讯差异仅在于通讯协议的处理(也就是定位问题)，对于数据交换上型别差异的处理并不会因此而有区别。所以要让COM的环境能更进一步延伸到跨计算机的领域，只要妥善解决计算机定位的需求，就有机会克服。同样幸运的是，COM在一开始的设计中完全不去碰触跨计算机的问题，使得要在COM的架构之上再架上一层跨计算机的处理环境并不会去破坏到原本的架构。于是COM的网络延伸版本DCOM(Distributed COM)就此出现，专责让COM组件可以在网络环境下持续提供服务。DCOM最主要处理的是两个议题，第一个议题是网络通讯能力，第二个议题则是权限的问题。之前COM是在同一台计算机中找特定的组件，而DCOM则要更进一步去找网络上的某台计算机，之后沿用COM的机制找到计算机上的组件。

到了.NET当中，跨计算机的问题同样也需要对应的技术进行处理，.NET Remoting就是一个对应于DCOM的技术，它让存活在不同应用程序域(AppDomain，一个 .NET中的新概念)、不同执行程序、以及不同计算机上的对象能够顺畅的进行沟通协作。在累积了长期以来分布式应用的经验之后，微软没有理由把东西设计的更难用。从某种意义来说，.NET Remoting提供了比过去更易于使用的开发架构，用来来支持跨计算机的沟通作业，省却开发人员建立分布式应用程序时必须花费的心力，不过这样一个“出色”的分布式应用应用框架并没有得到本来应该得到的“待遇”。相对于Java的RMI而言，它更加简单同时保持设计方面的弹性，同时摈弃了DCOM的一些缺点，在对于一个前后端必须以有状态紧密结合方式进行互动作业，同时又期望呼叫和数据交换的动作上能以最有效的方式进行的环境而言，.NET Remoting是一个比较恰当的选择方案。

可是问题在于微软本身对于XML Web Services的狂热推崇让.NET Remoting迷失了本来属于它自己的阵地，也就是说XML Web Services的过火让.NET Remoting忘记了自己应该承担的角色，于是在开发者眼中成为了一个“可有可无”的作品，至少对于很多开发人员而言，在需要创建分布式应用程序的时候首先考虑的是XML Web Services，而在于企业内部应用，特别是在可以控制服务器和客户端平台的情况下（比如完全基于.NET平台的应用），Web Service因为效率等等各个方面的原因并无法体现出优势。从技术本身来讲，.NET Remoting是一个非常出色的架构，但在商业方面，这是一个失败，毕竟，设计一个出色的产品然后束之高阁难免“不像话”。

.NET Remoting恰恰是这个战略的牺牲品，虽然拥有与生俱来的优点，不过依然生不逢时。

Enterprise Services

       从一个很直接的感觉来说，Enterprise Services只是对于COM+的一个包装，从使用方式和技术实现本身而言，和VB或者VC下使用COM+服务没有本质的区别，而更多的只是在于多了一层托管代码的包装，让.NET开发人员能够比较顺利的使用这些服务的功能。

       相对于J2EE平台上的应用服务器如BEA的WebLogic，IBM的WebSphere或者开放源代码的JBoss，微软是希望能够在企业级应用之中分一杯羹，可是因为先天不足的原因，在企业应用中需要的事务、负载平衡、故障转移等等技术中的表现不是那么尽如人意，至少缺乏非常清晰的应用服务器（Application Server）的概念，虽然微软不止一次的强调操作系统本身就是一个应用服务器，一个IT信息的基础结构。但是从开发人员实际的使用来看，这是一个“晦涩难懂”的产品。

       虽然.NET Framework改变了很多东西，但是作为企业级应用中最重要的支撑技术——事务和服务，并没有得到同等程度的发展，我想这个也就是很多大型企业应用目前不选择.NET的一个理由吧，毕竟从MTS——COM+——Enterprise Services，这一路走来微软始终不是提供一个非常透明的机制让开发人员去控制各个环节（可能和微软一贯以来的策略有关，只是关心最广泛的应用而不是最高端的应用），而.NET中的所谓企业服务，和竞争对手提供的相当的EJB还是有比较大的差距，这是一个日前的微软无法解决的软肋。

Web Service

       从一开始，微软就将其作为“重头戏”推出，并且饶有意思的增加了XML，然后那个“XML Web Services”就成为了.NET战略中一个非常重要的术语，就如微软的白皮书所言“Microsoft® .NET 是Microsoft XML Web Services 平台”，微软通过.NET来改变现有的互联网络结构，“Windows正在走向过去”这样的宣传是在于希望各个子系统之间的通信完全基于Web Service，那样的话，作为Win32开发人员一直困扰的组建注册，分发等等一系列问题都能够得到解决，并且能够用更多的语言更多的平台去开发应用。

       “一切皆是Web Service”，这是一个冒进的举动，至少对于4年以前的世界，而这四年以来，虽然Web Service有很多很多的优点可以让我们“歌功颂德”，但是不是“万金油”，比如一直称垢的性能和安全问题也阻碍了Web Service一统天下，于是其他分布式应用架构在特定的领域依然能够有自己的生存空间。

       这一次，微软高估了Web Service，虽然目前的.NET是实现XML Web Services最好的平台，Visual Studio .NET也提供了从上至下的包装，让开发人员完全可以不关心协议的底层实现，比如SOAP，比如对象序列化，比如WSDL，因为一切的一切都可以在IDE中自动完成。我们不否认因为.NET，Web Service从概念已经走进应用，而WSE 2.0的出台更加Web Service具备了互操作能力，不过依然无法改变开发人员的观点，只有在企业外网应用集成或者内部异种平台整合的时候才能够体现出优势，在于需要高度响应和服务支持的应用方面，Web Service只是一个臆造的神话。

ASP.NET

       我们无法否认，这项技术对于开发人员而言是一个颠覆性的改变，从静态的HTML到CGI再到ASP/JSP/PHP时代，我们都必须去了解HTML，了解HTTP，对于高水平的开发人员而言，需要掌握的还远远不止这个，在脚本横行的时代，我们必须很清楚的去了解实现的各个细节，包括HTML，JavaScript，CSS，还有和服务器相关的Request、Response。最直接而言，开发人员必须严格控制所有HTML及其相关内容的产生，脚本带来的只是一个相对于CGI层次更加高级的“自动化”罢了。

       然后，ASP.NET将这一切完全改变，WebForm让Web开发人员能够和Windows开发人员一样处理页面事件，同时可以完全的访问强大的.NET Framework类库，而且预先编译机制解决了ASP一直以来的效率低下问题。而在服务器端的设计，在原先ISAPI的基础上从新实现了HttpHandler和HttpMoudle，从而为开发人员提供了高度扩展的可能，而日前比较成熟的WebLog引擎.Text正是这些技术的经典之作。

       XML Web Services的内置集成则使ASP.NET成为Web Service应用的最好实现，日前市场上相当大部分的Web Service都是基于ASP.NET的，在这点方面ASP.NET已经远远超出Java社群的技术，包括JSP，包括Struct，包括JSF还有其他相关的Web应用技术，在ASP.NET都能够得到非常好的集成。

       我们不可能否认这个事实，相当大一部分（我个人认为是大部分）的开发人员转向.NET是因为ASP.NET，对于ASP开发人员而言，ASP.NET提供了更加强大的功能，很多在ASP中必须依赖组件技术来解决的问题比如文件上传在新的平台上已经成为内置支持，当然更加重要的是依赖Visual Stuio.NET强大的集成开发环境能够成倍的提高生产率。而另外平台的开发人员转向ASP.NET我想也是因为弹性的设计及其便捷的开发，我相信没有太多人会怀疑ASP.NET已经走在Web开发的最前沿。

       当然，任何事情没有绝对的完美，在.NET Framework 1.1(也就是.NET的第二个版本)之前，太多的Postback也是让开发人员抱怨之处，而且采用WebForm的开发方式让很多开发人员不是那么容易的处理客户端脚本，所有的事件实现都是依赖于ViewState，因此在低带宽下的网络应用，不断地提交也让有些用户感到“恼火”。

       这个世界没有绝对的完美，但是会一点一点走向完美，也许ASP.NET 2.0就有太多东西值得期待。

 

ADO.NET

       相信大家不会忘记ADO（ActiveX Data Object）,我想Windows上面数据库开发流行它功不可没，通过统一的接口来实现对于数据库的访问，从而屏蔽复杂的数据库访问协议。而到了.NET时代，ADO.NET进一步将数据访问“进化”，不要以为ADO.NET只是ADO的一个升级，在ADO的技术上提供了一个托管类库，除了都是数据访问框架，其他没有太多本质的关联。

       虽然ADO.NET带来的震撼远远不如其他技术，可依然有很多东西值得我们去欣喜，毕竟创新总是一件好事情，何况是这个最成功的软件公司带来的创新，那么我们就来看看到底带来了什么：

1．  除了提供了传统ADO的Connection,Command以外，我们意外的没有看到Recordset这样的对象，而是提供了DataReader用来处理向前滚动的数据访问，最最重要的是加入了DataSet这样的概念，因为如此，我们能够实现很多数据库应用中需要的“Disconnected Application”，能够实现“InProc-Database”，而这一切，通过DataSet能够得到很好的解决。

2．  以更加透明的方式提供了数据库连接池，同时开发人员能够通过变成的方式控制具体的运行方式。

3．  提出DataAdapter，让开发人员能够以一种统一的方式去访问异种数据库，唯一的区别在于具体适配器的实现不同罢了。

4．  “Typed Dataset”让开发人员能够非常方便的将DataSet 中的Table、Field映射到自定义类。

5．  对于XML提供了良好的支持，所有的DataSet都能够非常容易的系列化或者反系列化成XML文档。

当然ADO.NET不是万能的，在数据持久层（Data Presistent Layer）方面的支持显然不如Java，到现在为止都没有一个很好的O/R Mapping工具，而Java方面的Hibernate已经非常成熟，ADO.NET 2.0中的ObjectSapce也许能够改变目前的现状，就让我们耐心去等待，虽然需要到2005年。

 

posted on 2004年10月10日 1:21 PM

Feedback

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 11:32 AM zhuam

very good!

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 1:02 PM Suzan

还不错，尤其那首小诗。

# .NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 2:20 PM Piggy and Jery

Ping Back来自：blog.csdn.net

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 7:49 PM Justin

不错，开左眼界。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 9:32 PM erictang2003

最强势部分就是 ASP.NET + ADO.NET 说的没错!
当然 GDI+ 也不错!

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 10:16 PM freelancer

我是才学的.net
新手
不过也基本看得明白
不错

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 10:21 PM chechy

赞成其中的大部分观点。但是，我用了一段时间Hibernate后，实在是对它不敢恭维，相反我还是喜欢.net的DataSet。Hibernate也许会使对象清楚些，但是烦琐的操作，和.net的DataSet根本无法相比。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 10:38 PM 随便说说

说的不错，我以为.net FrameWork 对于程序员最大的好处是我们编程序的效率更高了。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-11 10:53 PM arnoldmjw

我一直再用Remoting,在局域网内的效率很好的

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-12 8:31 AM nice90

.net NHibernate 或许值得期待
Java Hibernate 确实非常不错

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-12 9:36 AM cl

说的真挺好，高手看着有意思，新手也能看明白。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-12 10:11 AM John

说了我一直困惑的东西，我很讨厌 Viewstate和postback

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-12 3:09 PM cometomysz

楼主说得比较好，但是如果对于一些大公司，或者一些用纳税的钱的公司，完全不要去.net而去用java，因主开发成本对于他们来说是多余的考虑；而对于我们的想赚钱的公司来说.net是最好不过的

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-12 6:12 PM 王浩

明，透；
中国都有这样的人，为什么不去开发操作系统？
看来中国不缺乏高手、善意之人

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-12 9:54 PM 小

我是不懂呀！

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 12:13 AM 路过的人

我不是很理解。说一点，VIEWSTATE和POSTBACK，没有你说
的那样不好用，如果你自己写的玩老是回送无所谓，商业化运
用下你是需要去改动的，最后让页面整体提交。前台的脚本比
以往更让人觉得使用方面。大量使用htc可以提高页面的效果
和互动性。在我看来，改进后的B/S系统，程序员可以在原来
的TAG里随意的加入自己的属性，在脚本中就可以直接使用。
同时在自定义对象方面，采用HTC可以有意想不到的效果。这
点可以在MSN的网站上看出来。说白了是要深刻理解对象，我
们看到的HTML文件全是文件，但每个TAG在浏览器中都是个对
象。老外在这个方面的运用比我们强多了。
其次，商业化运做我们要追求的是高效率和低成本，我能实现
同样强大的功能为什么不用呢。JAVA其实也是国外公司用来
抗衡的一种商业武器。它的代价是消耗你的机器性能。真的有
那么多东西要跨平台吗？如果需要我现在宁愿选择用WEB SERVICES。高响应用JAVA也不行啊。大并发的一般都用C写。C是静态编译，C++是动态编译，JAVA是解释执行。大家
都有缺陷，但那个快我想你还是很明白的。
个人认为你的这几个观点不成熟，我们不能用研究的眼光去
看应用。你的技术过硬就会合理利用这些，没有完美的，完美
的需要我们一起去创造！

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 12:19 AM 路过的人

PS：我也觉得长期在微软平台上的软件工程师会深受其害。
但我也觉得你没有必要在介绍每个技术的优点，评定为软肋
什么的。不知道你是不是个优秀的程序员，还是看了很多
介绍性资料。个人认为不需要误导。谁都有缺点。不光是
微软。有日我们国家也出个微软，那才是真牛。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 1:12 AM liuruhong

呵呵，终于看到一些对于我来说比较有意义的评论，不过我依然不是很认同你的一些看法。

1。相信我还算了解viewstate和postback，在很多情况下我也是建议不采用太频繁的回调和没有必要的viewstate，但是对于大多开发人员而言，ASP.NET给大家的感觉就是WebForm，利用viewstate和postback能够和写windows form程序如此简单,是的，是可以如此简单，但是目前的设计不是那么的好用，这点我相信大部分开发人员有同感，比如在类似处理无刷新的callback等等，我们总是需要想很多方法去解决。

2。我也接触过一些htc的开发，在web应用方面，我不是非常赞成使用htc，至于原因，我想一个是从跨浏览器的角度考虑（当然你可以告诉我在商业应用中可以不考虑跨浏览器），但是htc的效率是比较低下的，至少相对于javascript控制的dhtml而言（呵呵，不要和我争论这两者之间的差别或者概念混淆），总体感觉htc比较消耗内存，你可以看看http://www.stedy.com这个站点，的确很漂亮，但是说实话，效率确实比较一般。

3。我不是在否定web services,相反在很多应用中我会采用它，比如B2Bi,EAI等等，我只是从个人角度去认为微软夸大了web services的能力。

4。对于.NET Remoting,Enterprise Services,Web Services包括MSMQ这几个分布式应用程序可以采用的技术架构我说不上精通，只是在原来的项目还有个人的平时时间做过一些研究，因此对于其的评论我想不是在贬低哪个技术架构，正因为每个架构有各自的优势，所以许多时候难以取舍，但是就目前的宣传而言，Web Services表面的风光我想大家不会去否认的

5。对于Java，我从来没有觉得跨平台有多重要，因为在很多时候只有平台绑定才能够发挥出系统的威力，Java相对于目前的.NET最大的优势在于它架构的标准和开放性，同时已经具备大大量成熟的应用，我从来无意贬低.NET，想法，我在.NET方面下面做的工作占据了我大部分的时间，而且我个人的工作也和微软技术紧密相关。

6。我不知道一个合格程序员的定义在于哪里，虽然我也做过一些程序，做过一些系统设计，可能在一些高手的眼中那只是玩具，其实可以理解的，我想对于一些技术的评论我不会仅仅看过一些资料就武断的对于一个技术下一个评论，我能够做的也只是在我能力能够理解的范围内去表达自己对于技术的观点。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 1:14 AM liuruhong

ps:我最前面的文字也提到了，仅仅代表个人的观点，不保证其正确性，也不做其他商业用途的说明

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 8:33 AM 123456

.net 做不大啊,适合开发小型网站及小型管理系统,要是做大型的网站和企业级应用程序还是要用j2ee.兄弟们.net比较容易掌握,开发的人员自然多了,人才一多,待遇就低了,连微软也说招一个同样水平的java程序员比.net.程序员成本要高(言外之意说java的薪水比.net要高).兄弟学习这玩意,无非为了谋生.谁不想待遇比较好一点的工作.我想大家还是考虑java(虽然它比较难学,发毕竟是适应开发大型程序的吗,多了一个应用服务器就够你们学的了,还有那健壮的j2ee架构.在移动设备j2me的成就有目睹的)

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 9:14 AM aa

不用精.NET我誓不转向Java

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 10:53 AM 654321

123456 :
不知道有几个大型企业要你去做开发，又有多少笔上千万的项目等着你去做。最后的情况大多是你小项目不屑做，积累不起经验，大项目又做不来，最后饿死。
如果不想脚踏实地的做点东西，只想去骗钱的话，用JAVA是不错。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 10:54 AM Michael Mao

殊途同归，技术发展到最后都趋同了。不信你看看J2SE 5.0

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 11:51 AM 路过的人

http://www.stedy.com慢和用HTC没什么关系吧。htc
目前主要用于处理前台的一些效果，和JS一样，关键事件
响应的代码处理合理点就可以了。个人觉得讨论技术可以
从2个方面入手：研究和应用。好比学习和工作。开放性
和架构的标准性一直让我觉得很无趣。别人的东西开放很
有限，大公司的核心研究部门没有有色人种。操作系统的
很多API并不对我们开放，何来开放，我们现在只是用用
而已。标准也是别人定的，人一天一个版本，我们就一天
一个版本的跟进。我几年前做个网管项目，有些操作系统
的核心函数找不到，最后只有从二进制文件中反推结构自
己做，苦啊。JAVA这几年不如前几年火了，ASP缺陷太多
基本ASP的网站我相信你也可以在短时间里黑掉，其实你
说用什么好呢？我们只能叫蓝领工人，别人大旗一挥出个
新语言，我们就跟吧。web services在3G会有很大作用
。我觉得你可以修改你的文章，从2个方面谈优缺点会比
较合理点。存在就是合理，讨论是为了更好。从用到改再
到出新，路很长。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 11:59 AM 123456

你们用精了.net再转j2ee又如碰到一块硬钢板,可是精通了j2ee再转.net就如吃豆腐.这个好多人有这样的经历.很多用过.net 和 j2ee的人我想都有这种感觉吧.针对你们说的,没什么项目开发大型应用软件,要是你的开发网站在线人数达到上万或者几十万的时候,你还该用.net吗?看看目前几个大的门户网站(sohu 163等)还有国家的金融系统,电信系统等,要是你还不相信我推荐你们到人才网上去看看,网上基本招的是什么的人才,待遇怎么样,我在此推荐几个网站.(www.51job.com www.cjol.com不过地址再好选深圳)其实我以前是搞.net就是待遇不好,转搞j2ee的.生计所迫啊,没办法.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 1:17 PM liuruhong

to 路过的人
我最近确实有打算重新写这篇文章的打算，因为当时时间比较紧，感觉一些东西没有写清楚，如果有兴趣，希望得到你的帮助，可以给我发email,就在blog里发送就可以了

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 1:49 PM 123456

http://www.stedy.com在linux下那浏览器显示不正常.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 2:35 PM 路过的人

呵呵，帮助谈不上。我以前是写C的，对.net也是在研究中
我的打算是做一个基于.net的开发平台，一直想把WEB的程
序软件化。对xml,ldap,soap,web services等等研究的
还不够深刻。webform其实是个好东西，可以帮助网页程序
员的转型，123456说的不错生计所迫。后台.net前台xml+
ldap，我不知道这样的模式是不是可以提高很多效率，而且
加强管理。不过成型的话有一定难度。
PS：123456，stedy.com的程序可能只针对IE，如果要满足
好几个浏览器，工作量会倍一倍，你可以在你程序中用到JS
效果的地方附加<noscript>段。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 2:41 PM liuruhong

我从做程序开始就是在vb和com/com+上面打转，所以对于底层的了解比较有限，但是对于上层各种技术架构相对有兴趣，对于web也作过一些开发（虽然现在做的相对比较少）

# 不解 2004-10-13 4:36 PM 不解

怪现象，只要有.NET技术的讨论总有一些来吹捧J2EE平台如何高薪的人。最让人不解的是此类人似乎都擅长摆出“大要是你的开发网站在线人数达到上万或者几十万的时候,你还该用.net吗?看看目前几个大的门户网站(sohu 163等)还有国家的金融系统,电信系统等,要是你还不相信我推荐你们到人才网上去看看,网上基本招的是什么的人才,待遇怎么样,我在此推荐几个网站.”这类怪言论……

J2EE的所有技术在.NET和WINDOWS下都有等价技术，不解二者难易如何区别。

可能J2EE平台的难点是很多厂商都有各自的实现吧，很难有人精通所有实现吧？

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 5:30 PM liefeng123

不明白为什么放着容易上手、效率高的东西不用去用那些很复杂又高额成本的东西？商业运作就是为了利润！

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 6:00 PM x

“微软不止一次的强调操作系统本身就是一个应用服务器，一个IT信息的基础结构”

Windwos Server本身即使一个应用程序服务器，以活动目录域实现企业目录；以COM+服务提供事务性或持久性；负载平衡服务提供负载平衡；IIS服务提供多种上层服务服务；集群服务提供灾难保障，配合SQL SERVER /EXCHANGE SERVER/ISA SERVER/STORAGE SERVER提供全套企业服务。

相对于BEA的WebLogic，IBM的WebSphere这种昂贵的产品实现，应该按需求和承受能力来选择。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 7:36 PM .net 程序员 6k

j2ee不是什么人都可以搞的，如果E文不好就别想搞精。现在要想保持竞争力就要把技术吃透，单靠市面上的十几本J2ee的书想搞精j2ee是不可能的。象讲JBOSS的书就两三本，你不可能就靠这几本书就去做什么几百万甚至上千万的大项目吧？所以java虽然有众多大项目的成功案例，我们也要看看自己是不是这块料，别弄得最后是高不成低不就。
说搞.net收入低我不太同意，如果你搞.net收入低那只能说明你学的不够精，在我看来真正懂.net的程序员不是只会托拉几个控件到page上就行的，真正懂.net的程序员应该精通以下技术：asp.net、Com+、httphandler、自定义服务器控件、Web Services 、Remoting、javascript、visio、uml、设计模式(包括MVC)，正则表达式、反射、XML、水晶报表、application center test、Sql server。所有这些技术都有大量的中文书籍、文章讲述。现在每两个月就有一本中文MSDN杂志,明年还会有中文的《.net magazine》月刊，如果你真能熟练掌握这些技术你的收入不会低到哪里去。
所以一些人说三个月就可学会.net、.net是傻瓜语言是非常愚蠢和幼稚的。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 9:05 PM ……

楼上的列举的所谓.NET高级技术，真是幼稚可笑……不知……唉………………

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 10:54 PM 脚踏实地

“楼上的列举的所谓.NET高级技术，真是幼稚可笑……不知……唉……………… ”


别光讲空话，说点有用的东西。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 11:29 PM ...

介绍个高手给大家认识，他叫李毅。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-13 11:39 PM 阿里-汉

李毅？国家队踢足球的？^_^

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 12:55 AM 没提啊：）

.net智能客户端技术也挺好玩

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 7:29 AM cjijh

server asep.net component 嘿嘿

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 8:38 AM 123456

是很多技术.net和j2ee是相似的,因为微软抄袭了太阳.(这是微软的四大‘竞争利器’之一这本在李维大师的<<宝兰传奇>>有说).不过微软再怎么抄总不可能一成不变的搬吧.所以他也加入了一些新东西.不过总体思路和关键技术还是模仿j2ee.只不过一些细枝末节作了一些修改而唉!.(.net)微软开发团体并没有java开发团体多 (就如.net到目前为止还没有搞出个像样的中间件应用服务器,要是没有强大的中间件服务器支持,.net 就永远做不了大型程序,这也是他们团体开发人力不足的表现,也是微软搞闭关自练的恶果,)本人说一下java开发团体(sun主要负责开发java的标准,而很多公司(ibm,bea,oracle,borland,开源团体等N多公司投入开发java或全面支持java).不想再多说了,还是继续调试我的程序去吧(我目前的工作是搞.net开发,不久以后就想换了).

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 8:44 AM 123456

老兄IIS也叫应用服务器,叫webserver还差不多,这个连tomcat都比不上,要是你学j2ee,用一下bea的weblogic, IBM的websphere,就知道了什么叫applicationserver.像IIS这样东西,开源的东本多的是,一抓就是一大把.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 8:51 AM 123456

有些东西在开发小型能体现出高效率.但是随着应用增多,开发成本和维护成本也直线上升,而有些构架,刚开始速度和开发成本比较高一点,但随着应用增多,开发成本和维护成本升的比较缓慢,大家仔细想想,就会知道企业为自己选择架构(从实际出发,我不赞同所有企业都用j2ee,一些应用不多企业,或者网站的并发量在三位数内.最好选择.net.要求高一点就用j2ee架构比较划算了)

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 9:50 AM 微软的走狗

"是很多技术.net和j2ee是相似的,因为微软抄袭了太阳"
sun准备推出的1.5也抄袭很多.NET的东西， 大家互抄而已，大家老说微软抄别人，怎么不说openoffice抄ms office，在应用软件方面，微软被别人抄的东西多得是

“微软的四大‘竞争利器’”
李维，也不过是Borland的吹捧者而已，他的书几乎净说Borland的好处（当然得承认他老人家的技术）
微软挖人有什么不行，又不是用枪逼人去工作，清华、北大每年把全国的状元都“挖”走了， 怎么没人去骂

# 应用程序服务器？ 2004-10-14 10:45 AM 到底会不会用WINDOWS？

特别针对123456……你恐怕连WINDOWS应用这一关都没过吧……？上面似乎有人解释了作者“微软不止一次的强调操作系统本身就是一个应用服务器，一个IT信息的基础结构”
的意思…TOMCAT……你恐怕连IIS的功能都列举不全。

开源……开到系统调用这一层就算不得了吧，对一个搞应用的人有多大帮助不得而知，绝对中国小作坊“小而全”的思想，理解牛顿“站在巨人肩膀上”含意么？

最可笑的是你.NET框架只能小型应用这个论点，不解微软网站和这里的应用算是什么玩意……

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 10:49 AM 123456

在抄袭我只想表明,j2ee比 .net架构设计更优秀而唉!并不是说其它什么的.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 10:53 AM 123456

其实学J2EE也不是很难的,只是设计的程序大了,想的方面多了,复杂了一点.我想聪明中国人.绝对能应付的了.我推荐大家j2ee和.net都要学.最好先学好j2ee再学.net这样掌握这两门技术总时间相对会少很多的.老一辈的程序员.已经用实践证明这一点.真的,我讲的是真心话,绝对没有骗大家感情.

# 补充一下 2004-10-14 10:55 AM 到底会不会用WINDOWS？

选择这两种技术不是看应用大小，而是要考虑自身投入收益、对方投入收益、已有系统现状、成本和预算和其它这些因素。已有了IBM 服务器，跑着 AIX UNIX，不用WebSphere的J2EE实现 非要用.NET，已有了优利ES7000，跑着WINDOWS不用.NET非用WebSphere，那才叫纯粹的抽疯。

# j2ee比.NET设计的优秀？ 2004-10-14 11:16 AM 到底会不会用WINDOWS？

歪理邪说真不少……分明是两种企业解决方案，何来设计优越？不知你是不是真的把两种平台技术和WINDOWS的设计理念理解了……
我其实很不解EJB的部署搞一堆XML部署文件是很简单的事？和部署一个COM+差不多了，起码COM+还有可视化环境和ATL模板支持着……J2EE术语EJB CMP在COM+术语里等价事务和补偿资源，同样效果的玩意……
ADO.NET可以实现事务，就是J2EE EJB所谓的BMP
JNDI 等价技术 活动目录
JMS 等价技术 消息队列
以下略

允许的情况下，我会绝对推荐.NET。
有人指出：“我雇用一个JAVA程序员，可我都不知道他每天在做什么”。虽然这个管理者素质有点的，不过这也说明了一个潜在问题：J2EE太“难”了，蕴藏着管理的风险。不过行业里总有不少喜欢混水摸鱼的同志，倒是希望从业人员都摆正心态。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 11:23 AM 路过

我觉得这样的文章讲得很好。
可是总是有一些不入流的声音。
他们不是讨论，是扯淡。
我很欣赏作者的文章和态度，很希望还能看到你的文章。

# 关于本文的.NET Remoting 2004-10-14 11:24 AM x

再次仔细读过着篇文章，几个朋友一只觉得这里存在一个对.NET Remoting的误解：）
粘贴一段MSDN的原文：
编程模型
在设计分布式应用程序时，可以在几个新的编程模型之间进行选择，以使应用程序之间可以通信：

ASP.NET - 可以使用 ASP.NET 页框架创建 XML Web services，使这些 XML Web services 可访问 .NET Framework 的许多功能，如身份验证和高速缓存。有关更多信息，请参见托管代码中的 XML Web services。
ATL Server – 还可以使用 ATL Server 创建 XML Web services，这样可提供一组扩展活动模板库 (ATL) 的类，以通过 ISAPI 访问 IIS 的全部功能。ATL Server 提供使开发者可轻松处理诸如高速缓存、线程池和会话状态等问题的类。有关更多信息，请参见用 ATL Server 创建的 XML Web services。
.NET 远程处理 – 可以使用 .NET 远程处理创建使用 XML Web services 的松耦合解决方案，或创建使用二进制协议的紧耦合解决方案。有关更多信息，请参见 .NET 远程处理概述。

几种模式是为各种环境准备的，无所谓主次：）均是.NET解决方案的一环。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 11:50 AM liuruhong

.net remoting是一个非常不错的架构，如果说有错，我觉得还是微软宣传方面的问题，大多人更加熟知web services而不是.net remoting

# 不得不说，微软的宣传策略确实忽视了远程调用 2004-10-14 12:04 PM x

远程调用确实被宣传忽视了，可能考虑了大众的认知能力或是其它因素吧。
不过创建一个WIN32（DELPHI7比较典型，可以直接生成引用WEB SERVICES模块）应用（或其他异构应用）欲和.NET框架远程交互数据，似乎远程处理法就不能体现完全的跨架构跨进程特性了。
不得不说，远程处理被多数人忽视，这是技术层面之外的因素。不过开发工作者们应该还是能意识到他的作用的：）

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 1:49 PM 123456

.net是基于WINDOWS安全性想对来说差了一点.所以政府及安全要求高一点应用.固然不会优先考虑这一点.有些人例证一些J2EE .NET技术差不多.但是你对这些技术作深入的研究,就会知道J2EE比.NET成熟很多(毕竟J2EE发展了那么多年).要是你固执说,一样,那只能说你没进一步的学习(说真的,我也是刚学一些表面的,这些话是从我们同事们"老一辈程序员的声音".但是,我坚信,有争论才会有发展,就像J2EE和.NET有竞争才会有发展.要是没有J2EE.我想也不会有.NET了.要是不理解这句话,大家最好看李维大师的<<BORLAND传奇>>)

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 2:12 PM 123456

我想有人还没有用过weblogic.webspere应用服务器,兄弟你去用一下,就知道IIS是什么货色.要是IIS能胜任,企业为什么还花"十几万人民币/CPU".你以为他们是傻子啊.

# “微软不止一次的强调操作系统本身就是一个应用服务器，一个IT信息的基础结构” 2004-10-14 2:32 PM 到底会不会用WINDOWS？

如题……IIS是WINDOWS服务“之一”
“可是总是有一些不入流的声音。他们不是讨论，是扯淡。”
－包括我在内，不过不吐不快

# 微软不止一次的强调操作系统本身就是一个应用服务器，一个IT信息的基础结构 2004-10-14 2:39 PM 到底会不会用WINDOWS？

如题。IIS只是WINDOWS众多服务“之一”……

“我觉得这样的文章讲得很好。
可是总是有一些不入流的声音。
他们不是讨论，是扯淡。”
再扯淡一次，实在不吐不快。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 2:39 PM liuruhong

我和BEA的技术部门还有市场部都有接触，weblogic是一个很好的产品，bea也是一个很好的公司，但是如果你说iis不行，应该说是你不了解IIS，这两个平台都有自己的优势的，没有绝对的好和差

# 不希望看到技术阵营之间用言语互相贬低 2004-10-14 2:56 PM x

单纯言语较量在技术密集行业似乎不是好习惯。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 3:04 PM kandy

总有人说windows操作系统以及之上的相关应用不如其他系统安全，这点我也始终持反对意见。使用微软产品的人远远多于其他操作系统，正因为用的多了，了解多了才发现很多问题。比如10000个人使用微软产品发现了100个问题，而有1000个人用其他系统发现了15问题，请问哪种系统好呢？问题是有些人只看的懂15，而不懂 100/10000 和 15/1000 哪个大。N年前电脑报上就有报道说某操作系统的安全事件比windows多。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 3:24 PM ilovevc

光说架构，感觉应该都差不多，理论的东西。具体的实现可能有些区别。J2ee由于体系比较开放，因此有很多独立的中间件开发商，而微软的已经在操作系统中集成了，由于巨大的操作系统垄断性优势，因此在windows下就几乎只有微软自己的产品，别人也很难插足。

要说J2EE里面的东西，微软以前在COM+中也有实现了，例如Active Directory就是naming server，MTS是一个transaction services，DCOM提供分布式对象支持等等。

本质上大家都是想提供一个中间层，能够实现分布式应用。不过实现手法不一样罢了。例如你用XML，我用注册库，底层机制都差不多，例如RPC，都是使用proxy/stub模型，remoting也好，xml web services也好，包括java的都是一样。这种理论可能30年前就有了。具体上层的实现语言或者其他可能区别就大些。

你懂了任何一种体系架构，对另外一种体系架构都能很快的理解，而且几乎都能找到对应的东西。毕竟大家要处理的问题都差不多。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 4:20 PM 阿飞

http://www.stedy.com
这个网站确实太慢啦
我的机器是 P4 2.8C 512DDR400 Intel 865Ｇ
呵呵，死慢死慢呀

#  ilovevc 说得好 2004-10-14 4:34 PM 到底会不会用WINDOWS？

ilovevc 说得好。这才是真正理解了架构的人！反观某些人……真是可叹

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 4:50 PM 123456

跟你们深受MS毒已深的人没得说了.再说下去有高端服务器操作系统市场,都是MS的天下.根本没有UNIX的市场份额了吗?低端服务器(基于PC)是不是LINUX是不是没有存在了.哈哈哈哈!!!!!!!!!!!!我们搞开发的人我想对服务器的依赖比较重一点(不过桌面操作系统也不放过.移动设备客户也很重要的(这个现在JAVA先占先机了)),再看看在服务器市场大家自己说一下.MS的份额是多少呢(也放你们认为99%,要是真的这样的话,我又会狂笑一陈子,你知道我为什么笑吗?)

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 4:56 PM 123456

说真的,搞程序代码编写还是没有出路啊,尤其是上层应用程序开发.多搞搞模式设计对我们前途会好一点.要是那位兄弟对ERP有感兴趣的话(目前国内正在兴起,但是做的出色的真的很少).我可以开个话题,讨论一下模式设计也好.讨论架构设计实在没啥意义.也搞不出个所以来.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 5:03 PM 123456

讲一个笑话.一个命叫 bill gate的 他要跟一个前些日子出车祸变成"植物人"(不过他会说话).比历害. 那植物对BILL GATE 大声说,我有手也脚,还会说话,我跟你是一样.BILL GATE 无语.

# ……123456 2004-10-14 6:15 PM 到底会不会用WINDOWS？

本来没什么事情做，想和你争论来消磨下时间，不料连这点价值都没有了……
移动设备……今年盖茨的无缝计算演讲，把战略表现得很透彻了……。
虽然借题讽刺对文章作者和其他认真参与评论的人不太尊重，但不得不说：
人品我和你一样差劲……但你的业务水平实在太可怜了……

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 6:30 PM liuruhong

欢迎有思考的争吵，我个人的理解也有限，有问题可以直接指点，不过希望不是个人攻击

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 7:02 PM 123456

老兄,你看明白了吗?我并没有说微软没有在移动设备建树,只不过现在形势.J2ME占先机而唉!.看明白再说好不好.再说一下,作用一个人,再好不要骂人.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 7:03 PM 123456

我不喜欢跟要骂人的,争论技术.在此争论.目前只有一个.提高自己,但不是伤害别人.

# 一种消遣 2004-10-14 7:43 PM 到底会不会用WINDOWS？

压根也没打算争论…纯粹来消磨时间玩儿。文章作者的水平和认识绝对没得说，有不同观点也不过是个人习惯问题：）

……无奈的是这位123456，因为存在太多谬误，只好用讽刺来应对了，对他不是争论，是“扯淡”，个人其实就是在骂他，一个带了太多行业里令人恶心作风的家伙。

无论那一阵营都领会得肤浅，但却主动分化技术阵营；为了就业而做一切，但却冠冕堂皇来参与技术讨论；把编码环节孤立出来视为无出路低级劳动；在没有掌握多种解决方案的前提下来讨论“模式”；人云奕云的宣扬“安全性”“大型应用”“移动设备”“应用服务器”“ERP”“模式”…殊不知自己亲身证实的观点到底有那些。

123456，骂你是一件很让人开心的事情，给了无聊的自己一个狠狠骂业内无知思想的机会。

个人脾气比较急：）打搅其他人真是不好意思了，其实大家看看两个低级人物如何争斗有时也挺有意思

# 123456语录摘录 2004-10-14 7:57 PM 到底会不会用WINDOWS？

123456：

今天无事做，摘些您的语录，纪念一下，顺便帮您宣扬一下您伟大的学说。ERP是封装了企业经营管理因素的科学，劝请切勿盲目开版讨论


".net 做不大啊,适合开发小型网站及小型管理系统,要是做大型的网站和企业级应用程序还是要用j2ee.

兄弟们.net比较容易掌握,开发的人员自然多了,人才一多,待遇就低了

要是你的开发网站在线人数达到上万或者几十万的时候,你还该用.net吗?

是很多技术.net和j2ee是相似的,因为微软抄袭了太阳.

就如.net到目前为止还没有搞出个像样的中间件应用服务器,要是没有强大的中间件服务器支持,.net 就永远做不了大型程序,这也是他们团体开发人力不足的表现,也是微软搞闭关自练的恶果

老兄IIS也叫应用服务器,叫webserver还差不多,这个连tomcat都比不上

在抄袭我只想表明,j2ee比 .net架构设计更优秀而唉!

老一辈的程序员.已经用实践证明这一点.真的,我讲的是真心话,绝对没有骗大家感情.

.net是基于WINDOWS安全性想对来说差了一点.所以政府及安全要求高一点应用.固然不会优先考虑这一点.

但是你对这些技术作深入的研究,就会知道J2EE比.NET成熟很多(毕竟J2EE发展了那么多年).

跟你们深受MS毒已深的人没得说了………………哈哈哈哈!!!!!!!!!!!!

说真的,搞程序代码编写还是没有出路啊,尤其是上层应用程序开发.多搞搞模式设计对我们前途会好一点.

要是那位兄弟对ERP有感兴趣的话(目前国内正在兴起,但是做的出色的真的很少).我可以开个话题,讨论一下模式设计也好.讨论架构设计实在没啥意义.也搞不出个所以来. "

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 8:22 PM ldd10345

同意大家看法
他门好象把.net向世界公布做为国际标准了吧

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 9:09 PM 123456

我是自学软件开发.才搞了一年(在一家公司搞erp开发,对制造这一块比较熟一点).很多东西并不懂.所以也说不去什么真实技术.希望高手多多指教.至于上面我说那些,基本上是引用别人的东西.并不是我的观点.我想进这里的人基本上对.net比较热衷.我讲哪些有可能伤害你们.真不好意思.不过我在这里也被一些人骂死了.但是我还是不会回骂.你为真正中国人.是不会这样的.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 9:40 PM null

不管怎么样，能解决问题的就是好的。JAVA固然有大家说的那么多优点，可用JAVA开发一个项目需要多少钱？而用。NET呢？

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 10:35 PM liuruhong

java和.net各自有优势，下午我去Microsoft的时候，一个部门的产品经历还问我如何比较，哈哈，我居然说实话了，java确实不错，但是.net肯定不差了

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 10:42 PM 路过的人

没想到大家怎么激烈。呵呵，做技术的争论是不可避免的。
我第一个工作写C程序，用的开发机器是IBM SP2，跑AIX
，机器有4个节点16个CPU，数据库INFORMIX，中间件是
IBM CICS。（注：SP2就是当年宣传的更深的蓝）。我对
技术比较偏爱，那个时候没什么J2EE，JAVA只是刚开始。
不可否认我们对技术认识的层面还不深，我只是强调一句
存在就是合理。123456，做ERP也好，什么也好，现在强
调的是行业专家，计算机只是个实现手段。你说JAVA那么
好为什么WEBSPHERE还要有CTG？不如所有的应用一起做
了，还要调C函数做什么？国外公司在生产产品时候会注意
品牌，IBM整合了中间件，合称Websphere，BEA也进行了
整合叫Weblogic，其实是产品线。里面包含了很多技术。
技术讨论不追求偏激，需要开发性思维。人家一个学生兴
趣所至有个LINUX，SUN的几个工程师喝咖啡的时候给自己
的研究取名叫JAVA。其实很多人长期工作积累的结果，有
不足才有创新，都完美了要我们做什么？团队很重要，前面
有网友说谁谁是高手，高手我见的不多，老一辈的程序员
长期面向过程的思维方式让他们在面向对象方面显示出缺点
但新一代的程序在面向对象的思维方式下又忽略了底层。
有高手，我承认，不是我见的少是一个高手什么都做不出来
我们需要的是个团队。对团队的力量我想大家该思路一致吧
。一个团队里需要各种角色，还不是一个高手。
网友的评论中不缺少对技术精通的人，我们说开源，.net的
出现很好保护了代码，并且在dll的管理方面进行了改进。
这点我觉得好也不好，开源，你搞一堆人研究个东西全给
别人了，不开源，社会整体的技术水平无法提高。很矛盾的
东西。JBOSS人家开放了代码很好，问题是人家买的是文档。
你说你需要不需要？我们搞3000个高级别的程序员，做2到
3年，可以做出个操作系统，问题是这个费用谁出？国家都
没这个兴趣都靠志愿者？
如果有可能，不妨文章作者可以搞个项目组，大家都针对
.net和j2ee做出个开发平台。大家可以分组做些项目再
合并。成熟的产品不光可以用在自身的项目中，也可以为
为大家创造一个技术交流平台。有什么比做更加有说服力？
做出来，在同一个环境可以对比，再进行代码优化再对比。
呵呵，我是随便说说。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 11:14 PM liuruhong

to 路过的人

谢谢你的建议，有机会希望和你交流

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 11:42 PM dd

ddddddddd

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-14 11:55 PM qianbo

两到三年，是做不出操作系统的，请问各位能立刻写出神经网络架构和遗传算法么，各位能立刻用小波分析来分析大家的心理么（开个玩笑），又有多少个程序员懂的数学建模。
有个程序员有一天说，你懂得什么叫JOB,什么叫并发处理，什么叫事务回滚......（当然是数据库上的东西），然后就告诉我Oracle如何之好（因为她能处理这些），我Oracle 不熟，不过我知道她好，但是有一天客户说我们买不起，我们要用ACCESS,或者我们连ACCESS也不买，怎么办，你还怎样去处理这些问题，拿了别人的好工具来用，确认为自己在学技术，这一点是我们中国人的习惯，只不过我们在坐飞机，坐不同的飞机，但飞机决不是我们造的。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-15 12:09 AM 路过的人

做还是能做出来，我相信，不过要商品化可能还需要点
时间。qianbo你说的东西难度太大，就一遗传算法估计
能做出来的不多，你能写那我恭喜你可以买买了。有次
一个哥们说要给个制造厂做个软件，一个白铁皮任何分
隔才能使废料最小化。我回我们学校问了下，要遗传算
法，放弃，呵呵。虽然我学数学，但基本没这个功力。
我也坐飞机，一般我坐之前我都改装下。

# 深夜也能发现爱国人士 2004-10-15 2:45 AM 害怕，不敢具名

造工具的去中国科学院，用工具的去中国工程院，都是技术。有人提出遗传算法；有人把遗传算法用到最短路径计算，有人把遗传算法用到雷达数据提取，还有人把遗传算法应用到考古墓穴定位，不能说后三者不是技术吧……
什么都要分分进口国产～遗传算法也不是国人提出……“拿了别人的好工具来用，确认为自己在学技术”
买不了ACCESS就只好自己写文本文件嘛～记得使国标码——国产（笑）

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-15 8:16 AM 我也想说一下

这篇文章,写的确实不错.分析还是很公正的.大家的争论也是蛮好的.虽然很多人不同意"123456"观点.但是他讲得很多地方,确实是正确的.我现在在用友搞ERP开发(一般来说ERP可以称得上企业级应用程序了.),对应用程序开发接触多一点,目前用友搞两种方案.即.NET J2EE. 小型企业(一般用PC作服务器公司连线电脑2位数),且没有把老管理系统移植到新系统下.选择.NET的是推荐.但是一些企业比较大.并且有分厂还要考虑到把老系统移植过来的.并且还想调用以前服务器(一般不会是PC的),这样的情况我们推荐用J2EE.

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-15 8:26 AM to 深夜也能发现爱国人士

你说的也比较对，不过中国人的论文我看了不少，不管是什么中国科学院还是工程院还是什么大学，其中有不少优秀论文，我疑惑的是，有这么多，如此多，so 多的论文 还有什么优秀的什么"百篇优秀博士论文"之类的东西，为什么，为什么，为什么有这么多的，如此多，so多的优秀的人才，怎么也不见中国的起步，你懂的很多，告诉我

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-15 8:48 AM qianbo

有一天飞机从天上掉了下来，我却连降落伞也没有，并不是要分进口国产，余世维有一句话讲的好：中国人的硬件跟上了世界潮流，但是软件没有跟上（指的是中国人的思想），如果我们的基础素质没有达到要求，成天妄谈技术，跟随权威，怎么才能真正的进步。小弟没有别的意思，愿意奉献我的一生给中国软件。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-15 9:46 AM cgsw

真是池塘大了，什麼魚都有！寫文章隻是更好的了解技術，可以討論，但不極端。會傷合氣的。

# 回复：.NET重要技术思考——原文在《程序员》杂志第六期 2004-10-15 10:35 AM kiopl

又是java和.net的互相攀比
无聊
现在的瓶颈不在技术上，技术已经很全面了，瓶颈出在人上！！
中国很多大型的、全国化的、高度安全且机密的系统都是用vb、vfp、access、sybase这些老东西搞出来的，运行的好好的，且价值不菲，很多人鄙视吧？我以前也是。可是你想，企业公司或某个大的组织或集团，他们需要的是，比如：我们要实现实时通信，我要求一个报文要在1个工作日内被对方看到，而不仅仅是发过去存在服务器里，我要求公司工资的发放实现自动化，这些才是问题所在，你要做的是解决这些问题，而不是组建什么j2ee，弄几台服务器摆弄web service，你应该去找用于支付工资这个操作的银行代理接口，为管理层人员制定操作规范，教会它们如何有效使用系统，并且建立稳定高速且通讯加密的网络，而从编程技术上讲，用vb+sybase完全可以实现这些，你何必去用复杂、庞大、难以部署的java呢？何必去用效率低下的.net呢？他们真的能简化开发过程吗？他们有什么优点可以让我选择它们？组建一个J2EE真的有意义吗？建立我们自己的系统规则不是更容易掌握且合理吗？
做企业开发，不需要底层的东西，不要求高效率，多买10台服务器才几个钱？可请10个大师来定制软件要投资多少？且程序日后维护或升级、扩展要投资多少？
随便说个例子，告诉广大程序员或工程师们，不要沉迷于编程技术上，你是为了编程是为了解决问题，而不要把编程本身编程问题！