以前は、自分の Web サイトで通常の Web サービスを作成し、これらのサービスを JavaScript から呼び出して ajax 呼び出しを行っていました。
今、私は Ado Data Services について学んでいます。私の質問は、この Ado Data Services は、私が作成する新しいサイトで通常の Web サービスを置き換えることができますか?
はいの場合、
これらの Ado Data Services を別のプロジェクト「同じサーバー上のローカル」に配置して、自分の Web サイトから参照することはできますか? 「自分のウェブサイトの内部使用に同じサービスを使用し、他のウェブサイトやサービスにも同じサービスを提供すること。たとえば、Twitter と同じように」
何をしたいかによって異なりますが、Ado.Net Data Services のアーキテクトである Pablo Castro との会話を読むことをお勧めします。
これは基本的にパブロの言葉です。
これらのいくつかは非常に不便であり、修正を検討していることに同意します (たとえば、カスタムの結果セットを生成するために、入力モデルで定義された型に加えてカスタム型を使用するなど)。ただし、Data Services の性質に固有のものもあります。
Data Services フレームワークはデータベースへのゲートウェイではありません。一般に、そのようなものが必要な場合、Data Services は邪魔になります。Data Services の目標は、入力データ モデルからリソース モデルを作成し、それを統一インターフェースを公開する RESTful インターフェースで公開して、基礎となるモデル (「エンティティ」) 内のすべてのデータ ユニットがアドレス指定可能なリソースになるようにすることです。標準動詞で操作できます。
多くの場合、RESTful インターフェイスの実際の実装には、統一されたインターフェイスを壊さない方法で定義する必要がある、内部のデータに対して CRUD を実行するだけでなく、より洗練された動作が含まれます。そのため、Data Services サーバー ランタイムには、クエリ/変更インターセプターなどの形式でビジネス ロジックと検証用のフックが用意されています。また、標準的な動詞で操作されるリソースとして完全にすべてをモデル化することが常に可能であるとは限らず、実用的であるとは限らないことも認識しているため、エスケープハッチとしてサービス操作を含めました。
結合のようなものは、作成しようとしている抽象化を薄めます。それらが悪いなどと言っているわけではありません (それらのないリレーショナル データベースはそれほど有用ではありません)。特定のアプリケーション シナリオで要求されるのは、リレーショナル データベースの完全なクエリ表現力である場合です。サービスの境界がある場合は、ネットワーク経由で簡単にクエリを交換できます (そして、そのセキュリティへの影響を管理できます)。アソシエーション トラバーサルとしてモデル化できる結合については、データ サービスで既にサポートされています。
Data Services が、データを Web に公開することに関するすべての問題の解決策であるとは言い難いと思います。基礎となるデータ モデルに一致するリソース モデルに RESTful なインターフェイスが必要な場合は、通常はうまく機能し、多くの作業を節約できます。カスタム インターフェイスまたはデータベースへの直接アクセスが必要な場合、Data Services は通常、適切なツールではなく、WCF の SOAP や REST サポートなどの他のフレームワーク コンポーネントが優れた機能を果たします。