2010-01-12 75 views
2

我有一个面向服务的体系结构。客户端拥有绑定到前端的父级和子级dtos列表。为此的服务是一个返回所有内容的完整列表。当从列表中删除dto时要发送什么

删除当是它更好地:

一个。在服务删除方法成功时从前端列表中删除对象(返回成功或失败的布尔值)
b。再次返回对象的完整列表
c。返回受影响的父母和子女
d。其他建议

在此先感谢

+0

“面向服务的体系结构”是否意味着您拥有通过稳定的接口/合同暴露的逻辑的自治体?或者你的意思是你有一个客户/服务器架构? – 2010-01-12 22:10:37

+0

我的意思是两者。该服务允许我的客户端与服务器通话,但服务后面有一个域可以让其他应用程序在某个阶段挂钩。 – Burt 2010-01-12 23:06:39

回答

2

它实际上取决于商业案例。

当两个用户正在使用该系统。两者都添加和删除列表中的项目。

当用户A删除项目时,是否希望他看到用户B的棋子,还是需要用户A按下刷新以查看这些更改?

询问用户他们希望如何工作,然后选择通过网络传输的数据量最少的方法。

4

有一个真正面向服务架构,服务应该是异步的,所以他们不应该在所有返回任何结果。

对于删除操作,这个实现起来非常简单:只需开火并忘记。

Udi Dahan's blog是了解真正的服务导向的好地方。

如果你想留在你的问题暗示的RPC消息交换模式,我仍然会说该方法应该返回void。如果您从同步HTTP POST得到一个空的答案,它意味着成功 - 否则,您将得到一个SOAP错误或其他错误结果。

+0

感谢您的博客看起来不错的答案必须将其添加到我的阅读列表。 – Burt 2010-01-12 23:04:46

2

我会选择A.如果你的服务可以依靠正确地指出删除成功或失败,那么为什么还要重新加载所有的对象呢?除非你也想立即显示其他用户的删除,在这种情况下,B将是更好的选择。您也可以选择通过定期轮询/通知方法来显示其他用户的删除,这与删除操作是分开的。这真的取决于您的应用程序的要求。

1

它不仅取决于this answer所示的业务案例,还取决于您在代码设计中的风险承受水平。客户端与服务之间的紧密耦合可能会使代码更难以随着应用程序的增长而变化,并且复杂性也会增加。相反,清晰的职责分离和松耦合通常会提高可维护性和整体项目敏捷性。

在这种情况下,这可能意味着服务不知道客户端的存在以及它的实现,因此可以排除直接操作客户端列表的服务。如果此服务是作为类库实现的,那么我会推荐一种发布者/订阅者方法,其中该服务公开包含相关删除信息的类型的C#事件,并且客户端处理该事件并相应地更新它的列表。

如果这是一个Web(单向)服务,我希望删除服务调用与GetAll服务调用是分开的。客户端将使用这些调用的组合手动管理它的列表。