Service versus command

Jun 20, 2012 at 2:01 PM

Good morning all,

With regard to the contracts folder in MileageStats.Domain, would someone please explain when I would use a service vs a command structure? Implementing either seems straight forward, I'm just unsure when to use one over the either, or the real distinction between the two.


Jun 21, 2012 at 9:48 PM


Based on my understanding, the "service" contracts are interfaces that are implemented by services shared between different parts of your server side application (for example, controllers.) Usually, a service is used to expose common functionality across different classes. In the MileageStats RI, those services are registered in the Unity container and mapped to their corresponding interfaces in the unity.config file of the MileageStats.Web project. Like this, the services are available for the entire server side application and are injected when needed through dependency injection. As an example, you can check the ProfileController class of the MileageStats RI where the UserServices, CountryServices and DefaultFormsAuthentication services are injected in its constructor through their mapped interfaces.

On the other hand, based on my understanding, the "command" contracts in the MileageStats.Domain project are interfaces that are implemented by form models. Those models are entities that represents the fields in an HTML form which are specific to a controller action and contains only the data that is passed to the action. A form model can be seen as a special case of a view model. As an example you can check the FillupController class. Based on my understanding, in its Add Get ActionResult method, a FillupEntryFormModel is created and passed as part of the view model. Then, in its Add POST ActionResult method, it receives the FillupEntryFormModel back with the corresponding data. This FillupEntryFormModel is an implementation of the ICreateFillupEntryCommand interface.

I hope you find this useful,

Damian Cherubini

Jun 22, 2012 at 1:37 PM

Thanks for your feedback Damian. It helped to clarify the distinction between services and commands. If you don't mind I would like to ask a follow up question though. With regard to your explanation of a command functioning in a sence as a view model for a specific controlller and action, why does the sample app only have commands for the create actions, and all other actions are handled using 'Handlers? And secondly, why wouldn't a collection of Handlers be contracted by a service. For example the AddReminderToVehicle, CanAddReminder, DeleteReminder, FulfillReminder and GetReminder, classes be defined as methods in an IReminderService interface?

Ken Lemieux

Jun 22, 2012 at 8:13 PM

Hi Ken,

Based on my understanding, MileageStats uses a "command" (which basically contains the fields of a form) when it's needed to pass complex information to a controller's action. This is the case, for example, when performing "Add" or "Edit" actions as the client side needs to pass all the data to be added to the server. For other actions which do not require large amounts of data to be passed to the server side, it may not be required to use a "command." This is the case, for example, when performing "Details" or "Delete" actions. As an example of this, you can check the VehicleController class in the MileageStats.Web project.

Regarding the use of Handlers, as far as I know they are used by the controllers regardless if the action receives a "command" entity or not. For example, you can check the Add Post ActionResult method of the ReminderController class, in which a RemiderFormModel is received (an implementation of ICreateReminderCommand) and the controller processes the "command" by using the CanAddReminder handler and AddReminderToVehicle handler (among others):

public ActionResult Add(int vehicleId, ReminderFormModel reminder)
    if ((reminder != null) && ModelState.IsValid)
        var errors = Using<CanAddReminder>().Execute(CurrentUserId, reminder);
        ModelState.AddModelErrors(errors, "Add");

        if (ModelState.IsValid)
            Using<AddReminderToVehicle>().Execute(CurrentUserId, vehicleId, reminder);
            return RedirectToAction("Details", "Reminder", new { id = reminder.ReminderId });



According to Chapter 11: Server-Side Implementation - Creating a Business Service Layer, in MileageStats the Handlers are a set of classes that implement the core behavior of the application. They are completely independent from and unaware of the UI. Based on my understanding of this, while a controller is in charge of responding to requests from the client to the server and is more related to the UI of the web application, in MileageStates a handler is more related to the business logic of application.

If I am not mistaken, in MileageStats's case, the "services" are mainly used to provide access to repositories and providing authentication logic. However, what you define as a service in your application will depend mostly of your personal preferences and the requirements of your scenario. So far I'm not aware of a specific guidance about what "should be a service" and what "should not," so I believe it could be possible to group the functionality provided by handlers in a service instead.

I hope you find this useful,

Damian Cherubini