Motivation for a service layer (instead of just copying dlls)?

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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.