우리의 데이터 모델에는 약 200 개의 클래스가 있으며 약 12 개의 기능 영역으로 나눌 수 있습니다. 도메인을 사용하는 것이 좋았지 만 분리가 깨끗하지 않아서 변경할 수 없습니다.
우리는 Entity Framework를 사용하도록 DAL을 재 설계하고 있으며 필자가 보았던 대부분의 권장 사항 은 리포지토리 패턴을 사용하여 제안합니다. 그러나 샘플 중 어느 것도 실제로 복잡한 객체 모델을 다루지 않습니다. 내가 찾은 일부 구현은 엔터티 당 저장소를 사용하도록 제안합니다. 크고 복잡한 모델의 경우 말도 안되고 유지 관리가 불가능한 것 같습니다.
각 작업마다 UnitOfWork를 만들고 각 엔터티에 대한 리포지토리를 만들어야합니까? 나는 수천 개의 수업으로 끝날 수 있습니다. 나는 이것이 합리적이지 않다는 것을 알고 있지만 복잡한 모델과 현실적인 비즈니스 응용 프로그램에 대해 리포지토리, 작업 단위 및 Entity Framework를 구현하는 지침은 거의 없습니다.
답변:
먼저, 당신은 당신이 가진 모든 엔티티를 통해 실행하고 스스로에게 물어보십시오 :
이 엔티티 만 지속시키는 것이 합리적입니까?
여기서 의미하는 것은 개체 모델에서 일부 개체가 마스터-세부 관계로 다른 개체에 포함될 가능성이 있다는 것입니다. 엔터티가 다른 엔터티에 크게 의존하는 경우이 엔터티 만 단독으로 유지되지 않으므로이 엔터티에 대한 리포지토리 만 만들지 마십시오. 대신, 각 상위 클래스에 대한 저장소를 작성하고 하위 엔티티 및 기타 관계가 동시에 유지되는지 확인하십시오.
그들이 제공 한 링크에서 UnitOfWork 패턴을 구현하는 방법이 마음에 들지 않습니다. 이 줄을 따라 더 많은 일을하도록 제안합니다 . 저장소 당 하나의 클래스를 정의 할 필요는 없습니다. 모든 리포지토리에 동일한 클래스를 사용할 수 있으며 각 리포지토리에는 작업 수명 동안 고유 한 UnitOfWork 클래스 인스턴스가 있습니다. 동시에 유지하려는 변경 사항에 대해 다른 저장소에서 동일한 UnitOfWork를 재사용 할 수도 있습니다.
아마도 당신은 Domain-Driven Design을 보아야 할 것 입니다. 개체를 집계로 그룹화하고 각 집계의 루트 엔터티에 대해서만 리포지토리를 만드는 것이 좋습니다. 큰 복잡한 객체 모델로 주문을 가져 오는 좋은 방법입니다.
다른 기능 영역은 경계 컨텍스트 일 수 있습니다 . 경계가 겹치지 않는 경우 겹친 경계 컨텍스트를 처리하는 다양한 기술 이 있습니다 .
"리포지토리 패턴"데이터베이스 설계에 대한 이론적 기초는 무엇입니까? 나는 아무도 추측하지 않습니다. 그것은 "거짓 계층"은 당신이 격리되어야하는 것입니다. 내가 알 수 있듯이 관계형 디자인 원칙에 대한 광범위한 프로그래밍 무지와 응용 프로그램의 OO 디자인의 가정 중심에 대한 팬더가 있습니다. 그러나 이론적 근거는 물론 합리적으로 존재한다는 것을 정당화하지는 않습니다.
데이터베이스 설계를 향한 진정한 길은 30 년 동안 변하지 않았습니다. 데이터를 분석하십시오. 키와 제약 조건 및 다 대일 관계를 찾으십시오. Boyce-Codd 일반 양식에 따라 테이블을 디자인하십시오. 데이터 액세스를 용이하게하기 위해 뷰와 저장 프로 시저를 사용하십시오.
SQL DBMS는 프로그래머가 제공 할 수있는 것보다 더 나은 격리 계층을 제공합니다. 데이터베이스가 변경됨에 따라 액세스하는 데 사용되는 SQL이 변경되어야 할 수도 있습니다. 그러나 중개 계층이 있는지 여부에 관계없이 사실 입니다. 애플리케이션이 뷰 및 스토어드 프로 시저를 사용하여 DBMS에 액세스하는 한 일반 SQL 엔지니어링 도구는 기본 데이터베이스에 대한 변경이 해당 뷰 및 스토어드 프로 시저를 무효화하는시기를 표시합니다.
당연히 도전이 있습니다. 중개 계층은 코드를 작성하는 프로그래머에게 고립의 환상과 편안함을 제공합니다. 데이터베이스 설계 및 SQL을 학습하려면 새로운 것을 학습해야합니다. 대부분의 사람들은 생각보다 죽고 많은 사람들이 성공합니다.
팀의 누군가는 200 개의 클래스를 지원하기 위해 SQL을 작성하는 것이 많은 작업이라는 데 의심의 여지가 없습니다. 의심의 여지가 없습니다. 그러나 적어도 그것은 유용한 작업입니다. OO 설계를 모방하여 데이터베이스를 설계하는 경우 많은 작업을 수행 할 수 있으며 그 중 상당 부분은 쓸모가 없으며 DBMS가 제공하는 대부분을 물리 칠 수 있습니다.
예를 들어, 데이터베이스에 작업 단위 (테이블 또는 테이블)를 반영하는 것을 고려합니다. 작업 단위 : 내장에있는 DBMS의 서비스 begin transaction... 업데이트 데이터베이스 ... commit transaction. SQL에서 데이터베이스 테이블에 클래스를 매핑하는 것 외에는 모델링 할 것이 없습니다.
귀하의 질문은 4 년 전에 게시되었습니다. 최근에 어떤 방식으로 "업데이트"되었기 때문에 여전히 누군가에게 관심이 있음을 나타냅니다. 내 대답이 독자가 무의미한 해결 방법을 채택하는 대신 문제에 기본 관계 이론을 적용하도록 장려하기를 바랍니다.