设计WCF合约（操作/数据）
我目前正在寻求设计一些 WCF 服务，并希望获得社区对处理操作/数据契约的最佳方式的意见。
我有 2 个基本操作合约，第一个创建报价，第二个向报价添加项目（并在后台计算总计）。
第一个接收客户信息和商店信息并返回报价。
第二个接受一个报价和一个项目对象，计算总计并返回项目的报价。
我的问题是这种场景下的数据合约如何设计？
对于CreateQuote，是否应该传入带有客户属性和商店属性集的报价对象，或者是否应该存在某种包含客户和商店属性的 QuoteRequest 对象。存储对象但没有传入引用对象？
对于 AddQuoteItem，是否应该传入一个 QuoteItem 对象，并设置包含 Quote 对象的必需属性，或者是否应该有一个具有 Quote 对象和 item 对象（没有关系）的 QuoteItemRequest 对象，然后返回带有 QuoteItem 对象的重新计算的 Quote？
换句话说，它们应该看起来像这样吗？
Quote CreateQuote(Quote quote);
Quote AddQuoteItem(QuoteItem quoteItem);
或者它们应该看起来像这样？
Quote CreateQuote(QuoteRequest quoteRequest);
Quote AddQuoteItem(QuoteItemRequest quoteItemRequest);
I am currently looking to design some WCF services and wanted to get the community's opinion on the best way to handle operation / data contracts.
I have 2 basic operation contracts, the first creates a quote and the second adds an item to a quote (and calculates totals behind the scene).
The first takes in customer information and store information and returns a quote.
The second takes in a quote and an item object, calculates totals and returns a quote with the item.
My question is about how to design the data contracts in this scenario?
For the CreateQuote, should a quote object be passed in with a customer property and a store property set or should there be some kind of QuoteRequest object which contains a customer & store object but with no quote object passed in?
For the AddQuoteItem, should a QuoteItem object be passed in with required properties set including a Quote object or should there be a QuoteItemRequest object that has a Quote object and an item object (with no relation) and then a recalculated Quote with a QuoteItem object is returned?
In other words should they look something like this?
Quote CreateQuote(Quote quote);
Quote AddQuoteItem(QuoteItem quoteItem);
Or should they look something like this?
Quote CreateQuote(QuoteRequest quoteRequest);
Quote AddQuoteItem(QuoteItemRequest quoteItemRequest);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为将它们包装在请求/响应包装器中可能被证明有点多余。您始终可以假设 WCF 服务方法的参数是“请求”，返回类型是“响应”。
在您的场景中，将 Customer 类型和 Store 类型传递给 CreateQuote 方法并返回 Quote 类型。然后传递一个 Quote 类型并再次返回您的 Quote 类型，或者返回一个指示成功的 bool 值到 AddQuoteItem 方法。
同样，在您的场景中，您的请求/响应类只是单一类型的一级包装器。我只能设想一种场景，您将返回一个响应类，以将多种不同类型包装在方法的单个返回值中。
I would argue that wrapping them in request/response wrappers might prove to be a little superfluous. You can always presume that parameters to WCF service methods are the "request" and the return type is the "response".
In your scenario, pass a Customer type and Store type to the CreateQuote method and return a Quote type. Then pass a Quote type and return either your Quote type again, or a bool indicating success instead, to the AddQuoteItem method.
Again in your scenario, your request/response classes would simply be one-level wrappers around a single type. I could only envisage a scenario where you would return a response-esque class to wrap multiple different types in the method's single return value.