Dlaczego programista miałby używać usług internetowych zamiast bezpośrednich połączeń z bazą danych? [Zamknięte]

Szukam listy „dziesięciu najważniejszych” powodów, dla których powinniśmy łączyć się ze zdalnymi bazami danych za pośrednictwem usługi internetowej zamiast bezpośrednio łączyć się z bazą danych. To jest teraz wewnętrzna debata i jestem zwolennikiem usług internetowych, ale przegrywam. Mam podstawowe pojęcie o WCF / usługach internetowych, nikt inny tego nie robi. Możemy robić, co nam się podoba, ale musimy trzymać się tego, co teraz wybierzemy.

Oto, co wymyśliłem. Coś więcej?

1. Usługi sieci Web WCF, jeśli są poprawnie skonfigurowane, mogą być bezpieczniejsze.
2. Zmiany w bazie danych należy wprowadzać tylko na poziomie usługi (plik konfiguracyjny lub usługa rekompilacji).
3. Po skonfigurowaniu i umieszczeniu na serwerze usługi internetowe są łatwiejsze w użyciu.

1. Bezpieczeństwo. Nie przyznajesz dostępu do bazy danych nikomu poza użytkownikiem serwera internetowego / aplikacji.

   Jest to szczególnie ważne, gdy masz mnóstwo użytkowników. Unikniesz bólu związanego z utrzymaniem użytkownika / roli po stronie DB.

2. Redukcja obciążenia DB. Usługa internetowa może buforować dane pobrane z bazy danych.

3. Pule połączeń z bazą danych (hat / tip @Dogs).

   Usługa internetowa może korzystać z małej puli trwale otwartych połączeń DB. Pomaga na różne sposoby:

   • Pula połączeń DB jest ograniczona po stronie serwera bazy danych.

   • otwarcie nowego połączenia DB jest BARDZO kosztowne (szczególnie w przypadku serwera bazy danych).

4. Zdolność do odporności na awarie - usługa może przełączać się między źródłami danych pierwotnych / DR bez konieczności implementacji szczegółów przełączania awaryjnego przez odbiorców usług.

5. Skalowalność - usługa może rozprowadzać żądania między kilkoma równoległymi źródłami danych bez konieczności implementacji szczegółów dotyczących wybierania zasobów przez odbiorców usług.

6. Kapsułkowanie. Możesz zmienić podstawową implementację bazy danych bez wpływu na użytkowników usług.

7. Wzbogacanie danych (obejmuje wszystko, od dostosowywania klienta, przez lokalizację, po internalizację). Zasadniczo każdy z nich może być przydatny, ale każdy z nich powoduje duże obciążenie bazy danych i często jest bardzo trudny do zaimplementowania w bazie danych.

8. Może lub nie dotyczy Ciebie - niektóre decyzje dotyczące architektury nie są przyjazne dla DB. Np. Serwery Java działające w systemie Unix mają łatwy dostęp do bazy danych, podczas gdy klient java działający na komputerze z systemem Windows nie zna bazy danych i prawdopodobnie tego nie chcesz.

9. Ruchliwość. Twoi klienci mogą nie być na tej samej platformie / architekturze / języku. Odtworzenie dobrej warstwy dostępu do danych w każdym z nich jest trudniejsze (ponieważ musi uwzględniać takie kwestie, jak wspomniane powyżej przełączenia awaryjne itp.) Niż budowanie warstwy konsumenckiej dla usługi internetowej.

10. Podnoszenie wydajności. Zakładając, że alternatywą są klienci uruchamiający własne zapytania (a nie wstępnie przygotowane procedury składowane), można mieć 100% pewności, że zaczną używać mniej niż optymalnych zapytań. Ponadto, jeśli usługa sieciowa ogranicza zestaw dopuszczalnych zapytań, może znacznie pomóc w dostrojeniu bazy danych. Muszę dodać, że ta logika ma zastosowanie w równym stopniu do procedur składowanych, a nie tylko do usług internetowych.

