In my experience, not only is it a good practice, it is a MUST DO practice for the following reasons

Multiple Clients – The top reason cited by most advocates is simply that you cannot be guaranteed that you will have a single client type (say a desktop browser). You may end up with a mobile app client, another web service client or a multitude of other clients. The services layer serves as the entry point for all these clients – and in a lot of cases, handling your new client is as simple as providing another binding – a simple CONFIGURATION change. It is hard to beat that for the effort required to handle new clients.

While handling multiple types of clients is an important motivation for building a services layer, I find another compelling reason. When I start approaching any new application, the business operations seem to map naturally to service operations. If I think in terms of CreatingNewAccounts or UpdatingCustomerInfo– those seem to be ideally mapped to an AccountService and a CustomerService respectively.  Even as the business operations span across a single transaction (for e.g. AddItemToShoppingCart and CheckOut), it is easier to map these through attributes in the Services Operation.

The first starting point is always the service interface (a list of all the operations that the service will support). To me, any n-Tier app – needs to start with the Services tier –and then be concerned about the data access or the data tier or the web tier.

When might it be overkill?

If you see no other potential client except for the simple web client that you are building – if you see no future mobile clients or other services calling this functionality, the services layer may not be necessary. A simple MVC app – with your controller actions mapped to user operations would be sufficient.

The post Always build a services tier (layer) even if you don’t think you may need it appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.