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.

6 Answers
6

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.

Interestingly, Martin Fowler advocates against the same interface for local and remote invocation, arguing that the huge performance difference in remote invocation forces a more coarse grained interface.
–
psrAug 29 '12 at 22:41

I didn't quite understand your paragraph 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 - if it's all about multiple UIs so how do the CRUD get in here? And if I wouldn't need multiple UIs even though the CRUD goes well with services I would still not make a service layer, if I understood correctly, and I really I hope I did because I prefer to keep things simple (service layer is a mess to my inexperienced opinion)
–
BornToCodeSep 4 '12 at 21:10

2

In those cases it's rare that there would be only one client that can take advantage of it. If you only had one UI I can think of two reasons that you may still want the service layer: security and reusability. A typical enterprise setup would have the UI app available to external clients, and your service layer only available in the network. So the web server delagates the work to a locked down portion of your network. In the sales example you could have re-use if you take sales from your web site and expand to eBay or Amazon. Now you have one UI, yet multiple clients.
–
Phil PattersonSep 4 '12 at 22:16

3

Just to add to the comment from @PhilPatterson. Multiple clients don't just have to be UI based. Think web services or libraries - they can also be clients. Your front end UI might use the service layer as well as the software services you package and let someone else use.
–
DecoSep 5 '12 at 2:02

can you provide an example of a Service Layer?
–
user962206Mar 26 '13 at 10:31

I agree with you. There is no need to include one more layer if you are using a single UI.

DAL,BL and UI/Controller are good combination to design an application. If you are planning to go with a single UI, there is no need to prepare an extra layer. Including 1 more layer into application only increases development efforts/time.

Another schenerio is to use multiple UIs in your application, it is good to have a service layer to handle UIs in this case.

So do you suggest that on every complex application one develop he should use a service layer and not just settle for DAL,BL,UI layers?
–
BornToCodeAug 27 '12 at 8:49

In case of multiple UIs we must include a service layer. In your case i don't think there is a need of prepare a new layer. It only increases the complexity of the application.
–
Satish PandeyAug 27 '12 at 16:20

Most Service Layers I've seen are a complete mess. Services tend to have a lot of different methods, 1500 LOC are not rare. The different methods have nothing in common, but do share code. This results in high coupling, low cohesion. It also violates OCP, because every time a new operation is needed, you have to modify the code instead of extending the code base. A well constructed service layer is theoretically possible, but I never seen it in practice.

CQRS solves these problems and prevents you from having to create one of those procedural service layers.

Well constructed by whose standards though? Certainly by OO standards a service layer interface is a complete trainwreck of a mess. From a functional or procedural perspective then it encourages a beautiful layered design approach. I think the biggest hang up people have with service layers is that they encourage a stateless transaction based application and discourage a pure object oriented approach. I can understand both sides of the argument.
–
maple_shaft♦Aug 30 '12 at 11:17

Adding an interface (a service layer is a type of interface) takes time. A good one takes a lot of time to design and test. It is very important to get it right on the first try because changing it later breaks all the clients. Also, consider that you probably won't know what needs to be in that interface until you have a second client with slightly different needs. Maintaining a service is a never-ending project in itself.

