Hi,
Although from the side of the "consumer" (for example a controller consuming a service or a handler) they appear to be similar, the difference is how they are implemented.
In my opinion, a service allows to wrap certain parts of the application that should be loosely coupled from the rest of the components and provide a easy way to consume the functionality of those parts. A service might store information that could be then shared and modified in other components of the application. Also, it's not uncommon for a service to perform some kind of initialization before it can be consumed. An example of this case could be the repositories, where you are separating the data access layer from the controllers. The controllers doesn't know how to access the database, only how to consume the service.
The handlers used in Silk (not to be confused with the APS.NET handlers) have a more dumb role instead. They basically provide a collection of "functions" that could be executed in any controller. In contrast to services, they role is not to "decouple" functionality that should not be in the controllers and in fact I think that most code container in the handlers could be put directly in the controllers without breaking any separation concern. This is similar to when we separate a long function into smaller ones; it allows you to have smaller controllers which are more readable and promotes code reusability between controllers.
So basically, in Silk a handler is like a simple collection of reusable functions (like a helper) while a service provides access to more complex components.
Thanks,
Damian Cherubini
http://blogs.southworks.net/dcherubini
Although from the side of the "consumer" (for example a controller consuming a service or a handler) they appear to be similar, the difference is how they are implemented.
In my opinion, a service allows to wrap certain parts of the application that should be loosely coupled from the rest of the components and provide a easy way to consume the functionality of those parts. A service might store information that could be then shared and modified in other components of the application. Also, it's not uncommon for a service to perform some kind of initialization before it can be consumed. An example of this case could be the repositories, where you are separating the data access layer from the controllers. The controllers doesn't know how to access the database, only how to consume the service.
The handlers used in Silk (not to be confused with the APS.NET handlers) have a more dumb role instead. They basically provide a collection of "functions" that could be executed in any controller. In contrast to services, they role is not to "decouple" functionality that should not be in the controllers and in fact I think that most code container in the handlers could be put directly in the controllers without breaking any separation concern. This is similar to when we separate a long function into smaller ones; it allows you to have smaller controllers which are more readable and promotes code reusability between controllers.
So basically, in Silk a handler is like a simple collection of reusable functions (like a helper) while a service provides access to more complex components.
Thanks,
Damian Cherubini
http://blogs.southworks.net/dcherubini