.net,follow microsoft~our big boss~:)

解决方案 »

  1.   

    java现在更流行,找工作也比较好找,工资也高...我也想现在转java...
      

  2.   

    呵呵!其实不管哪个东西!你只要学的精就有高薪。
    我原来也为这个问题困惑,但是我更看中。NET!
    可以说他很有潜力,而且以微软的一向作风,这个的推出是要打败JAVA,而且投资很大!
    所以我个人认为还是。NET
      

  3.   

    选.Net1.java至今还没有标准化,j2ee的规范太复杂了,不易于实现。
    2.j2ee与j2me和j2se间体系不一致,开发手机平台的和开发服务器以及桌面的不易互相移植。
    3.sun公司的其他部门对推广java没有热情!
    4.java至今没有太大改进,不关心程序员开发java太难了!1..Net已经被ECMA采纳为标准,正在被采纳为OSI标准。
       现在有一个开源项目叫Mono正在把.Net跨平台,项目进展顺利总体进度为80%,你可以上网站下载安装。不久将来.Net不但跨语言而且跨平台。
    2.开发手机业务与开发桌面是一致的。真正一次开发到处使用!
    3..net是微软业务基础,推广力度前所未有。
    4.vs.net开发方便,msdn好用
      

  4.   

    不同意 lins(*无间行者*) 我还是选择java
      

  5.   

    如果你还不是java高手,就选.net
      

  6.   

    浅析J2EE与.NET平台优劣
    --------------------------------------------------------------------------------作者:宋振宇 本文选自:赛迪网 2002年02月25日 毫无疑问,程序员,软件开发商,企业IT经理一直都在密切的关注着J2EE和.NET的发展,但是选择一个在性能,价格,时间上满足他们需求的平台却并不是一件简单的事情。本文试图在技术上做一个简单的比较,希望对于他们做选择时有所帮助。 一.技术概观 在表现形式上,J2EE是一组规范,而.NET更象是一组产品。但它们的目的都是为了企业应用提供分布式的,高可靠性的解决方案.它们在架构上有着很多的相似之处,下表是一个简单对照: J2EE .NET 
    通信协议 Remote Method Invocation over Internet InterOrb Protocol (RMI/IIOP),XML 
    编程语言 Java C#,VB.NET,COBOL 
    运行时环境 Java Virtual Machine (JVM) Common Language Runtime (CLR) 
    胖客户端 Java Swing Windows Forms 
    目录服务 Java Naming and Directory Interface (JNDI) Active Directory Services Interface (ADSI) 
    数据访问 Java Database Connection (JDBC) ,Java Connectors ADO.NET 
    异步消息处理 Java Message Service (JMS) Microsoft Message Queue 
    表示层技术 Servlets, Java Server Page(JSP) ASP.NET 
    中间层组件模型 EJB,JavaBean COM+,COM 
    安全访问 JAAS COM+ Security 
    Call Context 
    事物处理 Java Transaction Server (JTS) Microsoft Distributed Transaction Coordinator (MS-DTC) 
    开发工具 WebGain Visual Café 
    Borland JBuilder 
    IBM VisualAge 等 
    (第三方提供,规范本身没有定义) Visual Studio.NET 
    J2EE平台的构成 EJB - J2EE 中间层,完成商业逻辑; JAAS - J2EE 处理认证和授权的API; Java Connectors - J2EE 用于连接异种数据源的API,对上层来讲是透明的; JSP, Java Servlets - J2EE的表示层技术,用于生成用户界面; Java Virtual Machine - Java 语言运行环境; JDBC - J2EE数据库访问; JMS - J2EE的异步消息队列; JNDI - J2EE的名字查找API,独立于目录服务器; JTS - J2EE用于处理交易的API; RMI/IIOP - J2EE的分布式对象的通讯API,提供了和CORBA交互的能力。 .NET平台构成 .NET Framework - .NET应用运行的基础; IL (Intermediary Language) - 所有的.NET语言首先被编译成该中间语言,然后在CLR中运行; SOAP - 用于服务访问的工业标准; DCOM - 组件间通信协议; MS-DTC - 用来在.NET平台上使用两阶段提交协议来处理分布式交易; CLR - .NET应用的运行时环境; COM+ - .NET的中间层模型,用于构建商务逻辑; ADO.NET - .NET 对数据访问的API。 此外.NET平台还包括其他一些产品象Application Center Server,BizTalk Server ,NLBS (Network Load Balancing Service),Commerce Server,Enterprise Servers,HIS (Host Integration Server),ISAS (Internet Security and Acceleration Server)用来提供象防火墙,安全访问,B2B交易,负载平衡等服务.J2EE规范本身没有定义这些服务,但可通过选择第三方产品来满足类似的要求。 二.技术比较 1.一 vs 多 一种语言vs多种语言,一个平台vs多个平台.这似乎是大家最喜于津津乐道的话题,也似乎是所有问题的焦点。 两种平台主流的开发语言Java和C#在架构上有着惊人的相似:虚拟机技术,基于沙箱的安全模型,分层的命名空间,垃圾回收等。所以从第一眼看上去,C#简直就是Java的克隆。但微软并不这样认为,微软的说明是:“它集成了C++, Java,Modula 2,C和Smalltalk等多种语言的精华,对它们共同的核心思想象深度面向对象(deep object-orientation),对象简化 (object-simplification)等都一一做了参考。”一方面,C#的大多数关键字来源于C++,使它在书写上有别于Java。但另一方面,C#的严格的类型转换等概念却明显来自于Java(当然,它的原始类型的定义更严格,并且据微软声称没有影响到效率.),使其在内涵上有克隆之嫌.但即是Java,其有些特性也和Smalltalk颇有渊源.所以评价一种开发语言的优劣不仅是看其外在的表现形式,更重要的是其实实在在的功效.作为一种新语言,C#加入了基于XML的标记,可以被编译器用来直接生成文档,C#的另一个特点:一站式软件(one-stop-shopping software)强调了自解释( self-describing) 的编码方式,即头文件,IDL(Interface Definition Language),GUID和其他复杂的接口无需再被引用.也即是C#,VB.NET等代码片断可以任意的被加入到其他语言中.这无疑在多种语言混合编程的模式中是一次飞跃,但是,其难维护性也是不言而喻的。 微软的.NET的平台提供了象C#,VB.NET,COBOL等多种开发语言,C#是新的,而其他的每一种语言都是在原有的基础上改造而来.这是微软煞费苦心并且也是不得以的要为习惯于这些语言的程序员铺一条便捷之路.但是,这些语言的改造与其说是整容到不如说是一次开膛破肚的大手术.首先是观念变了,Basic,Cobol等语言先天的缺少面向对象的内涵,现在却变成了面向对象的语言,这就不是要求其传统的程序员仅仅熟悉一些额外的关键字那么简单的问题了.基于面向对象的软件分析设计开发测试是完全不同于基于传统过程性语言的质变,所以这一过程的转变对传统程序员来讲也是一个痛苦和漫长的过程.在传统程序员面前,微软看似提供了丰富多采的解决方法,但对于实际问题而言,却怕是有些力不从心.所以一个简单的办法是:直接使用C#.对于独立软件开发商来讲,其转换成本不容忽视.其次,在一个软件项目中使用多种语言,开发商必须同时拥有多种语言专家和多个独立的难以互相支援的开发小组,无疑的,这也使其软件的维护的成本已非线性的曲线增长.多样性是双韧剑,实施时需仔细斟酌. 跨平台是J2EE的最大卖点,也是至今为止还绊住微软的栅栏.当开发商完成了符合J2EE规范的软件时,其客户可以依据其喜好和实力来选择不同应用服务器.从基于open source的免费软件到高端满足B2B需求的商业套件来搭建自己的平台.但是由于J2EE的规范还不完善,各个J2EE服务器的提供商为了使其提供其各自理解的完整的功能,不得不添加一些额外的特性.这就使得使用了这些特别功能的应用软件,绑定到了特定的应用服务器上.随着J2EE规范的发展,这种差别会逐渐减小. 微软的跨平台解决方案是Web services,它解决的是异种平台上不同应用之间的连通性问题.从技术角度讲,它除了以XML为介质之外没有什么新意.但它的重要意义在于:它是微软这样一个重量级选手所推出的,前景不容小视.构造和使用 Web services 的过程较为简单: 服务提供者用他所选择的语言构造服务; 服务提供者用WSDL(the Web Services Description Language)来定义该服务; 服务提供者在UDDI (Universal Description, Discovery, and Integration )中注册该服务; 使用者的应用程序从 UDDI中查找已注册服务; 使用者的应用程序通过 SOAP (the Simple Object Access Protocol )来调用服务.(SOAP使用HTTP来传递基于XML为表现形式的参数) 正如我们所讨论的: Web services解决的是异构平台上服务连通性的问题,但在现实中所更迫切需要的是如何在异构的平台上构造具有可扩展性,高可靠性,高可用性,故障冗余,错误恢复能力的企业应用.缺少这一点,从结构上讲,.NET平台还远未完善. 2.中间层 基于组件的软件开发技术可以在较高的级别上实现软件复用,加快企业软件开发的进程.在J2EE构架中, JavaBean和EJB(Enterprise JavaBeans) 被用来完成事物逻辑.其中EJB和 JavaBean 有着类似的模型,但它被用来创建分布式的企业应用.它定义服务器端组件的模型,具有以下一些特性: 生存期模型; 访问模型; 安全模型; 事物处理模型; 会话处理模型; 数据封装模型; 部署模型 根据这些模型,简单的编码就可完成复杂的功能。 在微软的.NET平台中,旧的COM 和 COM+的组件模型被新的组件模型所代替。增加了象基于沙箱的安全模型和垃圾回收等功能.并且实现了多重接口继承,扩展的元数据和新的代理模型等.旧有的COM和COM+组件也可被映射到新的运行环境中。 综上所述,两众架构在基于组件的中间层的设计上各有千秋,对于创建分布式的,复杂的,高效的,高可靠性的的应用程序都有着足够的能力。 3.表示层 两种架构都同时支持胖客户端和瘦客户端.即C/S模式和B/S模式.对于C/S模式,J2EE提供了替代Java AWT的Java Swing,同时作为可视化组件的JavaBean也可用来构造系统。对于B/S结构的表示层,J2EE使用 servlet ,JSP(Java Server Page) ,HMTL,WML,XML等工具来实现。 微软的胖客户端技术则由 Windows Forms代替了MFC.它们起的作用相同,在结构上 Windows Forms 被插入到.NET的运行时框架(runtime framework)和组件模型 (component model)中.在瘦客户模型中, ASP.NET代替了旧有的ASP和 HMTL, WML ,XML作为表示层。在 ASP.NET 中,C#,VB.NET等语言的代码片断可被自由引用.ASP.NET 页面被首先转换成中介语言( Intermediary Language),然后再被 中介语言及时编译器(just-in-time IL compiler)编译,最后运行于公共语言运行环境中,并且 ASP.NET 提供了页面的缓冲,所以,其运行速度要远远快于ASP。 大体上,两种架构所使用的表示层的技术非常类似,虽在细节上各有所长,但总体功能当在伯仲之间。
      

  7.   

    4.数据访问 J2EE 和 .Net 已不同的形式支持数据的访问。JDBC和ADO一样和所连接的数据库无关,并且通过连接,命令语句和结果集来对数据进行操作.所以属于中间层次的 API.更高一级的数据封装和数据管理是通过实体EJB (entity EJB)来完成的.基于容器管理的实体EJB使开发更快捷,管理更方便.事实上,由于实体EJB的load()和store()方法的同步机制,将大大缓解因并发而使数据库产生的瓶颈.也可以采用不属于J2EE规范的第三方数据访问工具,象WebGain的 TopLink。 而微软的.NET的数据访问工具则由基于XML的ADO.NET代替了基于COM组件的ADO.任何以XML为输出的数据源都可以作为 ADO.NET 的数据源.相应的结果集升级为数据集 (DataSets),命令语句则升级为数据集命令(DataSetCommands).从形式来看,微软的ADO.NET更新潮和时髦一些,基于XML的特性使其可以处理极其丰富的数据源,并且,因其构架在HTTP协议之上,易于穿透防火墙,使沟通更为便利.但由于XML本身的基于标记的特性,很明显限制了在有超大数据量和有网络瓶颈的应用中的使用.而J2EE的数据访问规则则显得略有单薄,但同时却更简单,更有效.并且通过对应用程序有效的层次的设计,对于数据库和基于XML的数据源的访问,也是可以无缝的整合的。 三.整体评价 在微软还没有足以和Java平台相对抗的产品的时候,微软所乐于做是大声的宣传:"write once, debug everywhere"。而它的对手则更乐于这样评价它:"微软开始也喜欢Java,他们喜欢它的方式是让它死去,他们当然也憎恨它,他们甚至憎恨每一个以J开头的单词。"但是现在,形式不同了,微软有了足以自豪的.NET他们可以已他们自己所喜好的方式来对J2EE和.NET来做各种比较。最热闹的应该算是微软出示的第三方对.NET Pet Shop和J2EE的 Pet Store的综合比较了.有兴趣的读者可以到MSDN,www.onjava.com,IBM开发者原地等网站看到相关评论。 &bsp; J2EE .NET 
    易用性 ** *** 
    扩展能力 *** ** 
    多平台支持 **** * 
    多语言支持 * **** 
    可靠性 *** *** 
    性能 *** *** 
    可管理性 *** *** 
    重用性 **** ** 
    负载平衡 *** *** 
    开放标准 ***** * 
    就企业而言,内部众多系统的整合、系统的延展性、安全性是更需要注意的议题,而这些都是J2EE的优势,也是微软的不足处。 在效率方面,J2EE阵营主张通过硬件的效能增加来弥补软件的不足.开放标准,功能强大,易于移植这些都是J2EE的卖点。但让人奇怪的是IBM的WebSphere和BEA的WebLogic在J2EE市场占了大半壁江山,而作为规则制定者的SUN却在做壁上观。 微软确实提供了从桌面的办公软件,开发工具,到后台服务器数据库的全方位的产品。 但统一平台的使用者可能要牺牲跨平台的好处,并也有可能由此就被无穷无尽的锁定在微软的许可证的汪洋中.更简单,更快捷,更高效是微软的目标,随着时代的发展,我们也许会看到更完美的技术解决方案。
      

  8.   

    java已经走过了8个年头,.net才开始,要想和java抗衡,还要看M$.
    下面是我看到的一篇文章:
    Java大师:曾为C#语言辗转难眠 本站提供 [2002-01-24] Java发明人James Gosling表示微软虽然推出自家版本极力压制Java气焰,但他现在已经不会辗转反侧难以入眠了。 下一波Web服务软件开发之争由微软卯上Java原创公司SUN,以及Java的忠实支持者包括IBM、Oracle等。而微软想拿下这一仗主要靠的便是C#,这是一种类 Java语言,即将加入新版Visual Studio .Net软件开发工具程序中。 SUN副总裁Gosling并不看好C#,不过倒是承认包括他与SUN内部人员一开始得知微软要推出此一语言时还曾紧张过一阵子。 “我只能说,微软的模仿是对我们最好的赞美。”他表示。“但那些人(指微软)还是没搞清楚状况,因为他们所推出的类Java语言少了稳定性、生产力与安全性。” Gosling在接受CNET记者专访时详细剖析C#,论述Java备受欢迎的原因,并透露当“超级明星”的滋味。 为何你会认为微软的C#语言少了稳定性、生产力与安全性? 里面的漏洞太多了。由于他们在设计之初考虑到支持C与C++的问题,因此必须加入一组记忆模式作为可随时存取资料之用。这些漏洞就成了程序开发人员眼中, 安全性、稳定性与生产力问题的最大来源。所以他们一方面虽然模仿了Java,但另一方面却又加入了一些不太有用或根本就不该加的东西,因此整个看起来相当可 笑。 我们有阵子还为C#穷紧张一阵子,但后来就不这么觉得了。以微软的势力来说,C#再怎么说都是值得我们关切的,但我曾与程序开发商谈过,此事并没有引起很 大的回响,因此其媒体炒作性质其实大过实际应用。 Java开发的成长情形如何?目前仍是主要用在服务器端吗?个人计算机上的情况如何? 这是一体两面的事,两者很难区分,因为我们所建立的网络同时有许多事情相互沟通,并相互为用。例如有人开发了一款用在手机上的应用程序,其中一定有部分 跟服务器有关,这就比如有人问,你体内血液是流到左手臂还是右手臂,答案是两边都有。 无线技术目前已经是业界最热门的话题,但个人计算机方面也很强劲,我预测桌上型应用还是比无线应用方面多很多。许多人都在开发以Java为基础的内部应用软 件,这些多数是前端桌上型应用连结至后端服务器上,或者独立的应用程序。 其应用程度非常惊人,每年我都会想,今年应该会慢下来了,但Java的世界却不断加速前进,只要有数字系统,就会有人利用Java写出一些东西来。由于有这种 开发环境与工具,才会有我们现今从超级计算机到智能卡都能有统一的架构。 目前你在SUN内有什么新计划? Java是我十年前发明的东西,所以两年前我决定应该作点新的事情,因此我重回SUN研究实验室,目前正在进行一开发工具计划。业界开发IDE的人不多(整合开 发环境),IDE主要是针对低端开发者而设计,也就是不太会写程序语言的族群。这方面的首选工具是Emacs,我23年前也是开发出Emac的第一批人之一。但这套 工具目前还在使用,真是太可怕了,且内容变化不大,这对低端开发者是好事吗?我看不见得。 我们有套SUN买下的开发工具叫做NetBean,这是一套一开始便以架构(framework)为设计主体的工具,非常具有弹性,我们在一年半前释出源代码,目前我正在 帮NetBeans写一套plug-in。 IBM有一套开放源代码计划称为Eclipse,主要是整合所有Java开发工具,方便软件开发商可选择不同软件制造商的开发工具,组合成一套可运作的产品。几乎 所有程序工具制造商都已加入,独独SUN还没,IBM为此迭有怨言,这究竟是怎么回事? NetBeans与Eclipse性质非常接近,他们认为我们故意不加入,但其实对方根本没问过我们,是他们对外宣布后我们才知道有这回事,我们觉得很奇怪,Eclipse很 像是模仿我们的产品,市场活动手法也挺耐人寻味的。 你觉得两套开放源代码计划可整合在一起吗? 有可能。我相信应该会有人思考这方面的问题,目前很难预测未来会怎么发展,最重要的是双方必须有共同的API(应用程序接口)。过去一年半来我们一直在研究 API,若IBM愿意一起加入我们的开放源代码计划,一切就好办了。 微软在Web服务方面进展相快速,有人认为Java目前已呈现落后局面,因为Java Community Process今年才会提出Web服务标准。你觉得呢? 我们一直被问到进度落后的问题,我也一再表示过了,民主模式总是比独裁统治要费时些,这话一点也不夸张,Web服务最重要就是要讲求合作,因此若要建立一 套机票定位系统,你当然必须请Travelcity、Orbitz、Expedia等线上服务商一起来讨论,决定订票流程的XML规范,你当然也可自己写一套标准要求航空业者照办 ,但他们一定会很不乐意,我不认为这样会成功,因为Web服务说穿了就是厂商间的合作,因此采用民主过程会好些。 当我们邀请Visa、MasterCard、花旗银行与美国运通等加入自由联盟时(一起建立一套网络认证标准),一开始大家歧见必然很多,但大家都有同意的共识,每家厂 商都有自己的需求,但大家也必须合作才能获得最大的好处,因此他们作得相当好。 四年前我们采访你时,你曾说你每次出席研讨会时,总会有许多Java开发人员要求索取签名,现在还有这样的“盛况”吗?若是的话,现在还四处演讲Java的感 觉如何? 我觉得受宠若惊。去年圣诞节,有人要求我直接在他身上穿的衣服签名,有人拿麦克笔要我在他的笔记本电脑上签名,不过多数都是直接签在纸上。 我很乐意讲述Java,我内心深处仍自觉是工程师,因此若写出来的东西有人乐于使用,我会觉得很开心,但当我得到处开会演讲Java时,我就觉得有点无趣了。 有阵子我四处演讲是因为我罹患了“腕隧道症候群”,手腕关节红肿无法使用键盘,但两年前我动过一连串手术后,我又可以开始使用计算机工作了,因此现在日子 过得挺开心的。 ----------------- 
    来自 ZDNet.com.cn
      

  9.   

    Java与.NET都不错,有时间的话两者都学