Почему разработчик должен использовать веб-службы вместо прямых подключений к db?

Я ищу список из десяти лучших причин, по которым мы должны подключаться к удаленным базам данных через веб-службу вместо прямого подключения к db. Это внутренняя дискуссия прямо сейчас, и я про-веб-сервис, но теряю аргумент. У меня есть базовое понимание WCF/веб-сервисов, никто другой не делает. Мы можем делать все, что хотим, двигаться вперед, но нам нужно придерживаться того, что мы выбираем сейчас.

Вот что я придумал. Не более?

Веб-службы WCF могут, если они настроены правильно, быть более безопасными.
Изменения в БД должны выполняться только на уровне обслуживания (файл конфигурации или перекомпилировать службу).
После настройки и размещения веб-сервисы легче потреблять.

Ответ 1

Безопасность. Вы не предоставляете доступ к БД никому, кроме пользователя веб-сервера/приложения.

Это особенно важно, когда у вас много пользователей. Вы избегаете боли обслуживания пользователя/роли на стороне БД.
Уменьшение нагрузки DB. Веб-служба может кэшировать данные, полученные из БД.
Возможность отказоустойчивости - услуга может переключаться между источниками первичных/DR-данных, не предоставляя потребителям информацию о сбое.
Масштабируемость - услуга может распространять запросы между несколькими параллельными источниками данных без того, чтобы детализация ресурсов была реализована потребителями услуг.
Герметизация
. Вы можете изменить базовую реализацию БД, не затрагивая пользователей услуг.
Обогащение данных (это включает в себя все: от настройки клиента до локализации до интернализации). В принципе, любой из них может быть полезен, но любой из них является большой нагрузкой на базу данных и часто очень сложно реализовать внутри БД.
Может или не может применяться к вам - некоторые решения по архитектуре не совместимы с БД. Например. Java-серверы, работающие в Unix, имеют легкий доступ к базе данных, тогда как java-клиент, работающий на ПК с ОС Windows, не знает базы данных и не хочет, чтобы это было.
портативность. Ваши клиенты могут не быть на одной платформе/архитектуре/языке. Повторное создание хорошего уровня доступа к данным в каждом из них сложнее (поскольку оно должно учитывать такие проблемы, как вышеупомянутые отказы /etc...), чем создание потребительского уровня для веб-службы.
Настройка производительности. Предполагая, что альтернатива - это клиенты, которые выполняют свои собственные запросы (а не предварительно консервированные хранимые процедуры), вы можете быть на 100% уверены, что они начнут использовать менее оптимальные запросы. Кроме того, если веб-служба ограничивает набор разрешенных запросов, это может значительно помочь в настройке базы данных. Я должен добавить, что эта логика в равной степени применима к хранимым процедурам, а не уникальным для веб-служб.

Хороший список также можно найти на этой странице: "Инкапсулирование доступа к базе данных: гибкая" лучшая" практика

Просто, чтобы быть кристально чистым - некоторые из этих проблем могут быть неприменимы ко всем ситуациям. Некоторые люди не заботятся о переносимости. Некоторым людям не нужно беспокоиться о безопасности БД. Некоторым людям не нужно беспокоиться о масштабируемости DB.

Ответ 2

По моему мнению, вы не должны автоматически публиковать свою базу данных в качестве веб-службы. Если окажется, что вам нужна услуга, чтобы разоблачить ваши данные, а затем напишите один, но не все доступ к базе данных должен выполняться через веб-службы.

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

Ответ 3

Веб-службы образуют API, определяя разрешенные взаимодействия между внешними системами и данными приложения.
Веб-службы отделяют базу данных от внешних взаимодействий и позволяют управлять уровнем данных независимо от внешних воздействий.
Разрешение доступа только через веб-службы гарантирует, что логика приложения получит возможность выполнить, защищая целостность данных.
Веб-службы позволяют принимать наиболее подходящие меры аутентификации/авторизации, в отличие от базы данных, требующей привилегий имени пользователя и пароля/табличного уровня.
Веб-службы предоставляют возможность автоматического обнаружения и настройки сервиса.
Трафик веб-сервисов может быть зашифрован для транзита через незащищенные сети. Не знаете каких-либо прямых решений для подключения к DB, которые позволяют это...?

Большинство из этих пунктов относятся к любому формальному API, а не к веб-службам.

Ответ 4

1) Головная боль поддержки базы данных снижается со стороны разработчиков, поэтому они могут сосредоточиться только на разработке.

