I have to build a small app which is basically a wcf API for CRUD operations to a database. I want to create a DAL –> BLL –> Web service layer in that order.
In the DAL I intend to create basic table CRUD operations to the db on a 1 to 1 basis, 1 call one operation on a table.
One of the requirents are that a legacy app which uses this interface needs to have access to the WCF webservices so that each screen will have an associated web service method. i.e. a screen (which the business decide will have 1 single method to serve each screen).
Im wondering should I essentially build these requirements into the BLL, and then just re-expose via the webservices? Or should I create the BLL to do logical business operations and then build a facade over the top which will create the specific (screen to web method call requirment mentioned above) and then re-expose that on the WCF instead?
I dont want to overcomplicate the app but I want it to be extensible obviously.
Any advice much apreciated.
In general, I think it makes sense to keep your BLL clean and usable by everything else that needs it. Then, if you need to support some legacy calls, your idea of a facade is a good one. That would allow your BLL to stay the way it should, while the facade would orchestrate the correct/existing BLL logic to serve the legacy app.
It’s almost a cheap way out to answer this way. My answer is that I agree with you; build a facade to support the legacy calls and orchestrate the existing BLL API calls. That way your BLL stays clean.