Designing Contracts and Operations with WCF Data

Question

Now I'm starting to develop a wcf service bus, which is now small, but will grow as our business grows, so I am worried about some problems with dirt, and I also try not too much YAGNI. It is an ecommerce platform. The problem is that I have too many second thoughts about where to put things. I will give a script to demonstrate all my questions.

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

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

Given this scenario, I have a few questions:

1) How to organize DataContracts objects in namespaces and folders in my solution? I was thinking about having a folder for the context (Partner, Customer, etc.) To save services and DataContracts.

So I would have

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

Using this method, I would have a namespace to host all of my data related to a specific content.

2) What about service design? Should I create a service for everyone that can place and order, and create a PlaceOrder method inside it as follows:

Partner.svc / PlaceOrder
Customer.svc / PlaceOrder

or create an order service using PlaceOrderForPartner and PlaceInternalOrder as follows:

Order.svc / PlaceOrderForPartner
Order.svc / PlaceOrderForCustomer

3) Assuming that I take the first option in the last question, what should I do with the operations that are carried out in the order and are normal for the Partner and the Client?

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

5) What are the names of input and output messages for operations? Should I use the objects themselves or use the template OperationNameRequest and OperationNameResponse?

In conclusion, my wonderful question: how to "organize" data and services related to the creation of the service?

Thanks in advance for any thoughts on this!

Answer 1

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

I like to structure my WCF solutions as follows:

Contracts (class library)
Contains all service contracts, operations, failures, and data. It can be shared between server and client in a clean .NET-.NET script.

Service implementation (class library)
Contains code for implementing services and any helper / helper methods needed to achieve this. Nothing more.

Service host (optional - may be Winforms, console application, NT service)
Contains the service host 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 pack my client proxies into a separate class library so that they can be reused by multiple actual client applications. You can do this using svcutil or the “Add Service Reference” and manually configure the terrible app.config that you receive or manually implement client proxies (when using the contract assembly) using the ClientBase<T> or ChannelFactory<T> constructs.

1-n actual customers (any application)
Usually it will refer only to the assembly of client proxies, or, perhaps, to the assembly of contracts, if it will be used together. It can be ASP.NET, WPF, Winforms, a console application, other services - you name it.

Thus; I have a beautiful and clean layout, I use it consistently over and over again, and I really think it made my code cleaner and more convenient to maintain.

It was inspired by Miguel Castro. Extreme WCF screen on DotNet Rocks TV with Karl Franklin - highly recommended screening!

Answer 2

You start wrong at the highest level.

• This should not be a PlaceOrder service, but an OrderManager. Perhaps you want to add additional service functions later — for example, request orders, cancel orders, change orders — who knows. In general, I would keep the number of "services" (.svc) small and add methods there. Otherwise, you will receive HUGH overhead for their use, in code - without any real benefit.

• Why split between partners and customers? I’m sure that with a 15-minute data design you could break everything down to a single data structure, so that you can only have one service. If not ... do these two methods on the same interface, limit security. But I seriously would not want two programs for this. Rather, there are two address fields - "Address" and "Affiliate Information", and only one can be set (the other must be empty), checked in logic.

• Divide into two projects. Interfaces, data contracts are part of a separate project (blabalbla.Api), so clients can actually get a DLL if they want to - at least it simplifies your work, you can rely on a “generic type”, no need to generate wrappers inside. Allows much better testing (since sub-projects do not forget to regenerate wrappers .... which can lead to errors when testing them).

• I always put the implementation in the project "blabla.Service". Url will be "Services.blabla.com/" in the subdomain (or "api.blabla.com", mainly depends on the mood, but lately I'm going to use api mainly) - it separates the tings from the main site.