设计WCF数据契约和操作

我开始设计一个 wcf 服务总线，它现在很小，但会随着我们业务的增长而增长，所以我担心一些日益严重的问题，并尽量不要 YAGNI 太多。这是一个电子商务平台。问题是我对把东西放在哪里犹豫了太多。我将给出一个场景来展示我所有的问题。

我们有一个电子商务网站，可以销售产品并最终交付产品。为此，我们有一个 PlaceOrder 服务，除其他参数外，它还需要一个由城市、街道和邮政编码组成的地址对象（我们的网站下订单）。

我们还与仅使用我们的平台销售产品的合作伙伴开展业务。他们负责送货。对于此场景，我们有一个 PlaceOrderForPartner 服务，除其他对象外，它还需要一个 Address 对象。但是，在这种情况下（合作伙伴下订单），Address 对象由仅与合作伙伴下的订单相关的不同信息组成。

鉴于这种情况，我有几个问题：

1) 如何在我的解决方案中的命名空间和文件夹中组织此 DataContracts 对象？我考虑过为每个上下文（合作伙伴、客户等）创建一个文件夹来保存服务和数据合同。

所以我会

- MySolution.sln
-    Partner (folder)
-        PartnetService.svc
-    DataContracts (folder)
-        Address
-    Customer (folder)
-        Customer.svc
-    DataContracts (folder)
-        Address
  

使用这种方式，我将拥有一个命名空间来放置所有特定于上下文的数据契约。

2）服务设计怎么样？我是否应该为每个可能下订单的服务创建一项服务，并在其中创建一个 PlaceOrder 方法，如下所示：

Partner.svc/PlaceOrder
客户.svc/PlaceOrder

或者使用 PlaceOrderForPartner 和 PlaceInternalOrder 创建订单服务，如下所示：

Order.svc/PlaceOrderForPartner
Order.svc/PlaceOrderForCustomer

3）假设我在上一个问题中选择了第一个选项，那么对于合作伙伴和客户共同的订单操作，我该怎么办？

4) 我应该将 DataContracts 和 Service 定义放在同一个程序集中吗？每人一份？一切都与服务实施有关吗？

5）如何命名操作的输入和输出消息？我应该使用实体本身还是使用OperationNameRequest 和OperationNameResponse 模板？

我的主要问题是：如何“组织”服务创建中涉及的数据契约和服务？

预先感谢您对此的任何想法！

除了 TomTom 提到的之外，我还想在这里补充我的 2 美分：

我喜欢这样构建我的 WCF 解决方案：

合约（类库）
包含所有服务、操作、故障和数据合同。可以在纯 .NET 到 .NET 场景中在服务器和客户端之间共享

服务实施（类库）
包含实现服务的代码，以及实现此目的所需的任何支持/帮助方法。没有其他的。

服务主机（可选 - 可以是 Winforms、控制台应用程序、NT 服务）
包含用于调试/测试或也可能用于生产的服务主机。

这基本上给了我服务器端的东西。

在客户端：

客户端代理（类库）
我喜欢将客户端代理打包到单独的类库中，以便多个实际客户端应用程序可以重用它们。这可以使用 svcutil 或“添加服务引用”并手动调整生成的可怕的 app.config 来完成，或者通过使用手动实现客户端代理（共享合同程序集时）来完成ClientBase<T> or ChannelFactory<T>结构体。

1-n个实际客户（任何类型的应用程序）
通常只会引用客户端代理程序集，或者也可能引用合约程序集（如果正在共享）。这可以是 ASP.NET、WPF、Winforms、控制台应用程序、其他服务 - 只要你能想到的。

那样;我有一个漂亮而干净的布局，我一遍又一遍地一致使用它，我真的认为这使我的代码更干净且更易于维护。

这是受到米格尔·卡斯特罗 (Miguel Castro) 的启发极端 WCF 截屏 http://www.dnrtv.com/default.aspx?showNum=122在 DotNet Rocks TV 上与卡尔·富兰克林 (Carl Franklin) 一起表演 - 强烈推荐屏幕演员！