吴江波

#

Java与.NET的比较

Java与.NET的比较

最好是能两者兼顾，但是每个人的时间都很有限，想要兼顾两者，其实不太容易。投入在 .NET 的时间越多，所能花费在 java 的时间自然就少了，反之亦然。在信息爆炸的时代，重要的不是信息的取得，而是信息的抉择。信息太多，时间太少，如果不能慎选适合的技术，只会平白浪费许多时间，斲丧自己的竞争力。

「 Thinking in java 」等技术书籍广受欢迎的 Bruce Eckel 原本认为 C# 和 .NET 只是 java 的模仿者，并无新意，但是在深入了解之后，才发现 C# 和 .NET 其实是改良版的 java ，不管在各方面，都有比 java 更突出之处。

下面，我试图从许多不同的角度，简单地比较 java 和 .NET 。

从技术的观点

通常新的技术会比旧技术更好，因为新技术可以从旧技术学到优点，且新技术可以摒除旧技术的缺点。 NET 比 java 诞生的时间晚了六年，许多方面都比 java 先进，当然是无庸置疑。

我的意思并不是 java 这六年停滞不前，事实上， java 一直在进步中，只是有许多缝缝补补、修修改改的地方。例如， XML 是在这六年之间出现的技术，所以 .NET 对于 XML 的整合可以说是天衣无缝，但 java 是后来才把 XML 整合进来，且整合的程度比不上 .NET 。

从历史的观点

以史为镜，可以知兴替。如果你了解近二十年的软件产业发展史，你会发现微软挫败的机会很小，即使是在头几场战役失败，也会在整场战争中获胜。换句话说， .NET 挫败的机会不大。在 Office 软件大战中， WordPerfect 、 Ami Pro 、 Lotus 123 如今安在？在操作系统大战中， OS/2 也已经销声匿迹。在浏览器大战中， Navigator 如今只整剩下小小的疆土。你一定可以举出更多这样的例子。

从市调的观点

分析机构如 Meta Group 和 IDC 皆预测，在 Windows Server 2003 推出之后，未来几年市占率会大幅提高。我认为，在 longhorn 推出之后（ 2006 年？）， PC 更是会全面 .NET 化。由于「精通」 .NET 知识可能需要费时两三年以上，技术人员应该尽量提早学习 .NET 以为因应。

三年前（ 2000 年）学习 .NET 恐怕有点太早，三年后（ 2006 年）学习 .NET 恐怕有点太晚，而现在学习 .NET 正是时候，不会太早，也不会太晚。学会之后，可以立刻投入市场对于 .NET 技术的人力需求。

从营销的观点

任何人都不能否定微软营销功力的厉害。平面的营销，包括在电子时报、 IT Home 等信息媒体，甚至连商业周刊等非信息媒体，都看得到相关的广告。动态的营销，包括 PDC 、 TechEd. 、修练讲座、产品发表会 … 等活动，直接走入人群，接触客户。电子的营销，包括 MSDN 中英文网站、微软 TechNet Flash 新闻信 … 等，提供技术新知。

另外，还有多得拿不完的教学光盘，读不完的在线文件，看不完的 Microsoft Press 出版品 … 。我发现，微软的作法和另一家公司的作法大相径庭。微软给我们一堆技术信息，要什么有什么，但另一家公司却常常把信息当成「传家宝」，舍不得释放出来给大众，连透过内部管道都还不见得拿得到，「好像很不希望有人学习他们正大力推广的技术」。

从销售指标的观点

关于某个城市的消费者物价指数，麦香堡指标（ BigMac Index ）是一个很有名也很简易的评估指标。我也发明了一个类似的指标，称为天珑指标（ TenLong Index ），可以用来评估 IT 技术的热门程度。天珑书局是台湾最大的 IT 图书门市，它的技术书籍销售量，对于判断技术的热门程度，有一定程度的参考价值。

2002 年全年和 2003 年上半年，天珑书局在 .NET 书籍的销售量都不高，但是在 2003 年下半年之后， .NET 书籍已经有相当不错的表现，这意味着最近准备采用 .NET 技术的公司已经增加了。

我记得在 java 推广初期，由于大家对于 java 认知不够，所以对于 java 有许多 FUD 存在。现在微软在推广 .NET 上，也遭遇到许多 FUD ，这是微软目前必须极力消除的障碍。如果你对于 .NET 也存有这些 FUD ，你不妨尝试着去破除这些 FUD ，就如同七八年前破除 java 的 FUD 一样。你将会发现，就目前来说， .NET 是一个非常有潜力的技术，值得投入

posted @ 2008-08-26 14:47 吴江波 阅读(101) | 评论 (0) | 编辑 收藏

ADO.NET：通向未来之桥

ADO.NET：通向未来之桥

在Web跨入编程时代之前，对于大多数IT管理者和顾问来说，数据访问只是一个相对而言的问题；所有要用到的数据都必须自己准备好。人们主要关心的问题是选择性能/价格比最好的数据库服务器，系统涉及的所有模块必须和服务器兼容。客户机/服务器应用是这种两层模型最典型的范例。

