Переноситься или не переноситься: обертывание доступа к данным в сервисном фасаде
Некоторое время теперь моя команда и я переносили наш уровень доступа к данным в фасад веб-сервиса (использующий WCF) и называющий его от слоя бизнес-логики. Между тем мы могли просто использовать шаблон репозитория, где слой бизнес-логики использует уровень доступа к данным локально через интерфейс, и в любом моменте времени, мы можем выключить вещи для него для удара сервиса вместо этого (при необходимости).
Вопрос: Когда это - хорошее время для обертывания уровня доступа к данным в сервисный фасад и когда не так ли? Прямо сейчас кажется, что основное преимущество состоит в том, что другие приложения могут использовать сервис, но если они - внутренние приложения, записанные в.NET затем, они могут просто использовать блок.NET вместо этого. Есть ли другие преимущества наличия DAL быть перенесенными в сервис, о котором я не знаю?
1 ответ
Это действительно зависит от того, что/как будет использоваться служба данных. Если есть только несколько приложений, то это не слишком большая проблема, но если у вас много приложений и много изменений на стороне данных, то может быть проблематично развернуть обновленные версии и гарантировать, что вы не сломаете существующие приложения.
С WCF вы можете создавать службы версий, которые помогут уменьшить этот риск. Так что в действительности многое зависит от количества потребителей, расположения потребителей (внутренние/внешние) и частоты обновлений.
Это, по крайней мере, то, что я использую при оценке.