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

94

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

Вот что я придумал. Больше?

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

Ответы:

120

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

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

  2. Снижение нагрузки на БД. Веб-сервис может кэшировать данные, полученные из БД.

  3. Пул соединений с базой данных (шляпа / совет @Dogs).

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

    • Пул соединений с БД ограничен на стороне сервера базы данных.

    • открытие нового соединения с БД ОЧЕНЬ дорого (особенно для сервера базы данных).

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

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

  6. Инкапсуляция. Вы можете изменить базовую реализацию БД, не затрагивая пользователей службы.

  7. Обогащение данных (это включает в себя все, от настройки клиента до локализации и интернализации). В принципе, любой из них может быть полезен, но любой из них представляет собой серьезную нагрузку на базу данных и часто очень трудно реализовать в базе данных.

  8. Может или не может относиться к вам - некоторые архитектурные решения не подходят для доступа к БД. Например, серверы Java, работающие в Unix, имеют легкий доступ к базе данных, тогда как клиент Java, работающий на ПК с Windows, не поддерживает базы данных, и вы, возможно, этого не хотите.

  9. Переносимость. Не все ваши клиенты работают на одной платформе / архитектуре / языке. Воссоздать хороший уровень доступа к данным в каждом из них сложнее (поскольку он должен учитывать такие проблемы, как вышеупомянутые отказы и т. Д.), Чем создание потребительского уровня для веб-службы.

  10. Настройка производительности. Предполагая, что альтернативой являются клиенты, выполняющие свои собственные запросы (а не заранее подготовленные хранимые процедуры), вы можете быть на 100% уверены, что они начнут использовать менее оптимальные запросы. Кроме того, если веб-служба ограничивает набор допустимых запросов, это может значительно помочь в настройке вашей базы данных. Я должен добавить, что эта логика в равной степени применима к хранимым процедурам, а не только к веб-службам.

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

Чтобы быть предельно ясным - некоторые из этих проблем не могут быть применимы ко ВСЕМ ситуациям. Некоторых людей не волнует переносимость. Некоторым людям не нужно беспокоиться о безопасности БД. Некоторым людям не нужно беспокоиться о масштабируемости БД.

ДВК
источник
26
Извините, не согласен. 1. Таким образом, вы предоставляете доступ к БД группе, а не одному принципалу - без разницы. 2. Любое приложение может кэшировать данные. Типы данных, которые могут быть кэшированы несколькими пользователями, в любом случае обычно являются данными небольшого объема. 3. FT в любом случае должна обрабатываться базой данных. 4. Это не готовая функция, и ее нужно программировать. 5. Ваш уровень доступа к данным должен выполнять инкапсуляцию. 6. То же самое. 7. Правда? JDBC не работает в клиенте? 8. Хороший момент, когда это имеет значение, что бывает редко. 9. Запрос против SP не входил в вопрос.
Джон Сондерс,
7
1. Попробуйте управлять этим для 5000 пользователей с сотнями ролей. Больше не масштабируется так хорошо. 2. Полностью зависит от приложения. В нашем текущем случае есть пример кеширования результатов запроса, который в случае сверхоптимизированной обработки занимает 20 минут и который нам нужно запускать 100 раз в день, по крайней мере, из разных приложений. 3. FT обрабатывается на нескольких уровнях. Что вы имеете в виду, "должна обрабатывать база данных"?
DVK
4
4. Конечно, это нужно запрограммировать. Но его можно запрограммировать в сервисе один раз или в миллиард клиентских приложений на различных платформах с разными возможностями. Есть большая разница. Забудьте о проблемах управления конфигурацией для балансировки нагрузки. 5. Те же рассуждения. Вам не нужно повторно внедрять DAL. На самом деле, вы можете просто думать о веб-сервисе как о портативном DAL, чтобы упростить себе жизнь. 7. Мы не хотим, чтобы каждый клиент открывал соединения с БД. Разве это такая большая просьба? Опять же, вы забываете пункты 1–5.
DVK
2
8.> 1 клиентская архитектура бывает ОЧЕНЬ часто. На самом деле я никогда не работал над проектом без такой ситуации в моей жизни, но я сосредоточен на финансовом мире. 9. Не было. По сути, я играл адвоката дьявола.
DVK
2
Мне нравится этот ответ, но я думаю, вы пропустили один из самых важных моментов: пул соединений. Если у вас 1 000 000 клиентов, у вас будет либо 1 000 000 открытых соединений, либо миллионы соединений, которые постоянно открываются и закрываются. Базовое интуитивное представление об организации компьютера подсказывает нам, что хорошо настроенный пул из пары сотен долгоживущих соединений астрономически более эффективен, чем наличие миллиона долгоживущих или миллионов короткоживущих соединений. HikariCP прекрасно развивает эту идею: github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
Dogs
15

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

  1. Нет причин, по которым соединение с базой данных не должно быть безопасным
  2. Вы можете инкапсулировать базу данных на уровне доступа к данным (возможно, Entity Framework)
  3. Использовать веб-службы не легче, чем хорошо написанный уровень доступа к данным.
