WCF SOA : CRUD 데이터 액세스 서비스 ... 왜 귀찮은가요?

Question

우리는 SOA WCF 시스템에 데이터 액세스 서비스를 가지고 있습니다. 이 서비스는 "시스템 전체"데이터베이스 테이블에서 CRUD (작성, 업데이트, 삭제) 작업을 담당하며 쿼리에 대한이 데이터의 소스이기도합니다. 시스템에서 DAS의 명령하에 테이블에 액세스하려는 다른 서비스는 가져 오거나 수정하기 위해 DAS로 이동해야합니다. 우리는 Entity Framework를 사용하고이 DAS에 대해 자체 POCO 상태 추적 시스템을 구축했습니다.

우리는 데이터베이스에 단일 서비스에 속하는 다른 테이블을 가지고 있으며, 비즈니스 정보가 충돌하고 다시 시작되거나 기록되는 경우 액세스 할 수있는 상태 정보와 같이 자신의 용도로만 데이터를 저장합니다. 우리는 하나 이상의 테이블이 하나 이상의 서비스에 의해 접근 될 수 없다는 규칙을 가지고 있습니다. 그래서 여러 서비스에 필요한 데이터는 DAS에서 끝납니다.

진실은 왜 데이터 액세스 서비스가 테이블에 직접 액세스하는 것과 반대되는 좋은 아이디어인지 전혀 이해하지 못했습니다. 데이터베이스 업데이트 (한 번에 하나의 POCOS 만 가능)의 POCO 그래프를 되돌릴 수 없기 때문에 우리의 DAS는 트랜잭션이 아니며 DAS가 실제로 데이터를 필요로하는 다른 서비스의 클라이언트이기도합니다 그것으로부터 ... 순환 의존성.

왜 DAS를 사용합니까? SOA와 관련하여 DAS가 중요한 이유는 무엇입니까? 내가 여기서 무엇을 놓치고 있니? 통제의 단일 지점?

모든 테이블이 DAS의 일부가 아니며 일부 서비스가 자체 "개인"테이블을 가지고있는 SOA 설계 결함입니까?

이 환영에 대한 토론입니다.

Answer 1

이 방법이 올바른 일이라고 생각하면 문제가 줄어들고 때로는 번거로울 수도 있습니다. SOA는 서비스와 관련된 모든 데이터에 대한 단일 제어 지점을 확보하는 대가로 일부 효율성을 교환해야합니다. 사실, "공통 DAS"서비스를 사용한다는 생각조차도 일부 SOA 서클에서 약간 악취가납니다.

모든 CRUD 작업을 SOA 응용 프로그램의 한 서비스에 집중시킴으로써 데이터 무결성을 보장하고 비즈니스 규칙이 제대로 작동하는지 확인할 수 있습니다. 예를 들어, 저장하려는 엔티티에 순수한 SQL 관점에서 접근하기 어려운 비즈니스 규칙이 있습니다. 예를 들어 파일 참조를 저장하고 테이블을 작성/갱신하는 경우를 생각해 봅시다. 이러한 파일이 존재하는지 확인하는 서비스.

SOA와 이러한 테이블에 대한 단일 액세스 지점을 사용하면 논리를 작성/업데이트 메소드에 코딩 할 수 있으며 서비스에서 수신하는 데이터가 유효하다는 것, 즉 참조 된 파일이 존재 함을 합리적으로 확신 할 수 있습니다. 누군가가이 테이블에 글을 쓰거나 데이터를 검색 할 수 있다면, 그러한 보증은 존재하지 않을 것입니다. 심지어 서비스를 직접 호출한다고해도 악의적 인 계획이나 건망증을 통해 다른 프로그래머가 구현을 잊어 버린 것을 알지 못합니다 그 핵심 비즈니스 규칙. 이것은 클라이언트 코드의 모든 비트가 비즈니스 로직을 독립적으로 보장하고 궁극적으로 응용 프로그램 전체에 흩어져있는 비즈니스 로직의 엉망진창을 방어 프로그래밍에 이르게합니다.

또 다른 이점은 확장 성과 메인 테너 빌리티입니다. 서비스 중 하나가 엄청난 양의 데이터에 액세스하고 있다고 가정 해 보겠습니다. SOA를 사용하면 모든 것이 "블랙 박스 (black-boxed)"되어 클라이언트 코드가 데이터가 어떻게 최종적으로 얻어지는 지에 대한 많은 지식을 갖지 못합니다. RDBMS를 변경하거나, 테이블을 파티션하거나, 캐싱을 구현할 수 있으며이를 호출하는 클라이언트 코드에서 모든 것을 볼 수 없도록함으로써 고통스러운 업데이트가 한 곳에서 이루어 지도록 할 수 있습니다. 앱 전체에 데이터베이스 코드가 흩어져 있으면 이런 종류의 업그레이드가 매우 어려워집니다.