종속성 주입을 사용하는 WCF 데이터 계약 설계

Question

그래서 맨 위에 WCF 서비스 인터페이스를 추가하는 계층화 된 응용 프로그램이 있습니다. 이 서비스는 단순히 클래스 라이브러리 인 BLL (Business Logic Layer) 내의 비즈니스 오브젝트 (BO)에 이미 존재하는 모든 비즈니스 로직을 가진 외관입니다. BLL 내에서 생성자 삽입을 사용하여 BO에 종속성을 주입합니다. 이것은 좋은 단위 테스트 등으로 모두 작동합니다 ...

일반적으로 작업에 적합한 속성을 가진 각 서비스 메서드에 대해 DataContracts로 요청/응답 개체 집합을 만듭니다. 작업에서 우리 엔티티 중 하나를 메서드로 전달하거나 메서드에서 전달해야하는 경우 해당 유형의 속성 만 정의하면 모든 것이 잘됩니다. 우리의 모든 BO는 직렬화 가능합니다. 그러나 이러한 "엔터티"중 하나가 서비스 메서드로 전달되면 WCF는 정의한 생성자를 호출하지 않고 개체를 deserialize하고 결과적으로 종속성이 해결되지 않습니다.

CreateSomething이라는 서비스 방법의 경우를 사용하십시오. 나는 일반적으로 같은 서명 서비스 작업으로이를 정의하는 것 :

CreateSomethingResponse CreateSomething(CreateSomethingRequest request); 

CreateSomethingRequest DataContract 수 및 유형의 속성을 속성 사이에 전달되는 "법인"을 표현 뭔가있을 것입니다 서비스. 어떤 경우은 인스턴스를받을 것으로 예상되는 비즈니스 개체입니다. 인스턴스화 될 때 DI 컨테이너의 인터페이스가 사용됩니다. 위의 설명처럼 WCF가 서버의 개체를 deserialize 할 때 발생하지 않습니다.

옵션 # 2 컨테이너가 주입시키는의 DataContract에서 뭔가 속성을 제거하고 내 서비스 메서드 내에서 다음 내 DataContract에 명시 적으로 각 속성을 정의의 뭔가 클래스의 새로운 인스턴스를 생성하는 것입니다 그런 다음 DataContract 개체의 속성 값을 BO에 매핑합니다. 그리고 나는 확실히 그것을 할 수는 있지만, 말하자면, 재산을 추가하고 싶다면 두 곳을 바꾸는 것에 대해 걱정하고 있습니다. 뭔가 유형입니다. 그리고 많은 속성을 가진 많은 코드 중복이 있습니다.

아무도이 다리를 건너지 않았습니까? 그렇다면 자신의 생각을 공유하고 자신의 응용 프로그램에서이 상황에 어떻게 접근 할 수 있습니까? 고마워!!!

첫째 : 당신 실체를 전송하고 데이터 전송이 대신 개체를 사용하지 마십시오

Answer 1

내 머리 속에 무엇이 있는지 확인한 결과, Ladislav에게 감사드립니다.

나는 결국 접근 방식을 약간 변경했습니다. 나는 사업 객체의 사용 자체가 과도하고 불필요하다는 것을 깨달았다. 아니면 잘못 지시했을 수도 있습니다. 내 요구 사항을 평가할 때, 나는 나의 접근 방식을 "단순화"하고 모든 것을 작동시킬 수 있다는 것을 깨달았습니다. 내 응용 프로그램에서 각 논리 계층을 가져 와서 레이어간에 전달해야하는 데이터를 확인함으로써 작동하는 디자인을 발견했습니다.

먼저 업무용 개체 대신 업무용 개체 인 SomethingManager을 구현했습니다. SomethingManager 나의 루트에 내가 원하는 모든 행동이나이 SomethingManager를 통해 이루어집니다 뭔가에 수행 할 수 있도록 엔티티 뭔가 연결되어 있습니다. 여기에는 GetById, GetAll, Save 및 Delete와 같은 메소드가 포함됩니다. IValidator < 뭔가 >와 ISomethingRepository :

SomethingManager 클래스는 생성자에서 두 개체를 받아들입니다. 이것들은 IoC 컨테이너에 의해 주입 될 것입니다. 전자는 우리가 선택한 프레임 워크 (처음에는 유효성 검사 응용 프로그램 블록)를 사용하여 필요한 모든 유효성 검사를 수행 할 수 있으며, 후자는 현재 나에게 Linq-to-SQL의 사용을 추상화하고 나중에 EF4로 업그레이드하는 것을 훨씬 쉽게합니다.

서비스 인스턴스의 경우 IoC 컨테이너 (이 경우 Unity)를 WCF에 연결하여 서비스 인스턴스를 컨테이너에서 만들었습니다. 이것은 ISomethingManager의 인스턴스를 내 서비스에 삽입 할 수있게 해줍니다. 인터페이스를 사용하여 종속성을 깨고 서비스 클래스를 쉽게 단위 테스트 할 수 있습니다. 또한 컨테이너가 인스턴스 인 ISomethingManager을 삽입하기 때문에 인스턴스를 생성하고 자동으로 종속성을 확인합니다.

그런 다음 서비스를 통해 전선을 통해 전송할 때 데이터가 어떻게 나타나야하는지 나타내는 DataContracts를 만들었습니다. 각 요청/응답 객체는 내 엔터티 클래스 (또는 BO)를 직접 참조하지 않고 DataMembers로 이러한 DataContracts를 포함합니다. AutoMapper를 사용하여 이것을 깨끗하고 효율적으로 만드는 것은 비즈니스 로직 레이어에서오고가는 데이터를 매핑하는 서비스 메소드 (ISomethingManager)입니다.

데이터 레이어에서 필자는 BLL에서 원하는 인터페이스를 구현하는 부분 클래스를 정의하여 생성 된 엔터티 클래스를 확장했습니다. 예를 들어, 무언가 L2S 엔티티는 부분적으로 정의되어 있습니다. 인 경우입니다. 그리고 이을 ISomething 것은 무엇 SomethingManager (및 ISomethingManager 인터페이스) 및없이 (아주 쉽게 데이터베이스를 쿼리 및 소비에 전달하는 서비스 계층을위한 체인을 L2S 엔티티를 통과하기에 ISomethingRepository 일 서비스 계층은 L2S 구현에 대한 지식이나 의존성을 가짐).

누구나이 접근법에 대해 언급 한 의견, 질문, 비평 또는 제안에 감사드립니다.

Answer 2

이 문제에 두 답변을있다. 엔티티는 논리 W 데이터가있는 비즈니스 오브젝트입니다. 비즈니스 객체의 논리는 데이터를 제어하는 ​​데 가장 많이 사용됩니다. 비즈니스 개체가 비즈니스 계층에서 데이터를 제어하고 더미 상자 만 교환하도록하십시오.

두 번째 : 첫 번째 방법을 따르고 싶지 않은 경우 IoC 컨테이너 문서를 확인하십시오. 의존성을 해결하기 위해 ususally 두 가지 방법이 있습니다. 새로운 인스턴스를 구축하고 모든 종속성 (생성자 주입에 필요한)

BuildUp를 주입 - -

• Resolve 기존 인스턴스를 받아 모든 속성 종속성을 해결 예를 들어 유니티 제공합니다. 이것은 당신의 선택이어야합니다.