Android 앱의 관계형 데이터베이스에 직접 액세스하는 대신 웹 서비스를 사용해야하는 이유는 무엇입니까?

웹에서 원격 위치의 중앙 데이터베이스에 효율적으로 액세스하는 방법을 검색했으며 데이터베이스에 대한 직접 액세스 (예 : JDBC 등) 대신 웹 서비스를 사용하라는 제안을 만났습니다. 그 이유와 다른 제안이 궁금합니다. .

database android web-services

— 예일 달
소스

답변:

웹 서비스 계층을 추가하면 필요한 CPU 성능과 처리 중에 사용 된 대역폭 측면에서 클라이언트를 더 가볍게 만들 수 있습니다. 두 가지 요소 모두 최종 사용자에게 매우 중요합니다.

CPU를 적게 사용하면 배터리 수명이 길어지고
더 적은 대역폭을 사용하면 요금제를 사용하는 사용자에 대한 월별 지불이 줄어 듭니다.

웹 애플리케이션 계층을 도입하면 대량의 처리를 휴대용 모바일 저전력, 저 대역폭, 저 메모리 클라이언트에서 메모리 용량이 큰 플러그 인 고전력 고 대역폭 서버로 이동 요구-처리 및 통신 비용이 클라이언트에 비해 훨씬 적은 비용의 환경.

그러나 시스템을 분리함으로써 비즈니스 규칙, 데이터베이스의 구조 및 존재하는 버전을보다 강력하게 제어 할 수 있습니다. 모바일 클라이언트가 데이터베이스에 직접 연결하게되면 디자인이 해당 데이터베이스 구조와 "결혼"됩니다. 거의 모든 변경 사항으로 인해 클라이언트와의 호환성이 깨져서 앱 업그레이드가 꺼려 질 수 있습니다.

반면 사이에 웹 서비스를 추가하면 관리하기 쉬운 방식으로 인터페이스를 모바일 클라이언트로 발전시킬 수 있습니다. 예를 들어, 기존 인터페이스를 그대로 유지하고 "병렬"로 작동하는 새로운 인터페이스를 추가 한 다음 완전히 단일 클라이언트를 손상시키지 않고 데이터베이스를 재구성하십시오.

웹 서비스를 디자인하는 동안 꽤 기본적인 디자인 원칙을 따르는 경우, 배치 된 성숙한 서버 측 인프라를 재사용함으로써 상당한 이점을 얻을 수 있습니다. 예를 들어, 캐시 및 프록시 서비스를 무료로받을 수 있습니다.

마지막으로, 이것은 당신이 스스로 서비스 할 수없는 플랫폼에 응용 프로그램을 노출시키는 다른 개발자에게 문을 열어 궁극적으로 회사의 이점을 발휘할 것입니다.

— Dasblinkenlight
소스

"필요한 CPU 성능과 처리 중 사용 된 대역폭의 측면에서"는 제가 찾고 있던 핵심이었습니다. 감사합니다

— yesildal

또한 앱이 데이터베이스와 직접 통신하는 경우 데이터베이스의 모든 테이블을 삭제하는 사람과는 역 컴파일러 일뿐입니다. 웹 응용 프로그램을 사용하면 훨씬 세밀한 제어를 사용하고 이와 같은 작업을 중지 할 수 있습니다.

— Earlz

@Earlz : 웹 응용 프로그램에 기꺼이 그렇게하지는 않지만 대부분의 데이터베이스 서버에는 견고하고 세분화 된 권한이 있습니다. 테이블 삭제 권한이있는 웹 사용자에게는 변명이 없습니다.

— Wyatt Barnett

@WyattBarnett OK ... 저장 프로 시저 등이 없으면 사용자가 어떻게 사용자 프로필을 업데이트 할 수 있습니까? USERS 테이블에 대한 읽기 / 쓰기 권한 ... 행이 아닌 행을 삭제하거나 편집하지 못하게하거나 행이 아닌 행을 읽지 못하게하는 원인 저장 프로시 저나 그와 같은 일부를 사용하지 않고는 데이터베이스 서버에 이런 종류의 세부 사항이없는 것이 확실합니다.

— Earlz

@Earlz-내가 아는 것은 아니지만 요점입니다. 왜 데이터베이스와 직접 대화하고 데이터베이스 기능을 고의로 무시하여 제대로 만들 수 있습니까? 그리고 프로파일 중심의 작업을 하고이 방법으로 무거운 것을 업데이트 하시겠습니까?

— Wyatt Barnett

앱과 DB 사이에 추상화 계층을 배치합니다. 이것은 다음과 같은 많은 장점을 제공합니다.

앱에 필요한 부분으로 만 DB에 대한 액세스를 제한합니다. 둘 다 앱의 코드를 단순화하고 DB를 안전하게 유지합니다.
DB의 내부 작업을 요약하므로 나중에 스키마, 쿼리 또는 전체 데이터베이스를 변경하기로 결정한 경우 중간 계층을 올바르게 유지하는 한 앱에 대한 링크가 끊어지지 않습니다.
DB 범위 밖에서 기능을 추가 할 수 있습니다. 예를 들어 상당히 일정한 데이터 캐싱 비즈니스 규칙은 DB와 떨어져 있어야 하는 또 다른 부분입니다 .

— 시스템 다운
소스

또 다른 장점은 캐시를 클라이언트 측 또는 서버 측 (또는 다른 목적으로)에 추가 할 수 있다는 것입니다.

— TMN

@TMN-좋은 지적입니다!

— 시스템 다운

그러나 이러한 사실은 모든 종류의 웹 응용 프로그램에도 유효합니다.

— yesildal

@yesildal-예, 여전히 유효합니다. 실제로 모든 유형의 응용 프로그램에 유효합니다. 그러나 웹 응용 프로그램에서는 웹 서비스를 사용할 필요가 없으며 이러한 기능을 자체 어셈블리로 분리 할 수 있습니다 (예 :). 원격 앱 (예 : 전화 앱)에 웹 서비스를 사용하는 이유는 DB 서버가 가까이 있지 않기 때문입니다.

— 시스템 다운

@yesildal-다시 성능 : 실제로는 1 명의 사용자가 있다면 예, 결과를 반환하는 데 추가 지연이 발생하지만 백만 명의 사용자가있는 경우 상황이 다르며 코드를 2 개의 서버로 분할하면 전반적인 성능이 더 빠릅니다.

— gbjbaanb

DB를 직접 노출시키지 않는 또 다른 이유는 전송입니다. JDBC와 대화하는 종류의 대부분의 관계형 데이터베이스는 일반적으로 공용 인터넷 용으로 설계되지 않았습니다. 무선 인터넷은 공공 인터넷의 끔찍한 끝입니다. 예외 처리는 번거로울 수 있으며 트랜잭션 손실을 피하기 위해 앱 내부의 웹 서비스 계층의 역을 작성하게 될 것입니다.

HTTP를 사용하는 새로운 종류의 데이터베이스가 있으며 이러한 종류의 데이터베이스에 적합 할 수 있습니다. 또한 데이터베이스에 일종의 응용 프로그램 코드를 넣는 방법이 특징입니다. CouchDb 또는 RavenDb를 살펴볼 수 있습니다. 둘 다 많은 현대적인 웹 서비스와 마찬가지로 json 및 http에서 작동하는 맵 / 축소 기능이있는 문서 데이터베이스입니다.

— 와이엇 바넷
소스