To wrap or not to wrap: wrap access to data on the service facade

Question

For a while, my team and I exchanged our level of data access on the front of the web service (using WCF) and calling it at the business logic level. Meanwhile, we could just use the repository template, where the business logic layer locally uses the data access level through the interface, and at any time we can disable it so that it hits the service instead (if necessary).

Question: when is the time to wrap the data access layer in the facade of the service and when is it not? Right now, it seems that the main advantage is that other applications can use this service, but if they are internal applications written in .NET, then they can just use the .NET assembly. Are there other advantages to having DAL wrapped in a service that I don't know about?

Answer 1

It really depends on how / how the data service will be used. If there are only a few applications, this is not a big deal, but if you have many applications and a lot of changes on the data side, there may be a problem with deploying updated versions and ensuring that you do not break existing applications.

With WCF, you can use version services to help mitigate this risk. Thus, in fact, a lot depends on the number of consumers, the location of consumers (internal / external) and the frequency of updates.

This is at least what I use in my assessment.