随着.NET的发布，开发者可以从COM的限制中解脱出来，编写.NET应用程序来解放公司的业务能力。在你向管理层兜售一个项目的时候这听起来很好，但是你要小心你所推销的东西。随着你更深入的了解.NET，你会发现为了让.NET应用程序能够正常工作，COM 架构的大部分东西仍然是需要的。



象大多数微软的产品一样，这是一把双韧剑。因为企业在过去的几年里已经在COM软件上投入了大量的资金，微软不能仅仅是发布一个.NET然后进行彻底的升级过程。（作为证明，你只需要看看将Windows 2000 和Windows XP 作为标准的企业桌面系统是多么的缓慢。）微软所作的就是在.NET软件包里捆进大量的COM功能，这些功能能够使基于微软平台的开发过程更加直观而高效。让我们看一些你在设计和开发应用程序的时候可能遇到的一些例子。


消息发送：CDO库和MSMQ

在你开发可伸缩的，异步的应用程序的时候，你可能会以使用一个已知的，通用的接口，比方SMTP邮件服务，开始进行工作。如果你察看.NET Framework，你会在System.Web.Mail命名空间里发现一整套邮件处理对象。但是当你使用这些对象开发程序的时候，你会发现System.Web.Mail 背地里仍然使用CDO/NT（Windows NT的电子邮件通用数据对象）而没有暴露所有的接口。



例如，如果你想使用一个SMTP事件，你不得不把它们写在脚本里或者是写成COM对象，因为没有.NET的接口可以使用。你在配置应用程序的时候要确保你已经在目标机器上安装和配置了活动数据对象（ADO）和CDO/NT。如果你没有，你的对象就不会工作因为CDO需要ADO来提取一些特定消息的数据。虽然你可以将SMTP 服务器对象指向一个SMTP服务器而不是缺省的IIS 5.x，你也不得不在使用另一个SMTP服务器的时候处理过程许可问题。总之，使用System.Web.Mail（至少在近期是这样）会需要你配置和支持一些现有的COM架构。



如果你希望从SMTP转移到消息队列以获得更多的可靠性和事务支持，那么你将有可能使用System.Messaging.MessageQueue命名空间带来的好处。这个命名空间提供了一些简单的对象调用来管理队列，但是象Mail 命名空间一样，它基本上是将调用绑定到底层的微软消息队列（MSMQ）COM架构上去。（我预计MSMQ以后的版本会是受限的.NET代码，因为这个技术是微软实现它的高度可伸缩的，异步计算环境概念的关键之一。）好消息是通过编程使用.NET对象，你将能够升级底层的MSMQ版本而不需要显著的改动现有代码。


数据访问

当你使用SQL Server和.NET开发新的应用程序的时候，你应该尽可能的使用System.Data.SQLClient命名空间（它与ADOClient是相对应的）。SQLClient驱动程序是完全的受限代码，它使用它自己的语言--表单化数据流（TDS）与SQL Server进行通讯。这使得它非常的高效而且完全的把应用程序绑定到了一个无连接的，异步的数据源上。如果你需要访问其它的数据库或者基于COM的SQL功能比方动态游标，那么你将不得不依靠ADOClient命名空间。这也需要你安装底层的COM库文件，而且你可以使用遗留的实用程序来管理它们。（有人甚至建议发布一个ODBCClient命名空间以支持所有的ODBC驱动程序来增强.NET的连接能力）。


这对于你来说意味着什么呢？

在设计一个新的系统的时候，不要假设你使用的所有.NET对象都在底层调用受限代码。你应该在开发工作开始以前确定所有依赖COM架构的地方。然后确保你的IT架构能够或者将要能够支持这些功能。如果不是这样，那么你可能需要重新设计你的应用程序或者察看一下有没有第三方的软件以原始方式实现.NET受限代码而不是自己动手来做或者是使用以前的COM 接口。