设计WCF数据合同和操作

Question

我开始设计一个现在很小的wcf服务总线，但随着我们业务的增长将会增长，所以我关注一些令人头痛的问题，并且不想太多YAGNI。这是一个电子商务平台。问题是我对于放置东西的地方有太多的想法。我会给出一个场景来展示我所有的问题。

我们有一个电子商务网站，销售产品并最终交付它们。为此，我们有一个PlaceOrder服务，其中除了其他参数之外，还期望在此上下文（我们的网站下订单）中的Address对象由City，Street和ZipCode组成。

我们也做生意，只有使用我们的平台来销售产品的合作伙伴。他们负责交付。对于这种情况，我们有一个PlaceOrderForPartner服务，除其他对象外，它还需要一个Address对象。但是，在这种情况下（合作伙伴下订单），地址对象由与合作伙伴下订单相关的不同信息组成。

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

1）如何组织在我的解决方案命名空间和文件夹，这个DataContracts对象？我想过为每个上下文（合作伙伴，客户等）提供一个文件夹来保留服务和DataContracts。

所以我会

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

使用这种方式我想有一个命名空间来放置我所有的上下文特定datacontracts。

2）服务设计怎么样？我是否应为每一个可能的地方，秩序和创造里面一个方法placeOrder在这样的服务：

Partner.svc/PlaceOrder
Customer.svc/PlaceOrder

或者创建拥有PlaceOrderForPartner订单服务和PlaceInternalOrder这样的：

Order.svc/PlaceOrderForPartner
Order.svc/PlaceOrderForCustomer

3）假设我挑了最后一个问题的第一选择，又该我是否对合作伙伴和客户的订单进行了操作？

4）我应该把DataContracts和Service定义放在同一个程序集中吗？每一个？所有与服务实施？

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

底线我的一个很好的问题是：如何“组织”涉及服务创建的数据合同和服务？

在此先感谢您的任何想法！

Answer 1

况且什么TomTom公司提到的，我也想在这里添加我的2美分：

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

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

服务实现（类库）
包含实现服务的代码，并在需要的任何支持/辅助方法来实现这一目标。没有其他的。

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

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

在客户端：

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

1-正实际客户（任何类型的应用程序）
通常只引用客户机代理组件，或也许合同组件也一样，如果它是被共享的。这可以是ASP.NET，WPF，Winforms，控制台应用程序，其他服务 - 您的名称。

那样;我有一个很好的和干净的布局，我一遍又一遍地使用它，我真的认为这使我的代码更清洁，更容易维护。

这是灵感来自Miguel Castro的Extreme WCF screen cast在与富兰克林DotNet岩石电视 - 强烈推荐屏幕演员！

Answer 2

您在最高级别上出现错误。

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

• 合作伙伴和客户之间为什么分开？我确信有15分钟的数据设计，你可以把事情分解成一个数据结构，这样你就只能有一个服务。如果没有......在一个界面上制作这两种方法，则按安全限制。但我真的不喜欢两个节目。而是有两个地址字段 - “地址”和“PartnerInfo”，只能设置一个（其他必须为空），在逻辑中检查。

• 分成两个项目。接口，数据契约进入一个单独的项目（blabalbla.Api），以便客户可以在需要时真正获得DLL - 至少它使事情变得容易很多，您可以依靠“共享类型”，无需在内部生成包装。允许更好的测试（因为子项目不要忘记重新生成包装......这在测试时可能导致错误）。

• 我总是把实现放到一个“blabla.Service”项目中。 Url在子域（或“api.blabla.com”，主要取决于情绪，但最近我主要用于api）中将是“Services.blabla.com/” - 将主要网站的排名分开。