移植到ADO.NET的最佳时机

　　开发人员经常收到的潜在经消息是，"不要在数据库上浪费时间，我们已经雇佣了很多的数据库管理员。集中精力开发组件。"但当采取具体挫施去提高性能，扩展性和交互操作性时，首先要考虑的事情是数据访问层。

　　因此，我每月两次深入这个复杂的问题。下面从热门话题：ADO .NET的出现（如果会改变，它）将如何改变你的生活，开始讨论。

　　好的和坏的

　　在ADO .NET中有好的和较好的东西，在本专栏我将探究、调查这些问题。同时，有一个故事可以证明我的观点：

　　一个IT经理去世了，并敲了天堂的门。登录后他要做出一困难的选择：地狱或天堂。在他做出最终决定前，他商量并试图一天在地狱一天在天堂。

　　在地狱中，他遇到了很多已经过世的同事和朋友。他们打高尔夫球，在很好的饭店吃饭，晚上从一个宴会转到另一个宴会。从个人角度讲，魔鬼看上去象易于相处、很好的人。不太坏，他这样想。

　　在天堂中，他享受了天堂的音乐，与天使一起飞翔，从一朵云飞到另一朵云，然后放松。太令人厌烦了，他想

　　总之，他推算在地狱中有较多的享受时间。因此它要求去地狱，然后乘电梯去了。但电梯打开时，他看到了真实的地狱。魔鬼的面孔和行为比期望的更不可靠。

　　"为什么突然变了呢？"，IT经理问。魔鬼回答说，"昨天我们雇佣你，而今天你是我们中的一分子。"

　　Is there an ADO .NET lesson we can learn from this?

　　这就是我们从ADO .NET得到教训吗？

　　ADO .NET既不是天堂也不是地狱。如果你从事一个错误的项目或以错误的实现项目，那么今天看上去象天堂很快会成为一个恶梦。当然，反之亦然。

　　作为一个IT经理，一个主要的开发者，或者是一个经常低估数据访问的人，不要让表象迷惑你。多花一些时间考虑与你项目相关的由ADO .NET带来的好处和问题。

　　至于与其它新技术相比，ADO .NET经常被认为是改变甚至是挽救世界的方式。过去，我们认为ODBC是一种革新，RDO是一大进步，而认为ADO是简化但加强数据访问进化过程中的最后一个阶段。在这点上，ADO .NET可以合理地被认为是你经过了无数次升级后的数据访问层，因为它遵循了事物的本性。

　　移植到ADO .NET并不是很轻松的一步；这是 .NET Framework完整而一致的组件。你不必为你的数据访问需求选择ADO .NET。相反，你应选择.NET作为平台，为数据处理代码使用ADO .NET。

　　等待移植的正确时机

　　季节交替时总是移植的好时机。这适用于信息系统和鸟类。然而鸟类内置的机制会告诉它何时应飞向更温暖的平台。不幸的是，信息系统和Web应用程序不会出现这种情况。

　　我认为没有正确的移植时间。并且这种时间存在，它也不能通过算法计算出来。不要急着移动现在运行得足够快的代码，至少要实现大部分的客户期望。

　　另一方面，你可以为.NET作准备。当决定要升级时，考虑你得到了什么，又失去了什么。对.NET，忘记估算升级所花的时间，此代价你负担不起。数据访问只是信息系统的一个方面--但它也是全世界所有应用程序都具有的一个方面。

　　尽早移植有好多原因，但等待也有好多原因。在每种情况下，重要的是你需要尽可能多得全面学习.NET，专门学习数据访问。

　　数据访问对任何现实的应用程序来说都是至关重要的。而且，数据访问在.NET中并不是严格向后兼容的。例如，将现在动态服务器主页转换到ASP.NET页相对容易。改变过程只需要很小变化就可使它工作。（如果你使用服务器端的Jscript，那么你会看到性能有很大改进，发生此情况的原因是JScript.NET option（fast）开关。）然而，现有ADO代码很难变为ADO .NET代码。它只能转换为工作在.NET应用程序上下文中的ADO代码。

