I’m having a hard time deciding which approach is better:
interface IService {
ISomething 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:
imho it would generate least traffic since if you just return ID from
CreateSomethingyou’ll most likely do another trip if you need the details for processing.Using the id in
DoSomethinggives 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.