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

Posted by BornToCode on Programmers See other posts from Programmers or by BornToCode
Published on 2012-09-24T14:56:15Z Indexed on 2012/09/27 21:50 UTC
Read the original article Hit count: 171

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?

© Programmers or respective owner

Related posts about design-patterns

Related posts about architecture