1

Given the most awesome release of the Visual Studio Extension for ServiceStack, I wanted to make sure that after creating my service with ServiceStack, that when I create a client to consume said services that I'm doing it correctly. By that I mean in a loosely coupled, high performance way.

Let's say that we examine the EmailContacts project so we're all on the same page. The Email Contacts project has a reference to both the EmailContacts.ServiceInterface and EmailContacts.ServiceModel, this is understandable as this IS the service. Now I want to consume this service from another .NET project, doesn't matter what type, console or web.

So my question is this "In the consumer application, will I add a reference to EmailContacts.ServiceInterface and EmailContacts.ServiceModel and use the ServiceStack C# client library?", I don't see where I have a choice not too.

Thank you, Stephen

Stephen Patten
  • 6,333
  • 10
  • 50
  • 84

1 Answers1

2

Keep Service Models in their own Assembly

The benefit of having a well-defined Service Contract where your DTO's are maintained in their own separate impl-free project is that clients will only ever need to reference your Services DTO's to use with one of ServiceStack's C#'s Generic Service Client to call any Service.

Add ServiceStack Reference

Clients are also able to avoid referencing any of your Server dlls if they use ServiceStack's Add ServiceStack Reference feature which provides another way for clients to access your Web Services DTO's.

Clients shouldn't reference any Server implementation projects

It's a code-smell if you find clients needing any reference other than your Service Model and ServiceStack's client libraries, which is an indication that your Service Models aren't in their own dependency and impl-free .dll, which shouldn't depend on anything other than ServiceStack.Interfaces.dll.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390