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?

  • What about 3rd-party clients that access the service via webservice client, when you don't want to distribute a DLL? Commented Sep 24, 2012 at 15:12
  • @FrustratedWithFormsDesigner - well, there aren't any, and there won't be in the future (in this application which I make to a specific company)
    – BornToCode
    Commented Sep 24, 2012 at 15:13

3 Answers 3


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

  • 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. Commented Sep 24, 2012 at 17:54
  • I'd say a web service is a type of API not a type of UI.
    – MebAlone
    Commented Sep 24, 2012 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
    Commented Sep 24, 2012 at 18:32
  • 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
    Commented Sep 27, 2012 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
    Commented Sep 27, 2012 at 17:37

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.