WCF를 통해 데이터베이스를 노출하려면 POCO 개체 또는 분리 된 EntityFramework 개체를 사용하는 것이 더 좋습니까?

Question

보안상의 이유로 응용 프로그램에서 데이터베이스에 직접 액세스하지 않고 제 3 자 응용 프로그램과 데이터를 공유 할 수 있어야하므로 내 데이터의 데이터 노출을 위해 WCF service을 만들었습니다.

내 솔루션은 다음과 같이 구성됩니다. WPF application ->WCFService library ->DataAccessLayer library.

WCF service을 구현하려면 서비스에서 단순히 detached EntityFramework objects을 반환하는 것으로 간주했지만 주 응용 프로그램에 DataAccessLayer 라이브러리에 대한 종속성을 적용해야합니다. 내가 그 주위에 얻을 수

있는 유일한 방법은 POCO objects를 생성하고 와이어를 통해 보내 그들을 사용하지만, 지금은 내가 동적으로 POCO의 발생있어 순간 등 EntityFramework.

다시 값을 매핑해야하고 T4 template을 통해 그리고 EntityFramework 값을 앞뒤로 매핑하기 위해 AutoMapper을 사용하고 있습니다.

Wcf 서비스는 데이터를 표시하기 위해 저장소 패턴을 구현하기 만하면됩니다.

좋은 해결책입니까? 다른 옵션이 있습니까? 알고 있어야하는 단점이 있습니까?

Answer 1

제약 조건에 따라이 솔루션에 동의해야합니다.

Google의 동기가 약간 다르긴하지만 거의 동일한 솔루션을 만들었습니다. 우리 고객은 Delphi Win32 였고 당시 JSON을 제대로 지원하지 못했기 때문에 SOAP을 사용해야했습니다.

클라이언트도 Nullable 프리미티브를 지원하지 않았기 때문에 POCO가 지원되지 않는 유형을 모두 제거하고 상호 운용성을 보장하기 위해 다른 변경 작업을 수행 한 다음 Automapper 사용자 지정 매핑을 사용하여 양방향 변환을 처리했습니다.

일반 저장소를 사용하여 T4 템플릿에서 생성되는 모든 WCF 서비스 (계약 및 구현). T4 템플릿을 사용하여 CRUD 작업을 위해 테이블 ​​당 별도의 WCF 서비스를 생성 한 다음 비즈니스 관련 WCF 서비스를 수동으로 만들 수있었습니다.

마지막으로 T4 템플릿을 사용하여 SOAP 서비스와 상호 작용하는 Delphi 저장소를 생성 할 수도있었습니다.

또는

당신은 그냥 쉽게 별도의 프로젝트에 포항 강판 (및 코드 생성)를 움직일 수는 포항 강판 라이브러리를 참조하도록 DataAccessLayer 라이브러리를 변경 만의 DbSets의로 구성된 DB 컨텍스트를 포함하여 POCO 및 데이터 액세스 논리는 있지만 엔터티는 없습니다 (현재 POCO입니다). 귀하의 고객은 DataAccessLayer 라이브러리에 의존 할 필요가 없습니다.

제약 사항에 따라 좋은 해결책입니다.