Dobrą listę można również znaleźć na tej stronie: „Hermetyzacja dostępu do bazy danych: zwinna„ najlepsza ”praktyka”

Dla jasności - niektóre z tych problemów mogą nie dotyczyć WSZYSTKICH sytuacji. Niektórym nie zależy na przenośności. Niektórzy ludzie nie muszą się martwić o bezpieczeństwo bazy danych. Niektórzy ludzie nie muszą się martwić skalowalnością bazy danych.

Moim zdaniem nie powinieneś automatycznie ujawniać swojej bazy danych jako usługi internetowej. Jeśli okaże się, że potrzebujesz usługi do ujawnienia danych, napisz ją, ale nie cały dostęp do bazy danych powinien odbywać się za pośrednictwem usług internetowych.

1. Nie ma powodu, dla którego połączenie z bazą danych nie powinno być bezpieczne
2. Możesz hermetyzować bazę danych w warstwie dostępu do danych (prawdopodobnie Entity Framework)
3. Usługi sieciowe nie są łatwiejsze w użyciu niż dobrze napisana warstwa dostępu do danych.

• Usługi sieciowe tworzą interfejs API, definiując dozwolone interakcje między systemami zewnętrznymi a danymi aplikacji.
• Usługi sieciowe oddzielają bazę danych od interakcji zewnętrznych i umożliwiają zarządzanie warstwą danych niezależnie od wpływów zewnętrznych.
• Zezwolenie na dostęp tylko przez usługi sieci Web zapewnia, że ​​logika aplikacji ma szansę na wykonanie, chroniąc integralność danych.
• Usługi sieci Web pozwalają na podjęcie najbardziej odpowiednich środków uwierzytelniania / autoryzacji, w przeciwieństwie do bazy danych wymagającej nazwy użytkownika i hasła / uprawnień na poziomie tabeli.
• Usługi sieci Web zapewniają możliwość automatycznego wykrywania usług i ich konfiguracji.
• Ruch usług internetowych może być szyfrowany w celu przesyłania przez niezabezpieczone sieci. Nie znasz żadnych bezpośrednich rozwiązań połączeń DB, które umożliwiają ...?

Większość z tych punktów dotyczy dowolnego formalnego interfejsu API, a nie konkretnie usług sieciowych.

Pisanie usługi sieci Web, która po prostu opakowuje wywołania do procedur składowanych, wydaje się być błędnym podejściem do projektowania dobrego DAL. Najprawdopodobniej twoje procedury składowane są starszym kodem pozostałym ze starszych systemów klient-serwer, tj. Reguły biznesowe są ukryte w SP. Jeśli tak jest, to naprawdę próbujesz stworzyć jedwabną torebkę z ucha lochy.

Co więcej, dodajesz warstwę protokołu komunikatów SOAP, która zwiększa wydajność aplikacji internetowych, które zostały „zmuszone” do umawiania się z tą „świnią”. Pracuję teraz nad projektem, w którym nasza nowa aplikacja MVC-4 została poinstruowana, aby używać takiego DAL. Jesteśmy obciążeni koniecznością zmiany zarówno sygnatury WebMethod, jak i sygnatury SP za każdym razem, gdy pojawia się nowa historia użytkownika, wymagająca takich zmian; który dla nas jest każdym sprintem. Nieodłącznym elementem takiego podejścia pośredniego są dwa ściśle powiązane poziomy.

1) Ból głowy związany z utrzymaniem bazy danych jest zmniejszony po stronie programistów, dzięki czemu mogą skupić się tylko na rozwoju.

2) Usługa internetowa obsługuje komunikację różnych platform (systemów operacyjnych takich jak Windows, iOS, Android itp.) W bardzo łatwy i efektywny sposób. na przykład rozważ sytuację, w której aplikacja Android i aplikacja iOS chcą komunikować się ze stroną internetową opartą na Javie, więc najlepszym rozwiązaniem jest komunikacja wszystkich trzech rzeczy, zamiast utrzymywania trzech różnych baz danych.

Ogólnie

