Почему разработчик должен использовать веб-службы вместо прямого подключения к БД? [закрытый]
Я ищу" десятку " причин, по которым мы должны подключаться к удаленным базам данных через веб-сервис вместо прямого подключения к БД. Это внутренние дебаты прямо сейчас, и я про-веб-сервис, но теряю аргумент. У меня есть базовое представление о WCF / веб-службах, никто другой не делает. Мы можем делать все, что мы хотим двигаться вперед, но мы должны придерживаться того, что мы выбираем сейчас.
вот что я придумал. Еще есть?
- WCF web при правильной настройке службы могут быть более безопасными.
- изменения в БД необходимо вносить только на уровне службы (файл конфигурации или служба перекомпиляции).
- после установки и размещения веб-службы легче использовать.
6 ответов:
безопасность. Вы не предоставляете доступ к БД никому, кроме пользователя веб-сервера / приложения.
Это очень важно, когда у вас есть тонны пользователей. Вы избегаете боли обслуживания пользователя / роли на стороне БД.
уменьшение нагрузки DB. Веб-служба может кэшировать данные полученные из БД.
способность к отказоустойчивости-служба может переключаться между первичными / DR источниками данных без подробных сведений о сбое реализовано потребителями услуг.
масштабируемость-служба может распределять запросы между несколькими параллельными источниками данных, не имея сведений о выборе ресурсов, реализуемых потребителями услуг.
инкапсуляция. Вы можете изменить базовую реализацию БД, не влияя на пользователей службы.
обогащение данных (это включает в себя все, от настройки клиента до локализации и интернализации). В основном любой из них может быть полезен, но любой из них является основной нагрузкой на базу данных и часто очень трудно реализовать внутри БД.
может или не может применяться к вам-некоторые архитектурные решения не являются дружественными для доступа к БД. Например, серверы Java, работающие на Unix, имеют легкий доступ к базе данных, в то время как клиент java, работающий на ПК с Windows, не знает базы данных, и вы, возможно, не хотите, чтобы это было.
переносимость. Ваши клиенты могут быть не все включены та же платформа/архитектура/язык. Воссоздание хорошего уровня доступа к данным в каждом из них сложнее (поскольку он должен учитывать такие проблемы, как вышеупомянутые сбои/и т. д...) чем создание потребительского слоя для веб-сервиса.
настройки производительности. Если альтернатива есть клиенты под свои запросы (а не предварительно хранимые процедуры), вы можете быть на 100% уверены, что они начнут использовать неоптимальных запросов. Кроме того, если веб-служба ограничивает набор допустимых запросов, это может помочь с настройкой базы данных значительно. Я должен добавить, что эта логика одинаково применима к хранимым процедурам, а не только к веб-службам.
хороший список также можно найти на этой странице: 'инкапсуляция доступа к базе данных: гибкая" Лучшая "практика'
просто чтобы быть кристально ясным-некоторые из этих вопросов могут быть применимы не ко всем ситуациям. Некоторые люди не заботятся о переносимости. Некоторые людям не нужно беспокоиться о безопасности БД. Некоторым людям не нужно беспокоиться о масштабируемости БД.
на мой взгляд, вы не должны автоматически предоставлять свою базу данных в качестве веб-службы. Если окажется, что вам нужна служба для предоставления ваших данных, то напишите ее, но не весь доступ к базе данных должен осуществляться через веб-службы.
- нет причин, по которым соединение с базой данных не должно быть безопасным
- вы можете инкапсулировать базу данных на уровне доступа к данным (возможно, Entity Framework)
- веб-службы не легче использовать, чем хорошо написанный уровень доступа к данным.
- веб-службы формируют API, определяющий допустимые взаимодействия между внешними системами и данными приложения.
- веб-службы отделяют базу данных от внешних взаимодействий и позволяют управлять уровнем данных независимо от внешних воздействий.
- разрешение доступа только с помощью веб-служб гарантирует, что логика приложения получает возможность выполнять, защищая целостность данных.
- веб-службы позволяют наиболее подходящий меры аутентификации/авторизации должны быть приняты, в отличие от базы данных, требующей имени пользователя и пароля / привилегий уровня таблицы.
- веб-службы предоставляют возможность использовать автоматическое обнаружение и настройку служб.
- трафик веб-служб может быть зашифрован для передачи по незащищенным сетям. Не знаю никаких решений прямого подключения к БД, которые позволяют это сделать...?
большинство из этих пунктов относятся к любому формальному API, а не конкретно сетевые сервисы.
написание веб-службы, которая просто обертывает вызовы хранимых процедур, кажется ошибочным подходом к разработке хорошего DAL. Скорее всего, ваши хранимые процедуры являются унаследованным кодом, оставшимся от старых клиент-серверных систем, т. е. бизнес-правила похоронены в SPs. Если это так, вы действительно пытаетесь создать Шелковый кошелек из МО.
кроме того, вы добавляете уровень протокола сообщений SOAP, который добавляет хит производительности в веб-приложения, которые были "принудили" к свиданию с этой "свиньей". Я работаю над проектом прямо сейчас, где наше новое приложение MVC-4 было проинструктировано использовать такой DAL. У нас есть бремя необходимости изменять как подпись WebMethod, так и подпись SP всякий раз, когда появляется новая история пользователя, требующая таких изменений; что для нас-это каждый спринт. Присущи такому подходу пасстру два тесно связанных яруса.
1)головная боль поддержания базы данных уменьшается со стороны разработчиков, так что они могут сосредоточиться только на разработке.
2)веб-сервис поддерживает взаимодействие разных платформ (операционных систем, таких как Windows,iOS и Android) в очень простой и эффективный способ. например, рассмотрим ситуацию, когда приложение android и приложение ios хотят общаться с веб-сайтом, который основан на java, поэтому для связи всех трех вещей webservice является лучшим решением вместо того, чтобы поддерживать три разные базы данных.
В общем
- уровень веб-службы способствует повторному использованию общих запросов данных для нескольких приложений
- веб-служба может быть настроена с управлением версиями, которое отклоняет многие вопросы, возникающие при разработке на уровне приложений. Например, если я новичок в проекте, которое существующее приложение я использую в качестве хорошей модели для настройки моего приложения для использования существующих источников базы данных.
- веб-служба эволюционировала, чтобы обеспечить гибкие возможности для отправки запросы и получение результатов ответа в общем формате, таком как JSON, с помощью простого URI, что означает что клиентские приложения могут быть разработаны с использованием более общего стандарта, который поощряет надежные унифицированные интерфейсы.
Я просто смотрю с ASP.NET веб-Api и план по созданию служб данных в первую очередь.
недавно я сосредоточился на веб-приложениях .NET MVC с использованием Entity framework.
- Если вы уже используете MVC веб-Api также использует MVC с контроллером Api, поэтому кривая обучения для создания служб довольно безболезненна.
недавно я оказался в неприятном положении с веб-приложением MVC, которое я создавал первоначально на основе хранимых процедур Oracle. Оригинальная версия как Oracle 9 или даже раньше, которая представила еще одну проблему с Visual Studio 2012, подталкивая более современный подход к фабрике соединений с сборками времени загрузки, находя правильные dll-файлы для используйте на основе подключений web config и имен TNS.
попытки подключения к базе данных завершились неудачей с сообщениями об ошибке "больше не поддерживается". Из любопытства я загрузил Oracle 12c и сделал некоторые соединения на уровне приложений, которые хорошо работали с моими именами TNS и dll сборки загрузки, и я смог работать с Oracle без проблем.
были построены некоторые веб-службы, которые работали с подключениями к более старой версии Oracle. Они были построены с помощью методов это были специально сопоставлены с выбранными таблицами, однако к моему разочарованию. Я должен был бы написать свой собственный.
Мне сказали, что группа, которая отвечала за поддержание баз данных Oracle, что они будут писать новые хранимые процедуры, чтобы заменить старые, которые я использовал для абстракции клиентского интерфейса и бизнес-логики слоев.
Итак, мои первые мысли были о том, что все общие запросы данных, такие как заполнение выпадающего списка или автоматическое завершение с общеорганизационными данными можно работать через службы данных,которые будут вызывать хранимые процедуры Oracle. Зачем повторять этот процесс над каждым приложением и заставлять каждого разработчика бороться с конфигурацией и сборкой версии/загрузки, проблемами TNS?
Так....
- для нескольких проблем сервера баз данных, таких как использование хранимых процедур Oracle в приложении .NET MVC, которое обычно может использовать EF для использования данных SQL Server, почему бы не поднять эти головные боли до веб-Api методы обслуживания, где эти проблемы конфигурации могут быть изолированы.
- снова клиентский интерфейс может быть выполнен с использованием JavaScript, JQuery и JSON, которые вы уже используете, если вы делаете это с помощью веб-Api для выполнения запросов данных SQL Server.
Я разработчик приложений / аналитик, а не DBA, поэтому моя перспектива-это опыт с бесконечным разочарованием от необходимости постоянно изменять приложения, когда инструменты базы данных развиваются.