Windows DNA到.NET移植的思考

当然，我们都知道最后一类囊括了很多子类型，包括简单的Web应用程序、C/S应用程序以及用三层实现的应用程序。当评估使用Windows DNA工具套件开发的两层或多层应用程序时，做一些有关你怎样将这些系统移植到.NET的一些基本假设是很有帮助的。然后你就可以估计那些应用程序看哪一类最适合移植。

核心假设

对于移植一个现有的Windows DNA应用程序到.NET中，可能唯一要做的最重要的假设是你将要采用XML Web Services，XML Web Services是为处理一些像执行时间、异步、安全以及与其它平台的互操作性等问题而设计的。当开发互联网级的应用程序时，这些问题给Windows DNA系统的设计者带来了最多的困难。

第二个核心假设涉及到状态管理。对于大型应用程序的设计，维持任意两个物理层的状态信息的需求应该尽可能地少。换句话说，最好能使用一个与表示层存在于同一物理机器的表示面来维持表示层的状态信息。最好不要在商业层或者数据库层维持表示层的信息，因为很可能表示这些层的对象与表示层不在同一台机器上。

如果你可以使用内在的无状态XML Web Services范式来移植现有的Windows DNA应用程序的对象，可能你就可以在一个无状态的环境中将应用程序的其它部分正确地升级为函数。确定一个Windows DNA应用程序是否适合移植到.NET中的第一步是简单地决定这个应用程序是否需要XML Web Services和无状态结构的优点。如果不需要，那么该系统可以继续运行在当前的环境下，直到其不再需要或者由于商业原因需要而被替换。这里需要考虑的主要结构问题是Windows DNA应用程序现有的对象模型。

评估对象模型

当评估对象模式时，你需要看的是返回数据类型，数据的大小，模型如何处理错误，以及当前的状态模型。如果现存的对象返回简单数据类型或者非连接记录集（disconnected recordset），向.NET移植就比较简单。简单数据类型将直接地映射到XML中，非连接记录集可以使用.NET数据集表示。但是如果现有对象返回复杂的COM数据类型、连接记录集（connected recordset）、或者其他复杂的结构，移植就不简单了。在这种情况下，你要检查当前的状态下维持COM对象状态的选项，并将它们用具有将COM数据类型翻译成其它层能够消费的XML数据类型的XML Web Services来包装。

因为XML Web Services结构中层间返回的值都是文本串的形式，返回数据的数量便成了关键问题。从一个Windows DNA对象返回1000个4字节的整型值不可能会超过4000个字节，但是用文本表示相同的数字信息需要16000个字节。数据存储400%的增长使应用程序的运行速度快速地降下来。相比要被多个通用函数重用的粗粒对象来说，只需要列信息而返回少数行的细粒对象比较适合向.NET的移植。

现有对象模型的另一个重要方面是报告错误信息的方式。XML Web Services需要一种方法，用于捕获错误并传回给消费者能有效使用的XML包。你的现有对象可能返回一个表示成功或失败的布尔型值和一个指向错误数据的参考指针，要么是在失败的情况下简单地返回null数据。哪一种返回方式都是正确的，但是用于移植的理想应用程序一般都实现相同的错误机制。

至于复杂数据类型的问题，处理有状态对象模型的最好方法是为现有代码提供XML接口。你要在Web Services wrapper中实现XML接口。wrapper管理现有代码的状态，甚至在XML返回一个无状态数据对象到Web service消费者之前，必要时还可以进行多路函数调用。

下一步

一旦你制定出了Windows DNA应用程序对象模型的移植细节，你可能会考虑它的安全模型以及事务模型。.NET扩展了现有的基于COM的安全和事务模型，但是它还还支持现有功能，所以你会发现这些问题很容易解决。