使用SOAP公开CRUD操作
通过SOAP web服务公开CRUD操作是个坏主意吗？我的直觉告诉我，这并不是最重要的，因为进行数据库调用的开销可能是巨大的。我正在努力寻找支持/反对这种(反)模式的文档，所以我想知道是否有人可以给我一些文档或者对这个问题有意见。
此外，如果有人知道在设计soap服务时的最佳实践(和/或文档)，那就太好了。
下面的示例展示了web服务的外观：
- Create
- Delete
- Execute
- Fetch
- Update
下面是实现的样子：
[WebMethod]
public byte[] Fetch(byte[] requestData)
{
SelectRequest request = (SelectRequest)Deserialize(requestData);
DbManager crudManager = new DbManager();
object result = crudManager.Select(request.ObjectType, request.Criteria);
return Serialize(result);
}回答 4
Stack Overflow用户
发布于 2008-10-09 14:20:56
如果您想以RESTful方式使用SOAP，那么有一个有趣的标准，WS-Transfer；它提供了松散耦合的CRUD端点；您可以通过它检查消息并相应地操作您的实体。
然后，您可以在其上分层任何其他内容，如WS-Secure、WS-Reliable messaging等等。
Stack Overflow用户
发布于 2008-10-09 14:12:20
我认为发布一个向匿名的公共“用户”公开CRUD操作的SOAP服务是一个特别糟糕的主意。但是，如果您可以限制这些警告中的一个或两个，那么我认为这没有什么错(而且我已经多次实现了这样的服务)。
- 除了执行操作所需的任何方法参数外，您还可以要求用户名和密码参数，这些参数实际上是在处理请求之前验证发起者的身份:身份验证失败可以通过返回SOAP异常来通知。如果您特别偏执，您可以选择在SSL
- 上运行该服务。您可以使用服务器解决方案来处理发送和接收请求的问题，该服务器解决方案基于IP进行过滤，允许来自一系列已批准地址的请求。
是的，通过SOAP运行请求是有开销的(与公开直接数据库访问相反)-即将请求包装到HTTP请求中，打开套接字并发送它的处理时间(以及在接收端进行反向操作，然后再次发送响应)-但是，它确实有优势。
Java (通过Web )和.Net (通过VS)都支持将NetBeans服务消费到项目/解决方案中-这样做的最大好处是远程服务上的对象/结构会自动转换为消费应用程序中的本机对象，这非常方便。
Stack Overflow用户
发布于 2008-10-09 14:12:41
如果你想做的只是在web上进行CRUD，那么我将研究一些不同的技术来代替使用WS*来进行REST。SQL Data Services (以前的Project Astoria)实际上可能是一个很好的选择。
https://stackoverflow.com/questions/187326
复制相似问题