　　随着Web交互性的日益提高和应用的日益广泛，对于第三层――中间层的需求也越来越突出。中间层是一个逻辑层，数据访问组件通常就在这一层上。数据访问组件是唯一有必要了解数据库细节的代码，同时，准备更换或者升级数据库服务器时，数据访问组件也是第一个需要修改的地方。

　　接下来，三层系统模型发展成了Windows DNA――现在称为Microsoft .NET服务器系统。Microsoft利用一个统一的模型进行数据访问。这个模型注重的是内容，而不是数据格式和存储媒介。它的具体表达方式建立在UDA（Universal Data Access，通用数据访问）的基础之上，而UDA正是激励OLE DB体系发展的深层理念。为了提供一种通过VB和ASP COM组件方便地、无缝地访问OLE DB功能的途径，Microsoft设计了ADO。ADO 2.0是用来支持OLE DB的第一个版本。在几年之内，ADO发展到了2.6版本，增加和扩展了XML支持，使得经过扩展的ADO对象模型能够匹配所有OLE DB改进功能（例如，对于OLE DB新增的Row和Stream对象，ADO 2.5提供了类似的ADO配套功能）。

　　一、ADO 2.0的核心功能超越了OLE DB

　　在多层系统中，随着中间层组件的出现，如何为表现层提供最新数据这一问题也随之出现。表现层怎样访问数据？连接怎样打开？或者，我们是否应该维护一份脱机记录（即，一些断开连接之后仍旧能够在表现层使用的数据库记录）？ADO 2.0以及它的更高版本同时提供了对服务器端游标和脱机记录集的支持（脱机记录集是一种COM对象，它可以跨越网络串行化，客户可以下载它然后脱机使用）。

　　服务器端游标代表着一个紧密结合的、保持连接的环境，在这个环境中我们总是维持着各个层之间的有效通道，只有结束时才拆除连接。与此相反，脱机记录集是一个有状态的对象，我们可以把它作为一个整体处理，且不必维持连接。脱机记录集使用客户端的静态游标，能够提供一个数据源的快照。对于那些只有读取要求、且需要在各个系统层之间移动数据的应用程序来说，脱机记录集是很理想的。今天，大多数Web应用程序要求在各个层之间传输数据。为了获取这些数据，我们经常使用快速的“只能向前”游标，用XML编码数据，然后通过网络发送数据，避免了在Web服务器上维持会话状态信息。在分布式环境中，数据库连接是一种关键性的资源，以脱机方式工作保证了高可伸缩性。

　　然而，Web是一把双刃剑。Web让我们连接到任何类型的联机服务，而且能够与它们进行交互。但是，Web也要求一定程度的互操作性，因为操作所涉及的各个服务可能运行在不同的软件和硬件平台上。我们可以通过利用开放的标准，以及那些不注重私有权的技术――甚至是象COM+这类广泛应用的私有技术，跨越不同的平台。

　　今天，基于Windows的Web数据访问应用程序利用了ADO丰富的、方便的编程接口。然而，ADO对象天生地定位在Windows平台上。ADO基于COM的本性使得记录集很难在一个分布式、异种平台构成的环境中使用。另外，即使目标平台可能允许我们使用ADO记录集，它也不具备最有效的机制。ADO.NET的DataSet和DataReader更有效；而且，如果没有ADO.NET，有些时候我们还可以借助XML或纯文本获得高效率。

　　为了在Web环境下传输数据，Microsoft对ADO记录集进行了优化。但COM类型转换仍旧是一个必不可少的步骤，因为COM的数据类型不可能总是匹配ADO记录集的数据类型（例如，String类型必须转换成BSTR类型）。由此，许多人把XML当成了粘合各个层的“万能胶水”――不管涉及到了哪些平台。通常的做法是：先提取一个记录集，把它保存为XML格式，然后传输结果数据流，让接收者从这个XML数据流重新构造出记录集供以后使用。随着对协同工作能力和可伸缩性要求的提高，ADO不再是最理想的答案，因为它不是建立在XML的基础上――但ADO.NET是。

　　二、ADO在Web环境中的不足

　　.NET框架创立了一种取代COM和COM+的新组件模型。.NET的提出是Microsoft成熟的组件技术的新战略。虽然几个关键性的COM特色不再在.NET中出现，但在某些方面，.NET与COM编程仍旧很相似。因此，COM程序员将能够方便地转向.NET开发。ADO.NET是Microsoft特别为.NET框架设计的数据访问层，它在很大程度上利用了.NET的优势。

　　为什么.NET必须用一个新的数据访问层来替代现有的、广泛应用的数据访问接口，比如ADO？现代Web应用系统必须具备客户机/服务器应用和桌面应用的交互能力，Microsoft设计.NET的目标正是为了迎接设计现代Web应用系统的挑战。同时，.NET也利用了各种Web协议广泛的、强大的连接能力和协同操作能力。

