2011-03-29 2 views
5

서비스 지향 아키텍처와 SQL을 활용하여 데이터를 쿼리 할 때 성능을 최적화하는 탁월한 UI를 결합하는 것에 대해 생각해 보면 나는 최근에 약간의 충격을 받았습니다.SQL로 웹 서비스 쿼리

예를 들어 ASP.NET 용 DevExpress 그리드보기는 모든 필터링, 정렬 및 페이징 논리를 데이터베이스 서버에 위임 할 정도로 멋지다. 그러나 이는 데이터 이 SQL 가능 데이터베이스 서버에서 검색된이라고 추정합니다.

데이터베이스와 UI 레이어 사이에 웹 서비스 레이어를 도입하고 UI에서 웹 서비스를 사용하여 데이터를 쿼리하도록하려면 어떻게해야합니까?

  • UI에서 웹 서비스를 통해 데이터베이스로 필터링 요청을 전달할 수 있도록 웹 서비스와 UI를 어떻게 디자인 할 수 있습니까?
  • List QueryData(string sqlQuery) 스타일 웹 서비스를 제공해야하며 보안/액세스 제한을 보장하기 위해 SQL 문자열을 직접 구문 분석해야합니까?
  • 또는이 부담을 감당할 수있는 좋은 프레임 워크 또는 디자인 가이드 라인이 있습니까?

이것은 매우 일반적인 문제 여야하며, 비교적 적절하게 이미 해결되었다고 확신합니다.

저는 주로 .NET/C# 기반 또는 호환 가능한 솔루션에 관심이 있습니다.

편집 : OData 및 Microsoft WCF Data Services를 발견했습니다. 내가 바로 그것을 가지고하는 경우로 볼 수있는 하나로, OData 기반 응용 프로그램은 다음과 같습니다

  1. 사용자 ---/나에게 페이지를 줘 1 (기록 1..10)/--->ASP.NET 서버 제어 (HTTP를 통해 물론,)
  2. ASP.NET 서버 컨트롤 ---/LINQ 쿼리/--->데이터 서비스 클라이언트
  3. 데이터 서비스 클라이언트 ---/중 하나로, OData 쿼리/--->WCF 데이터 서비스
  4. WCF 데이터 서비스 ---/LINQ 쿼리/--->엔티티 프레임 워크
  5. 엔티티 프레임 워크 ---/SQL 쿼리/--->데이터베이스

이 권한이 있으면 DevExpress 서버 컨트롤이 필터링 요청을 위임 할 수 있어야합니다 (예 : 나에게 상위 10 개만 제공하십시오.)이 모든 계층을 통해 데이터베이스에 연결 한 다음 해당 인덱스를 적용하여 해당 쿼리를 수행합니다.

맞습니까?

편집 :이 스레드가 생기게하는 것을 보는 것이 기쁨입니다.

+0

"그냥"IQueryable을 구현하고 백엔드에 webservice를 호출해야합니까? 구성 요소에 익숙하지 않은 경우 ... –

+0

좋은 질문입니다. 저는이 문제로 고생하고 있지만 결코 우아한 해결책을 찾지 못했습니다. 이전 구현에서는 서비스 메서드에 사용자 지정 "필터"매개 변수를 제공하고 (결국에는 WHERE 절로 파싱 됨) 서비스에서 액세스 제한을 보장하는 몇 가지 추가 기준을 추가했습니다. 편집 :이 경우 필자는 Telerik Grid와 협력하여 OQL 쿼리로 필터를 생성했습니다. – Ozzy

+0

@ Vincent : IQueryable을 구현하는 것은 아마도 스토리의 한 부분 일 것이지만 사소한 것입니다. 프레젠테이션 계층에서 LINQ를 사용할 수는 있지만 필터링 및 정렬을 DBMS에 위임하는 방법을 문제 (?)로 해결하지 못합니다. – chiccodoro

답변

1

List QueryData(string sqlQuery)을 구현하면 거의 무한한 보안 문제가 발생합니다.