1. Poziom usługi sieci Web promuje ponowne wykorzystanie typowych żądań danych dla wielu aplikacji
2. Usługa sieciowa może być skonfigurowana z zarządzaniem wersjami, które rozwiązuje wiele problemów wynikających z rozwoju na poziomie aplikacji. Na przykład, jeśli jestem nowy w projekcie, którego istniejącej aplikacji używam jako dobrego modelu do konfigurowania mojej aplikacji do korzystania z istniejących źródeł bazy danych.
3. Usługa sieci Web ewoluowała, aby umożliwić elastyczne opcje wysyłania żądań i otrzymywania wyników odpowiedzi z powrotem we wspólnym formacie, takim jak JSON, przy użyciu prostego identyfikatora URI, co oznacza, że ​​aplikacje klienckie można tworzyć przy użyciu bardziej powszechnego standardu, który zachęca do niezawodnych, jednolitych interfejsów.

Właśnie zaczynam przygodę z ASP.NET Web Api i planuję najpierw stworzyć usługi danych.

Ostatnio skupiam się na aplikacjach internetowych .NET MVC z wykorzystaniem frameworka jednostki.

1. Jeśli korzystasz już z MVC, Web Api również używa MVC z kontrolerem API, więc krzywa uczenia się tworzenia usług jest dość bezbolesna.

Niedawno znalazłem się w frustrującej sytuacji z aplikacją internetową MVC, którą tworzyłem pierwotnie w oparciu o procedury składowane Oracle. Oryginalna wersja jako Oracle 9 lub nawet wcześniejsza, która przedstawiała inny problem z programem Visual Studio 2012, który wypychał bardziej nowoczesne podejście do fabryki połączeń z zestawami czasu ładowania znajdującymi odpowiednie pliki dll do użycia na podstawie połączeń konfiguracji sieci Web i nazw TNS.

Próby połączenia z bazą danych nie powiodły się i wyświetlają się komunikaty o błędach „nie są już obsługiwane”. Z ciekawości pobrałem Oracle 12c i utworzyłem kilka połączeń na poziomie aplikacji, które dobrze działały z moimi nazwami TNS i biblioteką DLL zestawu ładowania i mogłem bez problemu pracować z Oracle.

Powstało kilka usług internetowych, które współpracowały z połączeniami ze starszą wersją Oracle. Zostały zbudowane przy użyciu metod, które zostały specjalnie zmapowane do wybranych tabel, jednak ku mojemu rozczarowaniu. Musiałbym napisać własne.

Powiedziano mi, że grupa odpowiedzialna za utrzymanie baz danych Oracle będzie pisać nowe procedury składowane, aby zastąpić starsze, których używałem do wyodrębnienia interfejsu klienta i warstw logiki biznesowej.

W pierwszej chwili pomyślałem, że wszystkie typowe żądania danych, takie jak wypełnianie listy rozwijanej lub automatyczne uzupełnianie danych w całym przedsiębiorstwie, są wykonywane za pośrednictwem usług danych, które nazywają się procedurami składowanymi Oracle. Po co powtarzać ten proces dla każdej aplikacji i mieć każdego programistę z problemami z konfiguracją i wersją / obciążeniem oraz problemami z TNS?

więc....

1. W przypadku problemów z wieloma serwerami baz danych, takich jak korzystanie z procedur składowanych Oracle w aplikacji .NET MVC, która zazwyczaj może używać EF do wykorzystania danych programu SQL Server, dlaczego nie przesuwać tych problemów do metod usługi Web Api, w których te problemy z konfiguracją można odizolować.
2. Ponownie, interfejs klienta można wykonać za pomocą JavaScript, JQuery i JSON, których już używasz, jeśli robisz to za pomocą Web Api do wysyłania żądań danych SQL Server.

Jestem programistą / analitykiem aplikacji, a nie administratorem bazy danych, więc moja perspektywa wynika z doświadczenia i niekończącej się frustracji związanej z koniecznością ciągłego modyfikowania aplikacji, gdy rozwijają się narzędzia bazy danych.