　　在非Windows平台上，ADO记录集不能直接使用，从而使得协同操作能力受到了限制。为了突破这个限制，我们要把记录集转换成XML格式，然后传输转换得到的XML记录集。在ADO.NET中，把数据转换成XML以及通过网络传输的操作得到了简化和优化。另外，ADO对象模型中的每一个地方都体现了以数据库为中心的思想。ADO把数据看成是一组来自数据源的记录，而不是把数据看成一些独立的信息。在ADO中，如果脱离了数据提供者用来保存和描述数据的结构，数据将不能独立存在。

　　三、ADO.NET数据集和ADO记录集

　　ADO.NET是从Web的角度对ADO进行检讨和改进。Microsoft对ADO.NET的设计严格地体现了其名字的含义：ADO，再加上.NET。ADO.NET自动连接网络，致力于让Web数据访问变得更加简单和高效。两个功能使得这方面的增强成为可能：脱机记录集，以及与生俱来的对XML的支持。由于采用了脱机记录集方案，ADO.NET自然也就不再支持服务器端游标。ADO.NET天生就把记录数据保存为XML文档，把模式（Schema）和数据视为分离的、可替换的元素。

　　如果你认为ADO早就提供了这些功能，它们并没有什么创新意义，那么，ADO.NET还提供了其他许多新的功能。ADO.NET能够使用连接的或者非连接的（脱机的）记录集，具体由用户选择的游标类型和游标位置决定。ADO记录集的本地存储格式是ADTG文件格式（Advanced Data TableGram，高级数据表图）。ADTG是一种Microsoft私有的二进制存储模式，代表着记录集在内存中的映像。XML是可替换使用的、确定的、详细输出格式。在ADO.NET中，我们可以断开一个记录集集合的连接，通过一个默认（但允许更改）的XML模式再现记录集集合。

　　在ADO.NET对象模型中，DataSet（数据集）是最重要的对象。一般地，一个DataSet对象就是一个记录集的集合。ADO.NET框架提供了记录集的所有数据库功能：排序，分页，过滤视图，关系，索引，和主键。

　　DataSet对象代表了一个在内存中的、有着丰富功能的数据缓冲区。DataSet对象也通过表组织数据，这些表与原始的数据源之间不存在连接。我们可以添加表，表可以通过读取本地或远程XML文件获得，或者也可以从任何可访问的系统资源（包括内存和其他附属设备在内）读取。我们可以排序、索引、过滤数据表，象处理ADO的Recordset一样导航数据表。

　　我们可以通过命令用数据集合填充DataSet对象。如果用.NET集合的形式为DataSet对象提供数据表（具有集合功能的.NET数据类型是ICollection），同一个DataSet对象能够服务来自多个连接的多个请求。ADO.NET的DataSet对象比ADO的Recordset更一般化；与ADO的Recordset不同，它是对数据源的一种抽象。然而，DataSet对象保留了一个在内存中工作的数据存储器；它没有完全淘汰记录集功能。如果我们只需要一次性地滚动记录集，然后生成某种输出，那么，我们应该使用DataReader对象。.NET的DataReader对象类似于“只能向前、只读”的记录集，但它是一个高度专用化的对象，所以无论在体积和开销上它都要比记录集小。事实上，记录集能够执行许多不同的任务，是一个相当臃肿的对象。与ADO的Recordset相比，DataReader不包含进行“家务管理”的代码，除了实现功能所必需的代码之外，它不包含任何其他代码。

　　把多个表作为一个整体管理以及允许建立这些表之间的关系，这是ADO.NET的新功能。我们可以用XML形式持久化或传输任何DataSet对象，而且无需付出任何额外的代价，因为DataSet对象本身就是按照XML格式构造。因此，除非要修改底层模式，否则，我们无需为了获得一个XML流而去转换DataSet对象的任意一个部分。

　　四、ADO.NET对象详解

　　ADO和ADO.NET有着两个截然不同的对象模型：ADO定位在基于Windows 2000和NT的服务器平台；ADO.NET定位在支持.NET的平台。Microsoft预期在2001年末推出第一个.NET OS――Windows XP（原来的代码名字为Whistler）。不过，它的后继产品（代码名字为Blackcomb）更有可能提供一个全功能的.NET OS。

　　如果要迁移代码，我们可以把现有的ADO代码导入到.NET应用之中，从而节省在编写代码方面的投入。然而，如果不做重大的设计调整，同样的代码几乎不可能移植到ADO.NET。ADO和ADO.NET的对象模型不一样，两者在不同的设计指导思想下完成。

　　ADO.NET只用来构造基于.NET服务器的Web应用。ADO.NET是.NET应用程序的数据访问API。因此，只有把服务器升级到.NET之后，你才可以考虑ADO.NET。在同一个应用程序中，让ADO和ADO.NET协同运作是没有什么意义的。虽然你可以同时使用这两者（至少从设计的角度来看），但这并不是一种好的选择。

　　ADO.NET的对象主要包括：DataSet，DataTable，DataColumn，DataRow，和DataRelation。这些对象的主要特点说明如下。

posted @ 2008-08-13 09:53 吴江波 阅读(117) | 评论 (0) | 编辑 收藏

仅列出标题
共3页: 1 2 3