WCF : FaultException 및 ObjectDataSource 바인딩 표시 안 함

Question

웹 서비스을 설계했습니다. 각 메소드 호출시 요청이 성공적으로 수행 된 경우 T 유형의 구조를 반환하거나 FaultException을 클라이언트에 던져 일부 오류를 알립니다. 클라이언트 응용 프로그램 중 하나는 ObjectDataSource 개체가 서비스 메서드에 직접 연결되어있는 ASP.NET 응용 프로그램이었습니다. 이러한 객체는 GridView 페이징 또는 DropDown 채우기 등의 작업을 처리합니다.

불행히도 서비스에서 모든 FaultException를 제거하고 T 형식의 원래 반환 구조를 래핑하는 일반 ServiceResponse<T> 구조로 반환하는 형식을 래핑하고 예외 정보를 전송하기위한 몇 가지 필드를 추가했습니다. 다른 선택의 여지가 없어, 나는 즉시 이것을 수행하고 모든 이전 서비스 프록시 호출을 요청이 성공한 경우 값의 래핑을 처리하거나 그렇지 않은 경우 일부 예외를 throw하는 자체를 돌볼 일반 ExecuteMethod<TChannel, TReturn> 메서드 호출로 대체했습니다. 문제는 이제이 새로운 메서드가 일반이므로 ObjectDataSource을 연결할 수없고 GridView 자동 페이징이 사라졌습니다.

ObjectDataSource ObjectDataSource는 제네릭 메서드를 지원하지 않으므로 피할 수있는 어셈블리 정규화 된 형식 이름을 사용하여 많은 mangling을하지 않는 제네릭 클래스도 지원하지 않기 때문에 GridView를 수동으로 페이지 옵션 중 하나가 남아 있습니다. 필자는 모든 필요한 서비스 호출을 랩핑하고 원하는 값을 반환하는 프록시를 작성하는 것을 피하고 싶습니다. 그러면 원하는 값이 "래퍼를 래핑"합니다. 어느 것이 최악이 아닌지 결정하도록 도와 주시겠습니까? 이 경우 다른 옵션이 있습니까?

Answer 1

나는 그것을 호출 할 때 "래퍼 랩핑"방식을 선호합니다. 구조적으로 이것은 각각의 책임이 하나이기 때문에 전적으로 유효합니다.

서비스 계약이 안정적이지는 않지만 동일한 조건에서 어셈블리 정규화 된 접근 방식보다 유지 관리가 더 쉽다면 유지 관리가 어려울 것입니다.

(RANT : 나는 서비스의 결함을 제거하도록 "명령 한"사람을 신뢰합니다. 서비스의 상호 운용성에 미치는 영향을 이해합니다. 또한 서비스 구현 자와 소비자가 새로운 독점 프로토콜을 제대로 구현하지 못하면 스스로 어려움에 빠지게됩니다. 변화하는 모든 것이 클라이언트에서 예외로 변환되는 메커니즘이기 때문에 실제로 아무 것도 얻지 못하는 것 같습니다.