DB에 직접 연결하는 대신 웹 서비스를 통해 원격 데이터베이스에 연결해야하는 이유에 대한 "상위 10"목록을 찾고 있습니다. 이것은 현재 내부 논쟁이며 나는 프로 웹 서비스이지만 논쟁을 잃고 있습니다. 나는 WCF / 웹 서비스에 대한 기본적인 이해를 가지고 있지만 다른 사람은 없습니다. 우리는 앞으로 나아가고 싶은 것은 무엇이든 할 수 있지만 지금 우리가 선택한 것은 무엇이든 고수해야합니다.
여기에 제가 생각 해낸 것이 있습니다. 더 있나요?
답변:
보안. 웹 서버 / 앱 사용자를 제외한 누구에게도 DB 액세스 권한을 부여하지 않습니다.
이는 사용자가 많을 때 더욱 중요합니다. DB 측에서 사용자 / 역할 유지 관리의 고통을 피할 수 있습니다.
DB 부하 감소. 웹 서비스는 DB에서 검색 한 데이터를 캐시 할 수 있습니다.
데이터베이스 연결 풀링 (hat / tip @Dogs).
웹 서비스는 영구적으로 열린 DB 연결의 작은 풀을 사용할 수 있습니다. 다양한 방법으로 도움이됩니다.
DB 연결 풀은 데이터베이스 서버 측에서 제한됩니다.
새 DB 연결을 여는 것은 매우 비용이 많이 듭니다 (특히 데이터베이스 서버).
내결함성 기능-서비스 소비자가 장애 조치에 대한 세부 사항을 구현하지 않고도 서비스가 기본 / DR 데이터 소스간에 전환 할 수 있습니다.
확장 성-서비스는 서비스 소비자가 리소스 선택에 대한 세부 정보를 구현하지 않고도 여러 병렬 데이터 소스간에 요청을 분산 할 수 있습니다.
캡슐화. 서비스 사용자에게 영향을주지 않고 기본 DB 구현을 변경할 수 있습니다.
데이터 보강 (여기에는 클라이언트 사용자 정의에서 현지화, 내재화에 이르는 모든 것이 포함됩니다). 기본적으로 이들 중 어느 것이 든 유용 할 수 있지만 이들 중 어느 것이 든 데이터베이스에 큰 부하가되고 종종 DB 내부에서 구현하기가 매우 어렵습니다.
귀하에게 적용되거나 적용되지 않을 수 있습니다. 특정 아키텍처 결정은 DB 액세스 친화적이지 않습니다. 예를 들어, Unix에서 실행되는 Java 서버는 데이터베이스에 쉽게 액세스 할 수있는 반면 Windows PC에서 실행되는 Java 클라이언트는 데이터베이스를 인식하지 못하며이를 원하지도 않습니다.
휴대 성. 클라이언트가 모두 동일한 플랫폼 / 아키텍처 / 언어에 있지 않을 수 있습니다. 이들 각각에서 좋은 데이터 액세스 계층을 다시 만드는 것은 웹 서비스를위한 소비자 계층을 구축하는 것보다 더 어렵습니다 (위에서 언급 한 장애 조치 등의 문제를 고려해야하기 때문입니다).
성능 조정. 대안이 클라이언트가 자체 쿼리 (미리 준비된 저장 프로 시저가 아님)를 실행한다고 가정하면 최적보다 적은 쿼리를 사용하기 시작할 것이라고 100 % 확신 할 수 있습니다. 또한 웹 서비스가 허용 가능한 쿼리 집합을 제한하는 경우 데이터베이스 조정에 크게 도움이 될 수 있습니다. 이 논리는 웹 서비스에 고유하지 않고 저장 프로 시저에 동일하게 적용된다는 점을 추가해야합니다.
이 페이지 에서도 좋은 목록을 찾을 수 있습니다 . '데이터베이스 액세스 캡슐화 : 민첩한 "최상의"사례 "
명확하게하기 위해 이러한 문제 중 일부는 모든 상황에 적용되지 않을 수 있습니다. 어떤 사람들은 이식성에 관심이 없습니다. 어떤 사람들은 DB 보안에 대해 걱정할 필요가 없습니다. 어떤 사람들은 DB 확장성에 대해 걱정할 필요가 없습니다.
제 생각에는 데이터베이스를 웹 서비스로 자동으로 노출해서는 안됩니다. 데이터를 노출 할 서비스가 필요하다고 판명되면 하나를 작성하지만 모든 데이터베이스 액세스가 웹 서비스를 통해 수행되어야하는 것은 아닙니다.
이러한 포인트의 대부분은 웹 서비스가 아닌 공식 API에 적용됩니다.
저장 프로 시저에 대한 호출을 단순히 래핑하는 웹 서비스를 작성하는 것은 좋은 DAL을 설계하는 데 잘못된 접근 방식 인 것 같습니다. 아마도 저장 프로시 저는 이전 클라이언트-서버 시스템에서 남겨진 레거시 코드입니다. 즉 비즈니스 규칙이 SP에 묻혀 있습니다. 만약 그렇다면, 당신은 정말로 모돈의 귀에서 실크 지갑을 만드는 것을 시도하고 있습니다.
또한이 '돼지'의 연대를 '강제'한 웹 앱에 성능 저하를 추가하는 SOAP 메시지 프로토콜 레이어를 추가합니다. 저는 지금 우리의 새로운 MVC-4 앱이 그러한 DAL을 사용하도록 지시받은 프로젝트를 진행하고 있습니다. 이러한 변경을 필요로하는 새 사용자 스토리가 올 때마다 WebMethod 서명과 SP 서명을 모두 변경해야하는 부담이 있습니다. 우리에게는 모든 스프린트입니다. 이러한 패스 스루 접근 방식에는 밀접하게 연결된 두 계층이 내재되어 있습니다.
일반적으로
ASP.NET Web Api에 관심이 많고 데이터 서비스를 먼저 만들 계획입니다.
저는 최근 엔터티 프레임 워크를 사용하여 .NET MVC 웹 응용 프로그램에 집중하고 있습니다.
저는 최근에 Oracle 저장 프로 시저를 기반으로 구축하고 있던 MVC 웹 앱으로 인해 좌절감을 느꼈습니다. 웹 구성 연결 및 TNS 이름을 기반으로 사용할 올바른 dll 파일을 찾는로드 시간 어셈블리를 사용하여보다 현대적인 연결 팩토리 접근 방식을 추진하는 Visual Studio 2012의 또 다른 문제를 제시 한 Oracle 9 또는 이전 버전의 원래 버전.
데이터베이스에 대한 연결 시도가 '더 이상 지원되지 않음'오류 메시지와 함께 실패했습니다. 호기심으로 Oracle 12c를 다운로드하고 TNS 이름과로드 어셈블리 dll과 잘 작동하는 애플리케이션 수준 연결을 만들었고 문제없이 Oracle과 작업 할 수있었습니다.
이전 Oracle 버전에 대한 연결로 작동하는 일부 웹 서비스가 구축되었습니다. 그러나 실망스럽게도 선택된 테이블에 특별히 매핑 된 방법으로 구축되었습니다. 나는 직접 써야 할 것입니다.
Oracle 데이터베이스를 유지 관리하는 그룹은 클라이언트 인터페이스와 비즈니스 논리 계층을 추상화하는 데 사용하던 이전 저장 프로 시저를 대체하기 위해 새 저장 프로 시저를 작성할 것이라고 들었습니다.
그래서 첫 번째 생각은 드롭 다운 목록 채우기 또는 엔터프라이즈 급 데이터로 자동 완성과 같은 모든 일반적인 데이터 요청이 Oracle 저장 프로 시저를 호출하는 데이터 서비스를 통해 수행된다는 것입니다. 각 애플리케이션에 대해이 프로세스를 반복하고 각 개발자가 구성 및 버전 /로드 어셈블리, TNS 문제로 어려움을 겪게하는 이유는 무엇입니까?
그래서....
저는 DBA가 아닌 응용 프로그램 개발자 / 분석가이므로 데이터베이스 도구가 발전 할 때 응용 프로그램을 지속적으로 수정해야하는 끊임없는 좌절감을 경험 한 경험에서 비롯된 것입니다.