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

Я шукаю "десятку" списку причин, чому нам слід підключатися до віддалених баз даних через веб-службу, а не безпосередньо підключатись до баз даних. Зараз це внутрішні дебати, і я про-веб-сервіс, але втрачаю аргумент. Я базово розуміюся на WCF / веб-сервісах, ніхто інший цього не знає. Ми можемо робити все, що хочемо, рухаючись вперед, але нам потрібно дотримуватися того, що ми обрали зараз.

Ось що я придумав. Більше?

1. Якщо веб-служби WCF правильно налаштовані, вони можуть бути більш безпечними.
2. Зміни в БД потрібно вносити лише на рівні сервісу (файл конфігурації або перекомпіляція служби).
3. Після налаштування та розміщення веб-служби легше споживати.

1. Безпека. Ви не надаєте доступ до БД нікому, крім веб-сервера / користувача програми.

   Це особливо важливо, коли у вас багато користувачів. Ви уникнете болю при підтримці користувача / ролі з боку БД.

2. Зниження навантаження БД. Веб-служба може кешувати дані, отримані з БД.

3. Пул підключення до бази даних (hat / tip @Dogs).

   Веб-служба може використовувати невеликий пул постійно відкритих з'єднань БД. Допомагає різними способами:

   • Пул підключень БД обмежений на стороні сервера баз даних.

   • відкриття нового з'єднання з БД ДУЖЕ дорого (особливо для сервера баз даних).

4. Можливість відмовостійкості - послуга може перемикатися між первинними джерелами даних / DR, не вимагаючи, щоб споживачі послуги реалізовували деталі перебоїв.

5. Масштабованість - служба може поширювати запити між кількома паралельними джерелами даних, не вимагаючи, щоб споживачі послуг реалізовували деталі вибору ресурсів.

6. Капсуляція. Ви можете змінити базову реалізацію БД, не впливаючи на користувачів послуг.

7. Збагачення даних (сюди входить що завгодно, від налаштування клієнта до локалізації та інтерналізації). В основному будь-який з них може бути корисним, але будь-який з них є значним навантаженням на базу даних і часто дуже важкий для реалізації всередині БД.

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

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

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

Хороший список також можна знайти на цій сторінці: "Інкапсулювання доступу до бази даних: гнучка" найкраща "практика"

Просто щоб бути кристально чистим - деякі з цих питань можуть бути не застосовними до ВСІХ ситуацій. Деякі люди не дбають про портативність. Деяким людям не потрібно турбуватися про безпеку БД. Деяким людям не потрібно турбуватися про масштабованість БД.

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

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

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

Більшість із цих пунктів стосуються будь-якого офіційного API, а не веб-служб.

Написання веб-служби, яка просто обертає виклики до збережених процедур, здається помилковим підходом до розробки належного DAL. Більш ймовірно, що ваші збережені процедури - це застарілий код, що залишився від старих систем клієнт-сервер, тобто ділові правила поховані в SP. Якщо це так, ви справді намагаєтесь створити шовкову гаманце з вуха свиноматки.

Більше того, ви додали рівень протоколу повідомлень SOAP, який додає показник продуктивності веб-програмам, які були «примусові» до датування цієї «свині». Зараз я працюю над проектом, де нашому новому додатку MVC-4 було наказано використовувати такий DAL. Ми маємо тягар необхідності змінювати як підпис WebMethod, так і підпис SP, коли з’являється нова історія користувача, що вимагає таких змін; що для нас - кожен спринт. Такому підходу до пастерів притаманні два тісно пов’язані рівні.

1) Головний біль ведення бази даних зменшується з боку розробників, так що вони можуть зосередитись лише на розробці.

2) Веб-служба підтримує зв'язок різних платформ (операційних систем, таких як Windows, iOS, Android тощо) дуже простим та ефективним методом. наприклад, розглянемо ситуацію, коли додаток android і додаток ios хочуть зв’язатись із веб-сайтом, який базується на Java, тож для спілкування всіх трьох речей веб-сервіс є найкращим рішенням замість ведення трьох різних баз даних.

В загальному

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

Я просто вдивляюся в ASP.NET Web Api і планую зробити послуги передачі даних першими.

Нещодавно я зосередився на веб-програмах .NET MVC із використанням сутності.

1. Якщо ви вже використовуєте MVC, веб-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.

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