Structuring your project to avoid dependency issues

When building up your project, it's important to choose a file structure that matches your architecture and simplifies your life as much as possible. For instance, projects that are considering an application with a service layer, a business model, and a repository layer might create a structure like this:

\CrudService
\CrudService\Models
\CrudService\Repositories
\CrudService\Services
\CrudService.Tests
\CrudService.Tests\Models
\CrudService.Tests\Repositories
\CrudService.Tests\Services

With ServiceStack and other frameworks that make use of strongly typed data transfer objects, it can make sense to have the DTOs themselves shared across both a client project, for instance, a ServiceStack C# client, and the server project, particularly when one team is in charge of both—this helps each project to immediately and automatically stay in sync on any changes to the DTOs.

We'll go into more depth on the C# client later in the Integrating with ServiceStack using the C# client and NativeTypes recipe in Chapter 9, Integrating with Other Technologies.

Getting ready

First make sure that your main project is broken up appropriately—creating folders for services and other layers for instance.

Secondly, create a new project within your solution for the data transfer objects. In our example, we'll call this project ServiceModel.

When that's done, we'll add a reference from the main project to the ServiceModel project.

When we create our client project after that, we'll add a reference only to the ServiceModel folder at that time, creating a clean line of separation between our projects. This leads to less coupling of our code and a more flexible interface.

While any unit test project will still require a reference to the main project, any integration test projects might not, depending on what all you're doing. Integration test projects will only require a reference to the ServiceModel project, as with our client.

How to do It

First, let's build on the service we created in the Routing using data transfer object attributes recipe, about the Route annotation. However, we'll refactor things a bit, creating a Service folder, and then creating a ServiceModel project. When you're finished, your project should look like this:

MessengerService.cs has been moved out to the Service folder, but nothing else has changed. Fix your namespaces, make sure things still build, and check that any tests still pass, as shown in the following screenshot:

Once that's done, our next step is to create the ReidsonMessenger.ServiceModel project—a class library will do fine.

Next, we'll move all of our data transfer objects to ServiceModel. You can do it one at a time, or highlight all six of them and drag-and-drop. Make sure you get Group.cs, GroupResponse.cs, Search.cs, SearchResponse.cs, Message.cs, and MessageResponse.cs in the new project, and you can delete them from the old one.

Once you've done that, the project won't build anymore. To fix that, add a reference from the main project to the ServiceModel project:

If you have any test projects, they'll need the reference too.

Once the references are in place, you need to add the using directives for each class that makes use of the DTOs. Once that's done, your project should build again, with tests still passing.

Now you can add a client project to your solution, and it would only need a reference to ServiceModel. To demonstrate, go ahead and add a ServiceClient project to the solution. Right-click the solution and choose New Project. Choose Console Application as the type, enter the name ServiceClient.

Note

Note that if you're using VisualStudio Express for Web, you can instead create a class library and then change the type to Console Application in the project properties.

You'll also need to add a reference to ServiceStack as usual.

Once the references are added, you could create a client as follows:

public class Program
{
  public static void Main(string[] args)
  {
    Console.WriteLine("Please enter your name:");
    var sender = Console.ReadLine();
    Console.WriteLine(
     "Please type the group name you'd like to post to:");
    var groupName = Console.ReadLine();
    Console.WriteLine("Please enter your message:");
    var body = Console.ReadLine();
    var message = new Message
    {
        Body = body,
        GroupName = groupName,
        Sender = sender
    };

    var client = new JsonServiceClient("http://localhost:2202");
    client.Post<MessageResponse>(message);
    Console.WriteLine(
      "Thank you. To read messages for " + groupName + ", please push any key.");
    Console.ReadKey();

Next up, we can query the service by calling client.Get(), passing in a request object, and specifying the response type we're looking for. We'll receive a response containing the messages we'd like to display. A simple foreach loop should do the trick of displaying them:

    var messages = client.Get<GroupResponse>(new Group { GroupName = groupName });

    Console.WriteLine("Displaying " + messages.Messages.Count + " messages:");
    foreach (var groupMessage in messages.Messages)
    {
      Console.WriteLine(groupMessage.Sender + ": "+ groupMessage.Body);
    }
    Console.ReadKey();

As you can see, with the one simple reference to ServiceModel, ServiceStack itself, and a starting URL, we can easily construct clients that can connect to the service without having any other references, reading documentation for the REST service, or needing to know the exact paths specified in the routes.

We'll describe the C# client in more detail in Chapter 9, Integrating with Other Technologies.