Services are important to your application. As an architectural tool, services allow you to develop broad, adaptive systems that would not be possible using only static binding or an application confined to a single physical machine. Services enhance scalability and increase flexibility. Some would argue that services are the last word in the quest for the loosely coupled system. The rising popularity of mobile devices, the desire for more responsive web applications via JavaScript and AJAX calls, frameworks such as Silverlight, and the resurgence of REST are all breathing new life into an architectural concept that until a few years ago was seen as the sole domain of ivory-tower architects and service-oriented architecture (SOA) geeks. For these reasons, more and more applications will begin to include a service interface requirement of some kind.

Services Are Code Too

The actual code in your service should be very simple. In other words, the code should do almost nothing. The most complicated action a service should perform on its own is translate data between data transfer objects (DTOs) and domain entity objects. The service may also perform some simple data validation, similar to what would be done on a web page or a Windows form. Aside from that, your service should call methods only on domain services or a business model object of some sort.

In spite of how simple the code for your service should be, your service is still code. As such, it ...

Get Professional Test-Driven Development with C#: Developing Real World Applications with TDD now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.