设计 WCF 数据契约和操作 [英] Designing WCF data contracts and operations

问题描述

我开始设计一个 wcf 服务总线，它现在很小，但会随着我们业务的增长而增长，所以我担心一些日益严重的问题，同时也尽量不要过多地使用 YAGNI.这是一个电子商务平台.问题是我对把东西放在哪里有太多的第二个想法.我将给出一个场景来演示我所有的问题.

<块引用>

我们有一个电子商务网站，可以销售产品并最终交付.为此，我们有一个 PlaceOrder 服务，除了其他参数外，它需要一个 Address 对象，在这种情况下(我们的网站下订单)由 City、Street 和 ZipCode 组成.

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

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

1) 如何在我的解决方案的命名空间和文件夹中组织这个 DataContracts 对象?我想过为每个上下文(合作伙伴、客户等)创建一个文件夹来保存服务和 DataContracts.

所以我会

<前>- 我的解决方案.sln- 合作伙伴(文件夹)- PartnetService.svc- 数据合同(文件夹)- 地址- 客户(文件夹)- 客户.svc- 数据合同(文件夹)- 地址

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

2) 服务设计怎么样?我是否应该为每个可能放置和订购的服务创建一个服务，并在其中创建一个 PlaceOrder 方法，如下所示:

合作伙伴.svc/PlaceOrder
Customer.svc/PlaceOrder

或者像这样使用 PlaceOrderForPartner 和 PlaceInternalOrder 创建一个 Order 服务:

Order.svc/PlaceOrderForPartner
Order.svc/PlaceOrderForCustomer

3) 假设我选择了最后一个问题中的第一个选项，我应该如何处理对订单进行的、合作伙伴和客户共有的操作?

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

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

最重要的问题是:如何组织"服务创建中涉及的数据合同和服务?

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

解决方案

除了 TomTom 提到的，我还想在这里添加我的 2 美分:

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

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

服务实现(类库)
包含实现服务的代码，以及实现此目的所需的任何支持/帮助方法.没有别的.

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

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

在客户端:

客户端代理(类库)
我喜欢将我的客户端代理打包到一个单独的类库中，以便它们可以被多个实际的客户端应用程序重用.这可以通过使用 svcutil 或添加服务引用"并手动调整产生的可怕的 app.config 来完成，或者通过使用 ClientBase 手动实现客户端代理(共享合同程序集时)或ChannelFactory 构造.

1-n 个实际客户(任何类型的应用)
通常只会引用客户端代理程序集，或者合同程序集，如果它被共享的话.这可以是 ASP.NET、WPF、Winforms、控制台应用程序、其他服务 - 您可以随意命名.

那样；我有一个漂亮干净的布局，我一遍又一遍地使用它，我真的认为这让我的代码更干净，更容易维护.

这灵感来自 Miguel Castro 在 DotNet Rocks TV 上的 Extreme WCF 投屏与卡尔富兰克林 - 强烈推荐的投屏！

I'm starting to design a wcf service bus that is small now but will grow as our business grow so I'm concerned about some grwoing problems and also trying not to YAGNI too much. It's a e-commerce platform. The problem is I'm having too many second thoughts about where to put stuff. I will give a scenario to demonstrate all my questions.

We have an e-commerce website that sells products and ultimately deliveries them. For this we have a PlaceOrder service which, among other parameters, expects an Address object that in this context (our website placing an order) is made of City, Street and ZipCode.

We also do business with partners that use our platform only to sell products. They take care of the delivery. For this scenario we have a PlaceOrderForPartner service that, among other objects, expects an Address object. However, in this context (partner placing an order) the Address object is made of different information that is relevant only to a order placed by partner.

Given this scenario I have several questions:

1) How to organize this DataContracts objects in namespaces and folders in my Solution? I thought about having a folder per-context (Partner, Customer, etc) to keep the services and the DataContracts.

So I would have

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

Using this way I would have a namespace to place all my context-specific datacontracts.

2) What about service design? Should I create a service for each one that might place and order and create a PlaceOrder method inside it like this:

Partner.svc/PlaceOrder
Customer.svc/PlaceOrder

or create an Order service with PlaceOrderForPartner and PlaceInternalOrder like this:

Order.svc/PlaceOrderForPartner
Order.svc/PlaceOrderForCustomer

3) Assuming that I pick the first option in the last question, what should I do with the operations that are made on the order and common to Partner and Customer?

4) Should I put DataContracts and Service definition in the same assembly? One for each? Everything with the service implementation?

5) How to name input and output messages for operations? Should I use the entities themselves or go for OperationNameRequest and OperationNameResponse template?

Bottom line my great question is: How to "organize" the datacontracts and services involved in a service creation?

Thanks in advance for any thoughts on this!

解决方案

Besides what TomTom mentioned, I would also like to add my 2 cents here:

I like to structure my WCF solutions like this:

Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario

Service implementation (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.

Service host(s) (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.

This basically gives me the server-side of things.

On the client side:

Client proxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.

1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.

That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.

This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !

这篇关于设计 WCF 数据契约和操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！