Designing WCF data contracts and operations

Question

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!

Answer 1

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 !

Answer 2

You start wrong on th highest level.

• It should not be "PlaceOrder" service, but "OrderManager". Maybe you want to add more service functions later - like inquiring for orders, cancel orders, change orders - who knows. In general, I would keep the number of "services" (.svc) small and add methods there. Otherwise you end up with a HUGH overhead for using them, in code - without any real benefit.

• Why separate between partners and customers? I am sure with 15 minutes of data design, you could break things down to exactly ONE data structure so you could have only one service. If not... make that two methods on one interface, limit by security. But I seriously would NOT like two programs for that. Rather have two address fields - "Address" and "PartnerInfo", and only one can be set (other has to be null), checked in the logic.

• Separate out into two projects. Interfaces, data contracts go into a separate project (blabalbla.Api) so that customers can actually get the DLL if they want - at least it makes things a lot easier on your end, you can rely on "shared type", no need to generate the wrappers internally. Allows a lot better testing (as sub-projets dont forget to regenerate the wrappers.... which may lead to errors when testing them).

• I always put the implementation into a "blabla.Service" project. Url would be "Services.blabla.com/" in a subdomain (or "api.blabla.com", depends mostly on mood, but lately I am going for api mostly) - separates thigns out from the main website.