Design Patterns – How Essential Is It to Make a Service Layer?

Architecturedesign-patternsserviceservicesweb services

I started building an app in 3 layers (DAL, BL, UI) [it mainly handles CRM, some sales reports and inventory].

A colleague told me that I must move to service layer pattern, that developers came to service pattern from their experience and it is the better approach to design most applications. He said it would be much easier to maintain the application in the future that way.

Personally, I get the feeling that it's just making things more complex and I couldn't see much of a benefit from it that would justify that.

This app does have an additional small partial ui that uses some (but only few) of the desktop application functions so I did find myself duplicating some code (but not much). Just because of some code duplication I wouldn't convert it to be service oriented, but he said I should use it anyway because in general it's a very good architecture, why programmers are so passionate about services??

I tried to google on it but I'm still confused and can't decide what to do.

Best Answer

Martin Fowler's book "Patterns of Enterprise Architecture" states:

The easier question to answer is probably when not to use it. You probably don't need a Service Layer if your application's business logic will only have one kind of client - say, a user interface - and it's use case responses don't involve multiple transactional resources. [...]

But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning.

The benefits a Service Layer provides is that it defines a common set of application operations available to different clients and coordinates the response in each operation. Where you have an application that has more than one kind of client that consumes its business logic and has complex use cases involving multiple transactional resources - it makes sense to include a Service Layer with managed transactions.

With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations. The responses to creation, update or deletion of a domain object should be coordinated and transacted atomically by Service Layer operations.

Another benefit of having a Service Layer is that it can be designed for local or remote invocation, or both - and gives you the flexibility to do so. The pattern lays the foundation for encapsulated implementation of an application's business logic and invocation of that logic by various clients in a consistent manner. This means you also reduce/remove duplication of code, as your clients share the same common services. You can potentially reduce maintenance costs too - as when your business logic changes, you (generally) only need to change the service, and not each of the clients.

In summary, it's good to use a Service Layer - more-so I think in your example you have provided as it sounds like you have multiple clients of business logic.

Related Topic