2

I'm curious as to see how most developers go about designing the contracts to their web services. I am quite new to service architecture and especially new to WCF.

In short, I'd like to find out what type of objects you are returning in your operations, and does each operation in your service return the same object?

For example consider the following: Currently, all services I create inherit from a ServiceBase object that looks similar to: 

public abstract class AppServiceBase<TDto> : DisposableObjectBase where TDto : IDto
{
    protected IAppRequest Request { get; set; }
    protected IAppResponse<TDto> Response { get; set; }
}

Response represents the return object which composes something like: 

public interface IAppResponse<TDto> where TDto : IDto
{
    List<TDto> Data { get; }
    ValidationResults ValidationResults { get; }
    RequestStatus Status { get; }
}

Therefore, any derived service would return a response composed of the same object. Now initially, I felt with would be a good design as this forces each service to be responsible for a single object. For the most part this has worked out, but as my services grow, I've found myself questioning this design.

Take this for example: You have music service you're writing and one of your services would be "Albums". So you write basic CRUD operations and they pretty much all return a collection of AlbumDto.

What if you want to write an operation that returns the types of albums. (LP, Single, EP, etc) So you have an object AlbumTypesDto. Would you create a new service just for this object or have your Albums service return many different objects?

I can imagine a complex service with several varying return types to be cumbersome and poor design, yet writing a whole new service for what maybe, only one or two service operation methods to be overkill.

What do you think?

Daniel
  • 1,843
  • 2
  • 18
  • 27

1 Answers1

1

It is a good idea to design your services around your domain problem. By exposing a CRUD pattern on the service, essentially you are using services for data access. The risk of this is your business logic will end up on whatever is consuming your service.

You service should expose methods relavent to the problem you are trying to solve (which loosely models onto the operation on the UI typically)

From here you will see your data contracts start to fit more naturally to the problem you are trying to solve, instead of creating "one size fits all" contracts.

For a good starter, Google "Domain Driven Design" But there is plenty of reference material on this.

Slappy
  • 4,042
  • 2
  • 29
  • 41
  • Thanks for your answer Slappy. I've been working with DDD for the past year now but until now, had not needed a service layer. Could you please clarify what you mean by: "The risk of this is your business logic will end up on whatever is consuming your service." So based on your response, I should not limit my contract operations to a single response type, but rather ensure they are only returning objects relevant to the problem. I'll continue reading up on DDD and service-layer design. – Daniel Nov 21 '10 at 20:03
  • Business logic consume CRUD routines. Implementing CRUD on your WEB service will mean that your consumer (in this case the silverlight application) will host the business logic. To my mind I would encapsulate the business logic IN the web services so your silverlight app only need concern itself with presentation. – Slappy Nov 22 '10 at 22:10