难分难舍的DSO（一）

自从体会到DSO在SQL Server2005 中的险境以来，这一个多月的工作都围绕着它所进行着。不知道是不是因为国内做基于Analysis Services的产品较少的缘故，似乎对DSO之类的讨论非常少。但是对于我们Team现在，DSO十足是一个心病。

大家都认识到微软的SQL Server 2005发布的重要性，如果我们的产品不能及早支持这个平台，很快将会在队伍中消亡。DSO之所以是个心病，是因为在以前的版本中，我们太依赖它了。在基于Analysis Service 2000的平台上，我们利用DSO几乎实现了它所能实现的所有功能（我们以前的平台是ASP+COM+SQL/AS2k）。从创建数据库，维度，立方体，到Partition，Roles，Level等所有对象的创建和维护，我们在代码中都实现了。由于在 2005上面不能再使用DSO的缘故，我们列出了四条出路：

1. 借助2005中自带的Migration程序把2000的数据库迁移过来，并希望DSO仍能被迁移版本支持。
结果是令人失望的，一是没有能成功迁移数据库（旧数据库我们实现了Virtual Cube等很多不兼容或不被支持的特性），二是由于旧版本基于Meta Data 服务的Repository的概念消失，导致DSO的功能单向不能继续使用。

2. 如果数据库不能迁移，我们自己创建一个操作AS2005的管理平台（类似Management Studio），操作2005数据的同时，像2000一样同时更新一个存在SQL Database中的Repository。
这个任务如果采用，可行性和难度都是非常大的，而且我们不可能让用户也使用这个平台去操作他们的数据库。

3. 用托管代码操作AMO来包装DSO的所有接口，并通过CCW在COM中使用。
看似有一定难度,工作量不是很大，因为如果能实现这个DSO的Wrapper，并保证接口都不改变，那么表现层，中间层的代码我们都不需要改变。

4. 利用AMO，修改所有表现层，中间层，和数据层的代码。
第四种方案就是实现一个新的系统了，所有旧的ASP框架将被重构。工作量大，周期长。

我们的目标是要尽可能快地完成到2005的迁移，基本保持产品所有功能都能使用。最后鉴于各方面情况的考虑，我们采用了第三条方案。

现在我就在这个方案的实施中煎熬...

我们面临的第一个挑战就是.NET 2.0被COM的顺利调用，似乎很顺利，我们在VS2005的平台上的CCW论证的很成功，也具有了一定的说服性。

其次面临的问题是DSO的Wrapper，这个最艰巨的任务。我们从DSO实现接口开始，通过RCW反编译.NET代码开始，把DSO实现的所有接口都在UML类图中表示出来（如果有朋友需要的话，我可以提供该类图的Visio版本）。并罗列了系统中用到的所有DSO接口使用。这些只是一个需求工作的开始。然后我们不切实际地用DSO的架构准备作为新类库的开发。这里我遗憾地是没有提早做AMO和AS2005细节的Research，以至于这个为新类库的架构工作毫无用处。（待续）