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: 204
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