7

I'm creating an application which has 2 different UIs so I'm making it with a service layer which I understood is appropriate for such scenario.

However I found myself just creating web methods for every single method I have in the BL layer, so the services basically built from methods that looks like this:

return customers_bl.Get_Customer_Prices(customer_id);

I understood that a main point of the service layer is to prevent duplication of code so I asked myself - why not just import the BL.DLL (and the dal.dll) to the other UI, and whenever making a change re-copy the dlls, it might not be so 'neat', but still less hassle than one more layer?

{I know something is wrong in my approach, I'm probably missing the importance of service layer, I'd like to get more motivation to create another layer, especially because as it is I found that many of my BL functions ALREADY looks like: return customers_dal.Get_Customer_Prices(cust_id) which led me to ask: was it really necessary to create the BL just because on several functions I actually have LOGIC inside the BL?}

so I'm looking for more motivation to creating ONE MORE layer, I'm sure it's not just to make it more convenient that I won't have to re-copy the dlls on changes?

Am I grasping it wrong? Any simple guidelines on how to design service layer (corresponding to all the BL layer functions or not? any simple example?) any enlightenment on the subject?

BornToCode
  • 1,273
  • 2
  • 13
  • 16

3 Answers3

14

I think the word 'service' gets bandied around so much that it's meaning nowadays is very overloaded and confusing.

There is a big difference between a 'service layer' and a 'web service [layer]'.

A 'service layer' is an abstraction behind which you put the business logic that will be consumed regardless of the UI. That way the UI layer can be as simple as possible (and it's as easy as possible to add more user interfaces later).

An important point to consider is that the service layer does not have to be a web service. Your BL.dll, as you describe it, is a service layer. If both of your user interfaces can consume the BL.dll, then you are just fine importing the BL.dll and going on from there. No need for a web service unless your application requires a web service for some other reason.

As a matter of fact, I wouldn't even consider a web service to be a 'service layer' at all. It's simply another form of UI. A special UI, to be sure; one designed to be consumed by other applications. But a UI nonetheless, especially in the sense that there shouldn't be any business logic in the web service layer, beyond authentication/authorization. The best web service layer will serve as a pass-through to the real service layer underneath.

In short, I don't see a reason that you should think about adding a 'web service layer' unless your application needs it (because the UI layers cannot consume your service layer dll directly).

Eric King
  • 10,876
  • 3
  • 41
  • 55
  • I concur. We have several applications in house that use the same library. We ended up setting up a NuGet server to hold the libraries and now all new projects that need them can get them right through visual studio. – Joshua Belden Sep 24 '12 at 17:54
  • I'd say a web service is a type of API not a type of UI. – MebAlone Sep 24 '12 at 18:21
  • 1
    @MebAlone Sure, I can go with that. But I think an API is a specialized form of UI, where the 'user' is another application. The concepts are basically the same, though, as they relate to business logic. – Eric King Sep 24 '12 at 18:32
  • That's not how I conceive it. A service has an API that it exposes to clients. Those clients may be UI's or other types of code. For example, Skype has had a web service API for some time. They have recently added Java and Python API's. – MebAlone Sep 24 '12 at 19:09
  • (continued from above) I would not refer to these API's as Skype's "service layer". Service layer is an enterprise design pattern, and a separate discussion altogether :-) – MebAlone Sep 24 '12 at 19:19
  • @MebAlone I think we're saying the same thing. Agreed, the web service (API) is not the 'service layer'. That's exactly what I said in my answer. I'm equating UI and API here because, in the context of this question, they are practically the same thing: a way for an external resource (human or otherwise) to access the real 'service layer'. – Eric King Sep 24 '12 at 20:06
  • Right, and you also said the term "service" is overloaded. The term "service layer" is also overloaded, which leads to confusion and actual misuse of the term. – MebAlone Sep 24 '12 at 22:16
  • Thank you for the information, your answers makes sense to me, but I'm still confused - 1.in this [post](http://programmers.stackexchange.com/questions/162399/how-essential-is-it-to-make-a-service-layer/162530#comment313394_162530) I wrote explicitly that I have 3 layers application, and nevertheless @Deco wrote that whenever I envision a second kind of client I should ADD a service layer.. is this a dispute or I'm not getting it right? 2. if a BL layer is also a service layer so why there are 2 DIFFERENT designs: n-layer design and SOA? – BornToCode Sep 27 '12 at 15:47
  • 1
    @BornToCode That post exhibits exactly the loose definition of 'service layer' that I think can be misleading. The implied meaning in the answer is a "web service", so that the maximum types of clients can consume your code. You don't need a web service, since both of your clients (today) can consume your BL directly. The very fact that two clients can consume your BL shows that your BL is acting as a service layer, intentionally or not. – Eric King Sep 27 '12 at 17:34
  • 1
    @BornToCode As for your #2, there's only a very loose connection between 'n-layer' and 'SOA'. N-layer describes the physical layout of your code, whereas SOA describes the intended usage pattern of your code. SOA apps can be n-layer, but they don't have to be. N-layer apps can be written in an SOA fashion, but they don't have to be. A maximally flexible code base for a large distributed app will probably be both n-layer and SOA. – Eric King Sep 27 '12 at 17:37
  • +1, I've long felt that a web service acts like a presentation layer. It offers a way for users to interface with data. It just doesn't tend to be very pleasing to the eye ;) – RustyTheBoyRobot Oct 16 '12 at 15:49
  • +1 Agree with this 100%. The only time we've needed to deploy a web service is when a client can't embed the service layer DLL directly (maybe a mobile client, or a SPA, or simply the service layer has to be hosted on a remote server in the same zone as the DB.) And when we do introduce that web service, it's just a very thin wrapper around the service layer DLL. – ngm Jul 12 '16 at 11:47
3

The benefit of an application service (doesn't have to be a web service) over a dll is you can off-load the execution of the service on a separate machine (probably a server). In the case of your UI being a desktop app, the local machine doesn't need to have as much code installed nor does it need as much horsepower to run your app.

A website could still use this application service.

Like Andy B indicated, you need to determine how many users you need to handle to justify this expense.

JeffO
  • 36,816
  • 2
  • 57
  • 124
1

How many clients are you going to support? Depending on the underlying platform you develop on and how its versioning system works, you may have to recompile and deploy the entire application for updates.

As you've pointed out, currently your service will simply call into the layer below it, effectively duplicating code. If you have fewer than 10 clients (total, not at a given site/deployment), I would say strongly couple to the DAL/BAL. More than that, I would go service.

PrimeNerd
  • 31
  • 1