Джон Сондерс
источник
Почему обязательно XML? Также гораздо легче разбирать JSON, CSV на простые плоские данные и т. Д.
DVK
Это не «без уважительной причины». Как уже отмечалось, в зависимости от ваших требований и желаний для будущего развития это может быть необходимо для вашего проекта.
Крис Стюарт,
Я пишу свой WS, чтобы использовать DAL. На каком порту вы бы посоветовали выставить DAL?
samis
@samus это не имеет значения.
Джон Сондерс
«Нет причин, по которым соединение с базой данных не должно быть безопасным», ну, например, сложно защитить соединение между клиентом Windows и базой данных. Реально сложно реализовать безопасное соединение!
NoChance 01
12
  • Веб-службы образуют API, определяя разрешенные взаимодействия между внешними системами и данными приложения.
  • Веб-службы отделяют базу данных от внешних взаимодействий и позволяют управлять уровнем данных независимо от этих внешних воздействий.
  • Разрешение доступа только для веб-служб обеспечивает возможность выполнения логики приложения, защищая целостность данных.
  • Веб-службы позволяют принимать наиболее подходящие меры аутентификации / авторизации, в отличие от базы данных, требующей имени пользователя и пароля / привилегий уровня таблицы.
  • Веб-службы предоставляют возможность использования автоматического обнаружения и настройки служб.
  • Трафик веб-служб может быть зашифрован для передачи по незащищенным сетям. Не знаете ни одного решения для прямого подключения к БД, которое позволяет это ...?

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

хвастун
источник
1
Да, это то, что я собирался сказать, если у вас есть одно приложение, обращающееся к базе данных, все ваши баллы доступны и для обычных API.
Игнасио Солер Гарсия
«Веб-службы образуют API, определяя разрешенные взаимодействия между внешними системами и данными приложения». Вы можете сделать это и с базой данных.
Shoe
«Разрешение доступа только для веб-служб обеспечивает возможность выполнения логики приложения, защищая целостность данных». - Я бы сказал, что целостность данных должна быть частью только СУБД.
Shoe
@Shoe Приятно обеспечить максимально возможную целостность в БД, но по мере того, как данные начинают накапливаться и обнаруживать недостатки, такие как необходимость некоторой проверки ввода, приятно применять это на уровне приложения (хотя я, например, предпочитаю применять на стороне клиента, иногда с этим нужно иметь дело на стороне сервера, если правила проверки зависят от данных, известных только серверу (хранимых из клиентского приложения)). Насколько сложно изменить набор правил целостности БД, я полагаю, это нетривиальный вопрос?
samis
2

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

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

Севасанакид
источник
1
Веб-API решил проблему раздувания WCF / SOAP. Теперь он похож на легкого, подтянутого, ловкого кота; именно то, что нужно для RESTful служить.
samis
Теоретически, вызывать хранимые процессы с помощью веб-сервисов - это нормально.
NoChance 01
2

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

2) Веб-сервис поддерживает связь различных платформ (операционных систем, таких как Windows, iOS, Android и т. Д.) Очень простым и эффективным способом. Например, рассмотрим ситуацию, когда приложение Android и приложение iOS хотят связаться с веб-сайтом, который основан на java, поэтому для связи всех трех вещей веб-сервис является лучшим решением вместо обслуживания трех разных баз данных.

Рохан
источник
1

В общем

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

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

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

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

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

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

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

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

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

так....

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

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

Брайан Куинн
источник