技术开发 频道

微软更难与甲骨文沟通了?

【美国1105集团供比特网专稿】微软决定不再选择Oracle作为其ADO.NET roadmap数据提供商之后,使得市场上众说纷纭,有的说这是微软十分明智的决定,而其它猜想这是否将意味着大量的代码重写。

  正如昨天报道的,微软已经停止了其System.Data.OracleClient。尽管其在.NET Framework 4中还有,但这已经被标记为“过时了”。

  更让人吃惊的是,微软将不再直接向数据库架构提供商(DSP)提供ADO.NET实体框架的Visual Studio Team System软件(VSTS 2010)。这是Quest软件公司发言人向我证实的,而这是今年早些时候微软曾宣布提供给数据库架构提供商的。

  “我们十分期待看到以后发布的版本的以实体框架为中心的应用程序和离线模型驱动的数据库之间的差距。”该发言人在一封电子邮件中说。

  这一消息对于纽约的一家主要银行的副总裁、资深技术专家Ayub Patel真是让人失望,他们的ASP.NET 2.0应用程序需要连接到Oracle数据库。Patel希望转移到实体框架以使得功能有所改善。“实体框架更强大并且是以C#类语言为基础的。我们希望充分利用这一部分。” 他补充说,使用第三方工具不是一种选择,因此他决定将等到Oracle或微软有更好的方案。

  但是微软正在准备用第三方的工具来填补现在停止的ADO.NET数据供应商甲骨文公司的空白。诸如DataDirect Technologies和Devart提供这种工具。此外,甲骨文公司的供应商为甲骨文提供. NET(ODP.NET),拥有许多优于微软的System.Data.OracleClient。

  “我们已经拥有Oracle数据提供商的.NET,这明显优于微软版本。” 英国伯明翰的Ravi Santlani写道。

  “微软正在放弃重复努力以保持一个数据提供商,甲骨文已经不可能做到更好了。” Lancaster, Pa.的Lynn Crumbling补充。

  “ ODP.NET为甲骨文公司提供更全面的支持,这显示了对甲骨文的数据类型更微妙的理解和忠诚。”纽约twentysix技术主管Andrew Brust表示。

  Brust补充说,这一切都要归结于:“如果我们能不断从微软获得API数据,我们就不会继续重复这种循环。从ODBC到OLE DB再到 ADO.NET要花费几个周期的从宽泛的数据支持和其他数据库的循环。随着LINQ和实体框架的到来,我们基本上又一次经历了这种循环。

0
相关文章