设计WCF数据契约和操作

我现在开始设计一个wcf服务总线，它现在很小，但随着我们业务的增长，它会不断增长，所以我很担心一些grwoing问题，同时也尽量避免过多地使用YAGNI。这是一个电子商务平台。问题是我对把东西放在哪里有太多的犹豫。我将给出一个场景来演示我的所有问题

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

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

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

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

所以我会

- MySolution.sln - Partner (folder) - PartnetService.svc - DataContracts (folder) - Address - Customer (folder) - Customer.svc - DataContracts (folder) - Address -MySolution.sln -合作伙伴（文件夹） -PartnetService.svc -数据合同（文件夹） -地址 -客户（文件夹） -Customer.svc -数据合同（文件夹） -地址 使用这种方式，我将有一个名称空间来放置所有特定于上下文的数据契约

2） 服务设计呢？我是否应该为每个可能放置和订购的服务创建一个服务，并在其中创建一个PlaceOrder方法，如下所示：

Partner.svc/PlaceOrder
Customer.svc/PlaceOrder

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

Order.svc/PlaceOrderForPartner
Order.svc/PlaceOrderForCustomer

3） 假设我在最后一个问题中选择了第一个选项，那么我应该如何处理订单上的操作以及合作伙伴和客户共有的操作

4） 我应该将DataContracts和服务定义放在同一个程序集中吗？每人一个？服务实现的一切

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

一句话，我最大的问题是：如何“组织”服务创建中涉及的数据契约和服务

---

提前感谢您对此的任何想法

你在最高级别开始时出错

• 它不应该是“PlaceOrder”服务，而应该是“OrderManager”。也许你以后想添加更多的服务功能——比如查询订单、取消订单、更改订单——谁知道呢。一般来说，我会保持“服务”（.svc）的数量较少，并在其中添加方法。否则，在代码中使用它们会带来巨大的开销，而没有任何真正的好处

• 为什么要将合作伙伴和客户分开？我相信，只要花15分钟进行数据设计，您就可以将事情分解为一个数据结构，这样您就可以只拥有一项服务。如果不是。。。在一个接口上使用这两种方法，受安全性限制。但我真的不希望有两个这样的节目。而是有两个地址字段-“地址”和“PartnerInfo”，并且只能设置一个（另一个必须为空），并在逻辑中进行检查

• 分为两个项目。接口、数据契约进入一个单独的项目（blabalbla.Api），这样客户就可以真正获得DLL，如果他们愿意的话——至少这会让事情在您这边变得更容易，您可以依赖“共享类型”，而不需要在内部生成包装器。允许更好的测试（因为子项目不会忘记重新生成包装…这可能会导致测试错误）

• 我总是把实现放在一个“blabla.Service”项目中。Url应该是子域中的“Services.blabla.com/”（或“api.blabla.com”，主要取决于情绪，但最近我主要选择api）——将内容从主网站中分离出来

---

除了TomTom提到的，我还想在这里加上我的2美分：
我喜欢这样构造我的WCF解决方案：
合同（类库）
包含所有服务、操作、故障和数据协定。可以在纯.NET到.NET场景中在服务器和客户端之间共享
服务实施（类库）
包含实现服务的代码，以及实现此功能所需的任何支持/帮助方法。没有别的了
服务主机（可选-可以是Winforms、控制台应用程序、NT服务）
包含用于调试/测试或可能也用于生产的服务主机
这基本上给了我服务器端的东西
在客户端：
客户端代理（类库）
我喜欢将我的客户端代理打包到一个单独的类库中，这样它们就可以被多个实际的客户端应用程序重用。这可以通过使用svcutil或“添加服务引用”并手动调整生成的app.config来实现，或者通过使用

ClientBase

或

ChannelFactory

构造手动实现客户端代理（在共享合同程序集时）
1-n个实际客户端（任何类型的应用程序）
通常只会引用客户端代理程序集，或者如果正在共享，也可能引用合同程序集。这可以是ASP.NET、WPF、Winforms、控制台应用程序、其他服务——你可以说
这样,；我有一个漂亮干净的布局，我一遍又一遍地使用它，我真的认为这使我的代码更干净，更易于维护
这是受到米格尔·卡斯特罗与卡尔·富兰克林合作的“网络摇滚”电视节目的启发——高度评价