보안 액세스를 기준으로 필터링해야하는 경우 OData 구현이 중요하지 않으므로 인증 된 사용자를 기반으로 OData 쿼리를 필터링 할 수 있도록 WCF 서비스에 대한 적절한 권한 부여/인증을 설정해야합니다. 데이터.

WCF 서비스에서 데이터를 검색 할 때 서버 측 데이터 작업을 구현하는 가장 쉬운 방법은 Grid의 정렬/필터 작업을 코드 숨김으로 차단 한 다음 WCF 서비스에서 특수 메서드를 호출하는 것입니다. 사용자가하고있다.

+0

그래도 서버 측에서 일종의 인증 및 권한 부여 메커니즘을 구현해야합니다. 서버 측은 다른 사람들의 요청을 위장하여 속지 말아야합니다. –

2

정말 흥미로운 질문입니다! 나는 옳고 그른 대답은 없다고 생각하지만, 건축 원리를 세울 수 있다고 생각합니다.

첫째, "서비스 지향 아키텍처"는 다른 응용 프로그램에서 사용하기 위해 비즈니스 서비스를 노출해야하는 아키텍처 스타일입니다. 적어도 데이터베이스 쿼리를 실행하는 것은 서비스가 아닙니다. 사실, 임의의 SQL을 실행하기위한 웹 서비스를 제공하는 것은 아마도 안티 패턴 일 것입니다. 대부분의 데이터베이스 서버가 제공하는 보안 모델을 우회 할 수 있습니다. 쿼리를 제어 할 수 없습니다. 구문 적으로 올바른 "select" 웹 서비스 프로토콜의 오버 헤드로 인해 일반적인 액세스 경로 (LINQ 등)를 통해 데이터베이스를 쿼리하는 것보다 몇 배 더 느려질 수 있습니다.

그런 관점에서 생각해 보겠습니다. 문제의 해결 방법은 무엇입니까?

첫 번째로 DevExpress 그리드 사용의 생산성을 원한다면 DevExpress가 작업하기를 원하는 방식으로 작업해야합니다. 즉, 데이터베이스에 직접 쿼리하는 것이 가장 좋은 방법입니다. SOA로 옮기려하고 DevExpress 그리드가이를 지원하지 않는다면, 전체 엔터프라이즈 아키텍처를 비교적 사소한 구성 요소에 맞추기보다는 새로운 그리드 컨트롤을 찾아야 할 때입니다.

둘째 - 구조적으로 정렬, 필터링 등은 어디에서해야합니까? 이것은 SQL의 쉬운 개념이지만 웹 서비스 사양으로 변환하려고하면 다소 불쾌합니다. 이해할 수없는 메소드 서명 ("getAccountDataForUser (userID, bool sortByDate, bool sortByValue, bool filterZeros, bool filterTransfers)")으로 끝납니다.). 반면에 클라이언트에서 필터링 및 정렬을 수행하는 것은 지저분하고 느립니다.

내 권장 사항은 Specification Pattern입니다.이 방법을 사용하면 깨끗한 메소드 서명이 가능하지만 일관된 방식으로 원하는 정렬 및 정렬을 지정할 수 있습니다.

+0

나는 당신의 견해에 동의합니다. OData 사양은이 문제에 대한 해답처럼 보입니다. 임의의 SQL 쿼리를 허용하지 않지만 필터링 및 정렬을 지원합니다. DevExpress와 같은 구성 요소와도 호환 될 수 있습니다 (하지만 여전히 궁금해하고 있습니다.) – chiccodoro

1

"이것은 매우 일반적인 문제 여야하며, 이미 비교적 적절하게 해결 된 이라고 확신합니다."

개발자 세계에 쌓여있는 껍질을 벗기는 고양이의 수를 감안할 때 아니오라고해야합니다.

WCF Data Services는 지금까지 발견 한 최상의 솔루션을 제공하지만 인증 및 권한 부여는 까다로울 수 있습니다. 이 주변의 서버 측 문제를 다루는 알맞은 게시물이 http://blogs.msdn.com/b/astoriateam/archive/2010/07/19/odata-and-authentication-part-4-server-side-hooks.aspx입니다. 이것을 설정하는 것은 쉬운 일이 아니지만 잘 작동합니다.