In most organizations, if you go to your business sponsor and ask them, "Do you want other departments to get the benefit of (reuse) this system we are developing with your budget?" they will laugh at you. Get it working for your business sponsor first, then start twiddling around with reusing that code (on your department's own time).

If you know, for a fact, that the functionality you are writing today will be reused by multiple different service clients, then consider designing a service layer from day one. If you are unsure, or there are many unknowns in the project already, get something simple working first and separate it into service and client later if you have time and budget. It much easier to get the service interface right on the first try when you start with a working system.

P.S. If you are working in Java, Joshua Bloch has a lot of fantastic interface advice throughout his book, Effective Java.

Adding a service layer because you have evaluated the idea and concluded its the best approach: good

Adding a service layer because thats what all the cool kids are doing: bad

If your gut says you dont need one, then dont make one.

One of the more dissappointing developments in the programming world over the past 10 years or so is that it has become annoyingly 'fashion' oriented, with people following trends and bandwagons as if they were this season's shoes. Dont fall into that trap. Because next season 'everybody' will be telling you that you should have designed it some other way.

There's nothing wrong or right with a service layer - its a particular approach who's suitablility should be evaluated on its technical merits for the project at hand. Dont feel compelled to substitute other people's opinions for your own judgement.

This doesn't address the subject matter at all, it just makes a blanket statement/rant about development practices that, after substituting a few words, could apply to just about any question on this site. From reading this answer, I'm not even convinced that you know exactly what a service layer is.
–
AaronaughtAug 29 '12 at 22:54

3

It certainly can be applied to other questions... doesnt make it less true. Fact is neither you nor I have anywhere near the necessary context to state what he needs in his project, so telling him yes he needs it, or no he doesnt, is just a flat out guess and unprofessional. What the OP needs here is a bit of moral support to make the decisions he knows are the right ones.
–
GrandmasterBAug 30 '12 at 3:21

1

@Aaronaught Regardless of the correctness of the answer, he is still essentially answering the main question, "How essential is a service layer?". He claims not essential at all and that it is possibly just a fad. If you disagree with the answer then please downvote.
–
maple_shaft♦Aug 30 '12 at 11:12

1

@GrandmasterB I would argue that fashions are good in software development. Most developers are too fresh or too incompetent to make well informed design and architecture decisions. We still expect them to turn out some semblance of working software though, so them jumping on a bandwagon and being consistent with a poor design choice is far preferrable and more maintainable than the way things were done years ago where we would cowboy code at everything they didn't understand or appreciate.
–
maple_shaft♦Aug 30 '12 at 11:22

6

@maple_shaft Just to clarify, I am not saying Service Layers are a fad. I'm saying, based on the way the question was asked, that it seems there's faddish/fashion/bandwagon behavior on the part of his colleagues to push him into using an architecture he doesnt think is warrented in his project. I make it clear in my answer I view Service Layers (or any other concept) as just that - neutral concepts whose suitability should be evaluated on their own merit for individual projects. They shouldnt be applied/used when one's own judgement says they arent needed.
–
GrandmasterBAug 30 '12 at 17:18

There are many factors that go into the decision of creating a service layer. I have created service layers in the past for the following reasons.

Code that needs to be re-used by multiple clients.

Third party libraries that we have limited licenses for.

Third parties that need an integration point into our system.

Centralizing duplicated business logic.

Case 1: You are creating base functionality that needs to be used by a myriad of different clients. Service layer builds in functionality for different clients to tap into your provided functionality right out of the box.

Case 2: You normally host code in app space but you are using a third party library that you have limited licenses for. In this case you have a resource you would like to use everywhere, but only a limited number of them. If you host it behind a service then your whole organization can get usage of it from their applications without having to buy a license for each individual hosting.

Case 3: You are building functionality for third parties to communicate to you. In your example you could set up an inventory endpoint to allow vendors to pass messages to you about incoming product shipments.

Case 4: You have analyzed your code enterprise wide and found that separate teams have created the same thing (just implemented slightly differently). With a service layer you can pick the best approach(es) and now you can implement the process the same across all teams by having them call into the service. Another benefit to centralizing logic is when bugs are found. Now you can deploy the fix once and all clients enjoy the benefit at the same time.

All this being said there are potential negatives to a service layer.

Adds system complexity. Where before you only had one application to debug now you have two. Production problems require checking client app setting, service app settings, or communication problems between otherwise correctly setup client and server apps. This can be tricky if you've never done it before.

One point of failure. If you have a service outage all clients are affected. When code is not deployed in this manner the risk can be less (though there are ways to mitigate this).

Versioning can be harder to do. When you have one app using a service deploying interface changes can be done at the same time between the two. When you have multiple clients now you must manage who is on V1, who is on V2, and coordinating the removal of V1 (once you know everyone has updated to V2).

The main point is that it's not always a slam dunk to make your system service oriented. In my experience it usually is a good idea (I tend to structure applications in this way), but it's not an automatic decision. At the end of the day you need to weigh the pros and cons and make the decision that's right for your situation.

+1 Thank you for the informative answer. I really had doubts weather to accept your answer or Deco's answer. Eventually because I'm not too experienced I decided to choose the answer that gets most upvotes. I still feel that your answer would deserve more upvotes. In any event I really do appreciate that you shared your knowledge and experience. Thank you!
–
BornToCodeSep 4 '12 at 21:15

1

Your welcome! The main point to take away from both answers is that this is (mainly) about solving maintenance issues with having multiple clients that need to do the same thing. The greater number of clients using the service, the bigger the maintenance gain for you.
–
Phil PattersonSep 4 '12 at 23:05