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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В общем

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.

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