2) Веб-сервис поддерживает связь различных платформ (операционных систем, таких как windows, ios, android и т.д.) очень простым и эффективным способом. например, рассмотрим ситуацию, когда приложение android и приложение ios хотят связываться с веб-сайтом, который основан на Java, поэтому для связи всех трех вещей вебсервис является лучшим решением вместо поддержки трех разных баз данных.

Ответ 5

Написание веб-службы, которая просто обертывает вызовы хранимых процедур, представляется ошибочным подходом к разработке хорошего DAL. Скорее всего, ваши хранимые процедуры - это устаревший код, оставшийся от более старых систем клиент-сервер, т.е. Бизнес-правила похоронены в SP. Если это случай, вы действительно пытаетесь создать шелковый кошелек из свиного уха.

Кроме того, вы добавляете уровень протокола SOAP-сообщений, который добавляет производительность в веб-приложения, которые были "принуждены" к датировке этой "свиньи". Я сейчас работаю над проектом, когда нашему новому приложению MVC-4 было дано указание использовать такой DAL. Мы вынуждены менять подпись WebMethod и подпись SP всякий раз, когда возникает новая история пользователей, требующая таких изменений; который для нас - это каждый спринт. В основе такого подхода - переход двух тесно связанных ярусов.

Ответ 6

В общем

Уровень веб-сервиса способствует повторному использованию общих запросов данных для нескольких приложений.
Web Service можно настроить с помощью управления версиями, что отклоняет многие проблемы, возникающие в результате разработки уровня приложения. Например, если я новичок в проекте, которое существующее приложение использует в качестве хорошей модели для настройки моего приложения для использования существующих источников базы данных.
Веб-служба развилась, чтобы позволить гибкие варианты отправки запросов и получения результатов ответа в общем формате, таких как JSON, с помощью простого URI, что означает что клиентские приложения могут быть разработаны с использованием более распространенного стандарта, который поощряет надежные однородные интерфейсы.

Я просто смотрю с ASP.NET Web Api и планирую сначала сделать службы данных.

Недавно я сосредоточился на веб-приложениях .NET MVC с использованием инфраструктуры сущности.

Если вы уже используете MVC, Web Api также использует MVC с контроллером Api, поэтому кривая обучения для создания сервисов довольно безболезненна.

Недавно я оказался в затруднительном положении с веб-приложением MVC, которое я строил изначально на основе хранимых процедур Oracle. Исходная версия в виде Oracle 9 или даже раньше, которая представила еще одну проблему с Visual Studio 2012, подталкивает более современный подход к подключению factory с сборками времени загрузки, которые ищут нужные DLL файлы для использования на основе соединений веб-конфигурации и имен TNS.

Попытки подключиться к базе данных не удались с сообщениями об ошибке "больше не поддерживаются". Из любопытства я загрузил Oracle 12c и сделал некоторые соединения на уровне приложений, которые хорошо работали с моими именами TNS и DLL сборки сборок, и я смог без проблем работать с Oracle.

Были созданы некоторые веб-службы, которые работали с подключениями к более старой версии Oracle. Они были построены с помощью методов, которые были специально сопоставлены с выбранными таблицами, но, к моему разочарованию. Я должен был написать свой собственный.

Мне сказали, что группа, ответственная за поддержание баз данных Oracle, будет писать новые хранимые процедуры для замены старых, которые я использовал для абстрактного интерфейса клиентского интерфейса и бизнес-логики.

Итак, мои первые мысли состояли в том, что все общие запросы данных, такие как заполнение выпадающего списка или автоматическое завершение с помощью данных масштаба предприятия, выполняются через службы данных, которые будут вызывать хранимые процедуры Oracle. Зачем повторять этот процесс над каждым приложением и бороться с каждым разработчиком с конфигурацией и сборкой версии/загрузки, проблемы с TNS?

так....

Для нескольких проблем с сервером базы данных, например, с использованием хранимых процедур Oracle в приложении .NET MVC, которые обычно могут использовать EF для использования данных SQL Server, почему бы не подтолкнуть эти головные боли к методам обслуживания Web Api, где эти проблемы конфигурации могут быть изолированы.
Снова взаимодействие с клиентом может быть выполнено с использованием JavaScript, JQuery и JSON, которые вы уже используете, если вы делаете это с помощью Web Api, чтобы делать запросы данных SQL Server.

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