OData 是公开非 CRUD API 的好方法吗？
[英]Is OData a good way to expose non-CRUD APIs?
问题描述
我正在从事一个项目，这是我们公司首次涉足领域驱动开发。
我们的 Web API 最初只是提供 CRUD 操作，并且项目公开了 OData 控制器，但我不确定这是否仍然是一个好主意。
OData 是公开非 CRUD API 的好方法吗？
更多信息：最初我们的 web api 基本上暴露了 CRUD 函数。 要创建一个新用户，您只需创建一个并将其发布到服务。 例如，要更改地址，您将获得用户实体的副本，进行更改，然后执行更新操作。 基本的 OData 东西。
除了提供查询支持外，OData 还以一种易于使用的方式公开服务，因此可以将其作为服务引用添加到其他项目中并通过代理进行访问。
自从我们转向 DDD 方法后，情况发生了重大变化。 我们的 Web API 现在只是通往许多独立子域服务的网关。 我们不再提供 CRUD 操作或对实体的直接访问，而是通过服务调用来操作实体。 消费者必须生成一个 CreateUserBindingModel 并将其发送到 User/Create 服务，然后让服务生成实体，而不是创建一个 User 实体，通过 Put 请求将其发送到 User 服务。 更改地址是通过 ChangeAddress(ChangeAddressBindingModel 模型) 方法完成的，而不仅仅是更新整个对象。 查询更有针对性，而且很少返回整个域对象。
当我们不再提供 CRUD 操作时，继续使用 OData 作为我们 Web API 的基础是一个坏主意吗？ 是否有另一种方法可以像使用 OData 一样公开我们服务的详细信息？ 我知道 WCF 服务提供了类似的功能，但我的印象是它比 OData 更依赖于 CRUD。
2 个解决方案
解决方案1
2 已采纳 2020-02-27 06:41:18
OData 是一个面向数据的 API 规范，它是反 DDD。 虽然它可以满足您实现 REST API 的所有要求，但它最适合数据处理 API。 我想您已经知道使用 OData 感觉就像通过 HTTP 操作数据库一样。 如果您使用的是 DDD，您应该完全忘记 OData。
解决方案2
0 2018-07-31 14:02:48
在 OData 中，动作和函数是一种添加服务器端行为的方法，这些行为不容易定义为实体上的 CRUD 操作
仅为路由公开.NET OData API的子集（对于排除的API，返回404）
[英]Expose only a subset of .NET OData APIs for a route (return 404 for excluded APIs)
这是通过接口公开通用基类方法的好方法吗？
[英]Is this a good way to expose generic base class methods through an interface?
在Nhibernate中设置CRUD方法和SessionFactory的好方法是什么？
[英]What is a good way to setup CRUD methods and SessionFactory in Nhibernate?
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.