在基于ASP前端的、具有良好结构的三层系统中，系统结构师已成功地将业务层和数据层分解到相应的COM组件中。这些系统可高效率地迁移，因为新的ASP.NET前端只需少量修改，即可调用这些组件。但假如你的ASP应用程序的结构不正确，ASP.NET将无法在迁移过程中提供多大帮助。
如果你的ASP应用程序具有正确的结构，那么选择两种策略之一，你既可重用COM组件，又可顺利进入.NET的世界。本文解释了这两种策略。
虽然ASP.NET应用程序可使用COM的“互操作”（Interoperability）层直接与COM层通信，但假如现有的COM层使用的是VB6业务组件，而且这些组件普遍使用了Variant数据类型，那么最终系统的效率将十分低下。
要创建高效和可重用的业务层，最佳的方式就是开发一系列强类型.NET组件，它们应包装了底层的VB6组件。然后，你的ASP.NET应用程序将调用这些适配器，后者又调用VB6组件，并将数据转换成强类型。采用这种方法，ASP.NET代码将实现完全的类型化。如果其他小组想在他们的ASP.NET应用程序中使用这些组件，就不必关心可能围绕COM
Interoperability层所产生的问题。
然后，你可开发一系列.NET业务组件，在保留相同的强类型接口的同时，不会对其他应用程序产生影响。完成后，就可将COM业务层彻底更换为一个基于.NET的业务层，不必等待一次完全的改写，就可着手重用它。
目前，基于COM的业务层所包装的业务过程可能具有不错的适用性，不值得对当前系统进行彻底改写。如果你选择基于Web服务的一种策略，并把Web服务作为内部或者外部的集成管道，那么最好用Web服务而不是.NET组件来包装你的COM组件。这样做还有另一个好处，也就是能将应用程序自然地分隔到物理层上（也就是运行Web服务的专用应用程序服务器），另外还可对其进行逻辑性分隔。
如果希望非Microsoft的系统也能访问新的业务组件，就应使用Web服务。但是，假如你完全依赖于Microsoft的产品，则应考虑用.NET Remoting来分隔物理层。考虑到这些目的，你可将Remoting视为.NET
DCOM。
Remoting明显快于Web服务，因为你可对封送格式进行更多的控制（例如选择SOAP或二进制格式），而且可以对一些通信设置进行优化。通过为客户做测试，我们发现采用TCP二进制Remoting后，相较于使用SOAP格式的标准Web服务，性能产生了200~300%的提升。惟一必须解决的问题是，如果通过Remoting来调用一个组件，就无法保持事务处理的完整性以及安全上下文。和前述的适配器策略一样，一旦你的Web服务或Remoting层已经就位，就可将COM组件更换为原生的.NET组件，以提高性能，同时避免对COM的依赖。
在.NET中可继续使用ADO，包括它的记录集。但是，最好尽快将ADO.NET当作自己首选的数据访问API。除了速度更快，而且对服务器内存的耗用更少之外，ADO.NET还提供了一个更可靠、定义得更好的断开数据策略。
以上因素的组合，允许你创建扩展性更好的系统，它消耗更少的数据库及服务器资源。相较于使用COM应用程序和ADO创建的系统，这些技术允许你创建一个更可靠的、基于.NET的系统。最开始，你应选用上述某种迁移策略，再将ADO.NET作为从COM到.NET的转换过程的一部分来使用，从而快速构建一个业务层。从业务和技术的角度看，它都会成为向.NET的转换过程的坚实基础。
