異端な開発者を許ぃたってチョ☆

SQL Server 2008 から、Native XML WEB Services 機能が、Deprecated になりました。

日本語 MSDN Library なのに、そこだけ英語なので、流行っとらんかったんかな、と思いましたが、やはり、WEB Service 関連は、ASP.NET に譲るべきということなのでしょうか。それとも、もう SOAP はやめていこう、ということなのでしょうか。

最近、.NET Framework 3.5 からの WCF のREST 対応を見ても、今までの SOAP 形式から、軽量の REST へ時代は動いとるんかな、と思います。

MSDN Library には、そんなにSOAP に対応させたいと言うなら、 WCF か ASP.NET を使え、と書いてあります。たぶん、今度 .NET Framework 3.5 SP1 で提供される ADO.NET Data Services では、もっと簡単に、宣言的に実装できるのでしょう。

個人的には、「SQL Server 自身が、WCF のエンドポイントを持ってくれたらなぁ」と強く思います。

ひろえむさんの記事で「Velocity」なる開発コードを知りました。

調べてみると、6月2日に、アメリカの Tech Ed で他にもいろいろ発表されたらしい。→ITmediaの記事

最近、LINQ の登場で、今まで簡単にできなかったアプリケーションでのデータ加工（特に JOIN とか）や、異なるデータソース間での JOIN などができるようになりましたけれど、SQL Server Compact や、その同期のための Data Caching とか、.NET Framework 3.5 SP1 で加わる ADO.NET Data Services や ADO.NET Entity Framework 、そして、その後に、Microsoft Sync Framework や Velocity など、次々と、データアクセスや分散アプリケーションの基盤ができてきているのは、そういう方向に進んでいるのだな、と思わされます。

「疎結合」と「多層化」と「抽象化」がコンピューター間まで発展しているということなんだろうと思います。

疎結合ということには、非同期も含まれると思います。だから、初代 ADO.NET で DataSet は非同期が標準となったのだろうと思います。「疎結合」に必要なものは、「抽象化」で、そのために登場した LINQ は素晴らしいと思います。どんな形態でも同じ書き方でクエリぇるのですから。

ただ、個人的には、LINQ to SQL は、データソースのデータ構造を意識してしまう（疎結合ではないと思う）ので、あまり使いたくないかな、とは思います。ローカルキャッシュである SQL Server Compact へのデータアクセスには、ＯＫかな、と思います。現在は、SQL Server のストアドをメソッドかWEBサービスのように使うのが常套手段ですが、ADO.NET Entity Framework は使ってみたいと思います。はよ、出んかな。