For a while now, my team and I have been wrapping our data access layer in a web service facade (using WCF) and calling it from the business logic layer. Meanwhile, we could simply use the repository pattern where the business logic layer consumes the data access layer locally through an interface, and at any point in time, we can switch things out for it to hit a service instead (if necessary).
The question is: When is it a good time to wrap the data access layer in a service facade and when isn’t it? Right now, it seems like the main advantage is that other applications can consume the service, but if they are internal applications written in .NET then they can just consume the .NET assembly instead. Are there other advantages of having the DAL be wrapped in a service that I am unaware of?
This really depends on what/how the data service is going to be used. If there are only a few applications it isn’t too big of a deal, but if you have many applications and a lot of changes on the data side, it could be problematic to roll out updated versions and ensuring that you don’t break existing applications.
With WCF you can version services which will help to mitigate that risk. So in reality a lot of it depends on the number of consumers, location of the consumers (internal/external), and frequency of updates.
This is at least what I use when evaluating.