|
当前页面: JAVA 编程资料牛鼻论坛 → Java & J2SE 技术区→.net 和 java 的问题 |
.net 和 java 的问题
.net 和 java 的问题
学东西 总是很想学一门就很好 但是社会的竞争却不是这个样子
所以我很想知道 .net 和java
到底是学一门 还是两门都学？
主要的是在社会上 现在的公司都招牌那种人才 比如说 会.net 或者 会java 还是两门都会！
.net 和 java 的问题 相关
想学都学吧，其实说话还是NET要好一点
想学都学吧，其实说话还是NET要好一点
自从.NET问世以来，程序员都很关心的一个问题是「该学Java或.NET」。我也在挣扎，该「该继续Java的研究，或者该开始准备培养.NET的知识」。
最好是能两者兼顾，但是每个人的时间都很有限，想要兼顾两者，其实不太容易。投入在.NET的时间越多，所能花费在Java的时间自然就少了，反之亦然。在信息爆炸的时代，重要的不是信息的取得，而是信息的抉择。信息太多，时间太少，如果不能慎选适合的技术，只会平白浪费许多时间，斫丧自己的竞争力。
由于我喜新厌旧的个性使然，过去这两年半，我着实花了不少时间在.NET上，对于.NET的认识越来越深，也修正了对于.NET原先的一些误解，渐渐的认同.NET的许多技术理念。姑且不论我们对于微软是褒是贬，单纯就技术本身来看，.NET的确是很卓越的。
我并不是唯一一个这样想的人。以「Thinking in Java」等技术书籍广受欢迎的Bruce Eckel也是如此。他原本认为C#和.NET只是Java的模仿者，并无新意，但是在深入了解之后，才发现C#和.NET其实是改良版的Java，不管在各方面，都有比Java更突出之处。当我看到Bruce Eckel说出这样的话，我感觉他说出了我的心声。
都会有,但是两者都学是学不过来的,挑一个学好比较好,多不如精嘛
就我个人经验来说，分析一下个人的能力和爱好。主要是兴趣，喜欢那个就学那个，不要让公司左右你！他们今天要java的，或许明天就要.net 的了。关键的问题是要学精通！然后你就去选择公司。任何公司的老板都喜欢能为公司独当一面的高手。除非他们招学徒，而你也想做小工！
我们相信使用存储过程的.NET实现不但是一种比J2EE BMP模型更为高级的设计模式，而且还能提供比其更好的性能和扩展性。该应用程序的两个版本的基准数据证实了这一点。J2EE中的任何一层不依赖于特定的产品，所以不用存储过程，并不是因为设计模式。
基于J2EE的解决方案要引入这些特性是轻而易举的，至少我在Java项目中也使用Cache和XML Web Service，并不觉得扩展很麻烦，相反我可以自己组态，深入事务内部。而且EJB2.0中大大提高了CMP应用场合的兼容性，这可是.Net尚不具备的（ASP.Net服务器控件中还没有类似的功能）
下面稍微比较一下两种解决方案：（以下纯属个人观点）
性能方面：
最终用户衡量的唯一标准：
性能瓶颈主要在中间层以下：EJB1.0或EJB1.1的效率确实不怎么样，不如轻量级的解决方案性能来得好，比如：硬编码直接访问数据库，对象关系映射，采用存储过程封装商业逻辑，采用对象库存储。特别是BMP管理起来代码文件特别多，发生业务变更时更需要重新配置服务器，影响了业务的连续性，但.Net 的解决方案也不见得好啊！
页面缓存和对象缓存：J2EE没有相应的标准，但某些应用服务器扩展提供了相应的标准，用法不一，提供的功能也不相同。
开发效率方面：
对我们来说选择开发工具的最需要衡量的就是这一因素：
表现层开发：J2EE这方面非常欠缺，把这一任务丢给了应用服务器厂商和编程人员，不象.Net拥有很牛的.Net Studio，不过Jbuilder 6已经出来了，支持EJB2.0 也不算太落后，但一直没有解决方案的就是页面用户控件（当然Turbine的Action Event也算一种），缺乏可视化设计和Servlet应用程序框架生成。我期望的一种方式是具有象.Net Studio一样的可以所见即所得的编辑模板(Template)，绑定用户按钮事件处理。目前可以通过javascript库，模板库及宏库略微缓解一下Servlet的开发。ASP .Net和Servlet都支持动态更新表现层。
商业逻辑层开发：
在这层的工作应成为高级程序员的重点而且应作为公司财产保护起来，大家的精力主要是要维护起公司商业库的升级和功能扩展，并进行良好的配置管理（应采用ClearCase，CVS对库的管理能力太差啦！）。
配置及发布：
发布和配置应完全独立开来，所有的配置项都应该可调（路径，数据库连接，EJB描述文件等），很可能正式发布的数据库表名，字段定义并不和开发人员的一致（如果开发产品的话，这点很重要！)
.Net只能通过存储过程方式来提供所谓的解决方案，而J2EE这方面做得非常全面，如果商业库是符合发布迁移规范的，系统管理员完全可以做到任何细节可控。这一过程需要商业逻辑层开发人员的努力。
XML支持能力：
.Net一直叫嚣的就是我集成了XML和Web Service，但JDK1.4也搞出了XML规范，这方面已经差不多了，不过.Net的易用性好得很，而且就此一家，程序员不必费心思选组件或产品。
在采用XML和XSLT的开发模式中：微软的SQL Server 2000直接提供了HTTP Query到XML数据的功能，不过我用dbxml也能做得这一点嘛，还适用于大多数的主流RDBMS，更牛！这种开发模式应该是未来的方向。
分布式组件，消息服务和事务服务支持等方面：
我的经验不足还不能评价。
.Net用COM，DCOM，MSMQ和MTS
J2EE用EJB,JMS和JTS
安全性方面：
通过网页授权方式：
.Net支持的验证方式：Windows, Forms, Passport,None
Servlet支持通过扩展也能支持这些，而且通过丰富的加密算法（例如AES)也很容易集成到自己的解决方案中
Passport足以显示微软的野心，不过其安全性有漏洞。
.NET和J2EE该相互学习什么
技术之间是相通的，精于触类旁通，善于联想是我们程序员应有的优势。我们在专注.NET技术的时候，不妨在工作间隙休息的时候看看. NET外面的世界。
提到.NET和J2EE，一般都会想到它们之间兵戎相见，水火不容的关系，毕竟两者都在努力地去虏获程序员的青睐，占领更多的市场份额。我无意去鼓吹.NET是如何如何之强大，J2EE是如何如何的成熟，也无意去探究NHibernate，Spring.NET等等Project的起源，只想从一个程序员的角度去看待两者在互相竞争的过程当中到底相互借鉴了什么，同时探讨一下同时了解两个领域知识的必要性。
第一次接触到ASP.NET的时候，第一个感觉就是，它比ASP好多了，再也不用像写ASP那样在HTML嵌套着一堆堆的Scriptlet，动态内容的呈现都包含在一个个方法中，如Page.OnInit()和Page.OnLoad()等等，这些方法中有Client端JS方法的影子。在开发ASP.NET页面的过程中，需要做的就是在页面中引入不同的Web Control或者是HTML Control，这些Controls与HTML标签是何等的类似，除了它有ASP的prefix和那时看起来如Magic一般的runat="server"。这样的相似性让熟悉HTML和JS的人很快能掌握ASP.NET的基本应用，ASP.NET所带来的进步是革命性的，难怪有朋友认为ASP.NET是.NET家族中最为成功的产品了。如果只是拿ASP.NET来跟ASP作对比，其优越性自然显露无遗，尤其是在控件设计方面的优势。事实上与J2EE的开发相比，ASP.NET的开发方式仍然有很大优势。Microsoft在技术的创新上一直秉持削弱领域开发特性的原则，让开发人员能够在不同的开发领域中都可以轻松上手，游刃有余。ASP.NET的出现带来了WebForm，而在桌面程序开发中则有WinForm，两者相通的地方随处可见，这让原有的桌面程序开发人员可以平滑的过渡到Web Application开发中来；ASP.NET对于控件在设计以及使用上的支持堪称完美，也为网页设计人员进入ASP.NET开发领域扫除了不少的障碍。反观J2EE领域，做Swing开发的人员，如果要学习Web的开发，原有的知识几乎无用武之地了。在这个人气就是财富的年代，在一定层面上求同存异，让开发人员能够一通百通，无疑是一个十分明智的做法。J2EE领域也开始意识到了这一点，将Swing概念应用到Web开发的Wicket Framwork的发布着实是一个极大的进步啊。J2EE在降低Web开发的难度，吸引入门级开发人员方面需要向.NET好好请教一番了。
在这个技术如此Open的年代，.NET的程序员应该去了解J2EE，反之亦然。我想，相互学习，共同进步最好。