从您的实际经验中可以使用一种方法定义服务协定,该方法将接受某个对象作为请求的形式,并根据该请求返回其他一些对象。我的意思是,与其说拥有创建,删除,编辑和搜索客户的方法,不如将这些 Activity 封装在DataContracts中,并且在收到这样的DataContract之后服务将采取相应的措施。但是服务接口(interface)很简单:
interface ISomeService
{
IMessageResult Process(IMessageRequest msg);
}
因此,IMessageRequest将提交名为OperationType = OperationTypes.CreateCustomer的文件,其余字段将为服务提供足够的信息,以使其可以创建Customer对象或记录在数据库等中。而且IMessageResult可能具有带有一些代码的字段,用于指示是否创建了客户。
我试图通过这种设计实现的功能是能够轻松将IMessageRequest委托(delegate)给客户端甚至不知道的其他内部服务。我看到的另一个好处是,如果我们必须在客户上添加一些操作,我们只需为此操作提供额外的DataContract,而不必在服务接口(interface)方面进行任何更改(我想不惜一切代价避免这样做,我的意思不是新的操作,但更改服务接口(interface):)
所以你怎么看?这是处理复杂业务流程的好方法吗?什么是pitfals,什么会更好。
如果我重复了其他一些线程并且对我的问题有一些答案,请提供链接,因为我没有找到它们。
最佳答案
简短的答案:是的,这可能是一个很好的主意(我已经以一种或另一种形式实现了一个)。
这种方法的一个很好的起点是Davy Brion在他所谓的request/response layer上的帖子。他将最初的想法和想法整合到一个非常有用的OSS项目Agatha中,我在撰写本文时在客户站点上建议该项目。