Ado 数据服务可以替代我在网站的 ajax 调用中使用的 Web 服务吗？

发布于 2024-08-04 08:49:44 字数 260 浏览 8 评论 0原文

我曾经在我的网站中创建普通的 Web 服务，并从 javascript 调用这些服务来进行 ajax 调用。

现在我正在学习Ado Data Services，我的问题是：此 Ado 数据服务是否可以替代我将创建的新站点中的普通 Web 服务？

如果是，

我可以将这些 Ado 数据服务放在“同一服务器本地”的单独项目中，然后仅从我的网站引用吗？ “将相同的服务用于我的网站内部使用，并为其他网站或服务提供相同的服务，例如与 Twitter 相同的服务”

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

萌梦深 2024-08-11 08:49:44

取决于您想做什么，我建议您阅读我与 Ado.Net 数据服务架构师 Pablo Castro 的对话

数据服务 - 缺乏

这里基本上是 Pablo 的话。

我同意其中一些事情非常不方便，我们正在考虑修复它们（例如，除了输入模型中定义的类型之外，还使用自定义类型来生成自定义结果集）。然而，其他一些只是数据服务本质所固有的。
数据服务框架不是数据库的网关，一般来说，如果您需要类似的东西，那么数据服务就会成为障碍。数据服务的目标是从输入数据模型创建资源模型，并通过公开统一接口的 RESTful 接口公开它，以便底层模型中的每个数据单元（“实体”）成为可寻址资源可以用标准动词来操作。
RESTful 接口的实际实现通常包括比仅仅对底层数据进行 CRUD 更复杂的行为，这些行为需要以不破坏统一接口的方式进行定义。这就是为什么数据服务服务器运行时以查询/更改拦截器等形式提供业务逻辑和验证的挂钩。我们还承认，将所有事物建模为使用标准动词操作的资源并不总是可能或不切实际，因此我们将服务操作作为逃生舱门。
诸如连接之类的东西会淡化我们试图创建的抽象。我并不是说它们不好或者什么（没有它们的关系数据库不会那么有用），只是如果给定的应用场景所需的是关系数据库的完整查询表达能力可以在服务边界，那么您可以简单地通过线路交换查询（并管理其安全影响）。对于可以建模为关联遍历的连接，数据服务已经支持它们。
我想这是一个很长的说法，数据服务并不是所有涉及将数据暴露到网络的问题的解决方案。如果您想要一个与我们的底层数据模型相匹配的资源模型上的 RESTful 接口，那么它通常效果很好，并且会为您节省大量工作。如果您需要自定义接口或直接访问数据库，那么数据服务通常不是合适的工具，而其他框架组件（例如 WCF 的 SOAP 和 REST 支持）在这方面做得很好。

depends what you want to do , I suggest you read my conversation with Pablo Castro the architect of Ado.Net Data Services

Data Services - Lacking

Here is basically Pablo's words.

I agree that some of these things are quite inconvenient and we're looking at fixing them (e.g. use of custom types in addition to types defined in the input model in order to produce custom result-sets). However, some others are just intrinsic to the nature of Data Services.
The Data Services framework is not a gateway to a database and in general if you need something like that then Data Services will just get in the way. The goal of Data Services is to create a resource model out of an input data model, and expose it with a RESTful interface that exposes the uniform interface, such that every unit of data in the underlying model ("entities") become an addressable resource that can be manipulated with the standard verbs.
Often the actual implementation of a RESTful interface includes more sophisticated behaviors than just doing CRUD over the data under the covers, which need to be defined in a way that doesn't break the uniform interface. That's why the Data Services server runtime has hooks for business logic and validation in the form of query/change interceptors and others. We also acknowledge that it's not always possible or maybe practical to model absolutely everything as resources operated with standard verbs, so we included service operations as a escape-hatch.
Things like joins dilute the abstraction we're trying to create. I'm not saying that they are bad or anything (relational databases without them wouldn't be all that useful), it's just that if what's required for a given application scenario is the full query expressiveness of a relational database to be available at the service boundary, then you can simply exchange queries over the wire (and manage the security implications of that). For joins that can be modeled as association traversals, then data services already has support for them.
I guess this is a long way to say that Data Services is not a solution for every problem that involves exposing data to the web. If you want a RESTful interface over a resource model that matches our underlying data model, then it usually works out well and it will save you a lot of work. If you need a custom inteface or direct access to a database, then Data Services is typically not the right tool and other framework components such as WCF's SOAP and REST support do a great job at that.

回复收藏 0 原文

~没有更多了~