　　实世界应用程序使用COM组件。它们依靠数据提供者工作，直接向ASP的输出流中写数据，或通过记录集或XML字符串返回数据。这些代码不需要太大努力就可改编到.NET环境下。导入组件的类型库就足够了，由于.NET通常提供的COM交互操作桥，所以它仍能继续工作。

　　这种方式移植有意义吗？为了充分利用.NET，你必须理解它的内部结构，接受新的思维方式。实际上，.NET思维方式与众所周知的COM方式没有多大不同，尽管它要求你遵循不同的规则管理不同的对象，对它们进行考虑。

　　对总的.NET和特殊的ADO .NET，你的位置在哪儿呢？下面是我的三步指导：

　　1.忘记ADO对象。
　　2.使用ADO .NET哲学和对象重新考虑并重写你的代码。
　　3.根据你先前的ADO经验，精练、优化代码

　　换句话说，忘掉ADO和OLE DB编码的细节，但保留、重估计经过很长时间学到的在它们背后的概念。从ADO .NET角度重新对他们进行考查。你将发现ADO .NET天然是第一流的，一致的，比ADO更通用。它象OLE DB那样灵活，但再在限于专家和相当聪明的C++开发人员。你会发现ADO .NET比OLE DB更简单，同时更具专业性。

　　花一些时间理解ADO .NET。将它与ADO进行比较，看看在你特定的上下文中你如何修改、改进你的程序。

　　移植的原因

　　移植到ADO .NET和ASP .NET最引人注目的原因是性能，对开发和维护的简化。ASP .NET和ADO .NET利用了一些通用的最优秀的实践，并将它们集成到完全封装的、一致的框架中。

　　当重写Web应用程序时，很快你会意识到有一个组件可以做到你在寻求的东西。你可以得到一个作为服务运行的会话管理器，它在Internet信息服务崩溃时仍能运行。你还有一个包含了多个记录表的对象。无需惊奇，你可以在ASP .NET会话对象中存储对象。你可以使用你自己的存储过程对任何数据提供者进行批更新。你拥有一个可立即使用的数据网格组件，它也是可高度定置的。在将记录集转换为XML时你感觉不到任何困难。你可以随意改变XML结构。你可以选择比较喜欢的导航模型在记录间浏览。

　　任何你能考虑的层次上（表示层，中间层或数据访问）为.NET进行开发是比较容易的。而且ADO .NET为你提供了一组对象，不管目标编程模型是什么：Windows 窗体, Web 窗体, Web服务，这组件对象总是不变的。只要在后端有一个数据源，ADO .NET就能提供同样的帮助。

　　转向ADO .NET还意味着你可以不去考虑ADO 与OLE DB组件间的二元性。现在，只有在C++中才有可能直接调用OLE DB。它们速度快，但太容易出错了。它们需要特殊的技巧，但并不是所有的开发团队都有。另一方面，ADO是专为ASP和VB开发人员设计的，它提供了很多C++程序员也欢迎的便利功能。

　　ADO .NET利用宿主框架的语言中立性结束了这种二元性。不论语言如何，也不论编程模型如何，它都交付了同样的便利功能。

　　等待的原因

　　我先前提到过，转移到ADO .NET并不是一步就可实现的过程。没有哲中的挫施。或者你将系统保留原样，或者你从头考虑，制定中期或长期的移植计划。

　　你必须重新设计核心的数据访问功能，以利用ADO .NET提供的新特性和新对象。

　　在研究.NET时，你是否拥有维护系统当前版本的资源？在着手考虑核心系统前，你应当具有开发一个项目的经验。如果轻易地接受 .NET的挑战，你的风险将远超出你的预算。

　　在ADO .NET项目中，你要考虑在数据库，SQL和ADO方面的技巧，并将它们与构建在ADO .NET中的新对象模型和新策略进行比较。你可以在对问题的理解和你特定上下文的数据访问策略上进行构建。你可以使用ADO和OLE DB高层次的知识。如果要通过网络工作，你就要依靠你的IIS和ASP经验。