Обернуть или не обернуть: обертывание доступа к данным на фасаде службы

Question

Некоторое время мы с моей командой оборачиваем наш слой доступа к данным в фасад веб-службы (используя WCF) и вызываем его из уровня бизнес-логики. Между тем, мы могли бы просто использовать шаблон репозитория, где уровень бизнес-логики потребляет уровень доступа к данным локально через интерфейс, и в любой момент времени мы можем переключиться, чтобы он вместо этого попал в службу (при необходимости).

Вопрос в том, когда самое подходящее время обернуть слой доступа к данным в фасаде сервиса, а когда нет? В настоящее время кажется, что главное преимущество заключается в том, что другие приложения могут использовать эту услугу, но если они являются внутренними приложениями, написанными на .NET, они могут вместо этого просто использовать сборку .NET. Существуют ли другие преимущества того, что DAL будет включен в службу, о которой я не знаю?

Answer 1

Это действительно зависит от того, каким образом / как будет использоваться служба данных. Если есть только несколько приложений, это не так уж сложно, но если у вас много приложений и много изменений на стороне данных, может быть проблематично выкатить обновленные версии и убедиться, что вы не сломаете существующие приложения.

С WCF вы можете создавать версии сервисов, которые помогут снизить этот риск. Так что в действительности многое зависит от количества потребителей, местоположения потребителей (внутренних / внешних) и частоты обновлений.

Это как минимум то, что я использую при оценке.