Service interface - comparison of a couple of approaches

I'm having a hard time deciding which approach is better:

interface IService {
  I开发者_如何学GoSomething CreateSomething();
}

interface ISomething {
  void Do(string parameter);
}

vs

interface IService {
  ISomething CreateSomething();
  void DoSomething(ISomething something, string parameter);
}

vs

interface IService {
  ISomething CreateSomething();
  void DoSomething(int somethingId, string parameter)
}

vs

interface IService {
  int CreateSomething(); // returns something.Id
  void DoSomething(int somethingId, string parameter);
}

vs any other...

The IService interface is supposed to be consumed in a number of different ways:

• As a class library
• As a WCF Service
• As an XML Service
• As a JSON Service

ISomething may have a number of properties that the client will want to investigate, and a number of operations it may perform. ISomething is just one of dozen classes I need to expose this way. ISomething may return more interfaces that I can perform operations on.

I will appreciate any and suggestions and thoughts.

EDIT:

The idea is to create a service that will allow the users to build a workflow graph, and will support a designer. My requirements are to have service code that will support any flavor of a client (therefore the int parameter approaches). At the same time I don't want to run into an explosion of types and method.

Maybe the best approach would be to design it as a feature rich .NET library, and create facades (?) for any channels that may be consuming that?

---

I would use:

interface IService {
  ISomething CreateSomething();
  void DoSomething(int somethingId, string parameter)
}

imho it would generate least traffic since if you just return ID from CreateSomething you'll most likely do another trip if you need the details for processing.

Using the id in DoSomething gives you the least traffic since the entire object doesn't seem to be necessary.

Always try to design service interfaces so that you have to use a few calls as possible to do what you want. That also means that it's difficult to tell you an answer since I do not know the intended purpose.

---

The problem I see is that you want for a class to be a service and data contract at the same time. ISomething can't be interface, because you actually pass concrete types and your clients should know their structure. So my suggestion is that service remains service and data contract remains itself.

class Something
{
}

interface IService {  
  void Do(string parameter);
  Something GetSomething();
}

class SomeService : IService {
  private Something smth;  

  public void SomeService()
  {
    smth = CreateSomething();
  }

  public void Do()
  {
    //
  }

  public Something GetSomething()
  {
    return smth;
  }
}