일부 데이터를 수집하는 라이브러리를 프로그래밍 중입니다. 그것은 데이터 저장소 (데이터베이스/파일)를 변경하기 위해 리포지토리를 전환 할 수 있습니다. 나는 도시, 거리 등등과 같이 저장할 더 많은 엔티티를 가지고있다. 우리 계획은 구현에 필요한 인터페이스를 게시하여 사용자 정의 데이터 저장소에 대한 사용자 정의 저장소를 작성하는 것이다.더 많은 엔티티를위한 하나의 저장소?
각 저장소는 하나의 항목을 처리합니다. 그러나 그러한 경우, 각 저장소에 대해 더 많은 인터페이스가 있어야합니다. 필요한 모든 엔티티를 수락하고 하나의 인터페이스 만 게시하는 단일 저장소를 만드는 것이 좋습니다 (저장소 설계 패턴 의미)? 더 많은 인터페이스를 사용하면 일부 구현하고 int 일관성이없는 데이터 API를 만드는 것을 잊을 가능성이 있습니다.
이 문제를 해결하는 더 좋은 방법이 있습니까?
여러 데이터 소스에 대한 참조를 포함하는 GeographicRepository을 만들고 featureType을 매개 변수로 사용하는 것이 좋습니다.
(의사) 될 이것을 사용하는 가능한 방법 :
var rep = new GeoRepository();
var citylist = rep.getEntities(featureType='city');
// or instead:
var citylist = rep.getCities()
EDIT : 대 단편화 REPO 개별의 수집기가되도록 RepositoryFaçade를 가질 것이다 중앙 REPO에 기초한 제안 (및 개별적으로 테스트 할) 저장소 : 물론
var centralRepo = new GeoRepository();
centralRepo.connectRepository(new GoogleCityRepo());
centralRepo.connectRepository(new YahooVillagesRepo());
centralRepo.connectRepository(new USGSDatabaseRepo('C:\usgs_usa_counties.db'));
다를 것 "연결"을 생성/선언하는 방법 : 생성자에서 하드 코딩, 명시 적으로 서비스 가용성 그리고에 따라 (위 그림과 같이), 무엇이든을. 또한 이는 단일 레포 만 호출 할 수있는 하네스 외관을 작성하여 개별 테스트를 허용합니다.
희망이 도움이됩니다.
각 저장소는 다른 항목을 반환 할 수 있습니다. 그러나 모든 것을 하나의 인터페이스로 그룹화하면 다른 개발자가 읽고 유지하는 것이 매우 어려울 것입니다. 내 개발 프로젝트에서 우리는 각 저장소가 관련 엔티티를 리턴하는지 확인하려고합니다. 희망이 도움이됩니다.
짧은 답변 : 예, 모든 작업에 단일 저장소를 사용할 수 있습니다.
긴 답변 : 내가 먼저 저장소를 사용하기 시작했을 때, 내가 유일한 방법은 각 엔티티에 대한 저장소를 사용하는 줄 알았는데 후 나는 저자가 집계 루트 당 하나의 저장소를 사용할지 여부를 논의이 우수한 기사 "Query Objects with the Repository Pattern"을 발견하거나 각 엔티티에 대한 저장소 또는 전체 저장소에 대한 단일 저장소. 그는 데이터 소스를 쿼리하기위한 쿼리 개체 패턴의 조합으로 모든 단일 저장소를 사용하려는 매우 유혹스러운 의견으로 결론을 맺었습니다. 최종 결과가 정말 마음에 들었습니다.
나는 그 문제에 관해서 당신과 다른 이들과 완전히 저자에 동의하지 않습니다. 또한 동의하지 않는 많은 저자를 찾을 수 있습니다. 무엇보다도 주어진 repo에 대해보다 일반적인 기능이 필요하기 때문에 테스트 능력이 떨어질 것입니다. 또한 표현식 3 개를 전달하는 것은 좋지 않으며 IQueryable
@DarthVader 코멘트에서 토론을 시작하고 싶지는 않지만, 엔티티 당 인터페이스를 사용하고 있음을 지적하고 싶습니다. 그런 식으로, 나는 저자가 그의 아이디어를 구현하는 방법은 꽤 테스트 할 수있는 표현 나무를 전달하지 않는다는 것을 말하고 싶습니다. 그리고 나는 누군가가 그가 엔티티마다 저장소를 만들고 있다고 주장하는 것보다 여전히 좋다고 생각합니다. 그는 실제로 모든 종류 또는 원칙을 위반하는 모든 종류의 작업을 포함하여 공통 기본 클래스에서 자신의 저장소를 파생합니다. –
토론을 시작하지는 않았지만 상속이 모든 종류의 원칙을 위반 한 이후로. 어때? 원리? – DarthVader
나는 보통 하이브리드를 위해 기본 저장소와 확장 저장소가 있으며 사용자 지정 구현이 필요합니다.
예 :
public class BaseRepo<T> : IRepo<T> where T: TEntity
{
// common functionality for all repos
// such as find, add, remove etc.
}
그러나, 대부분의 시간은 당신이 특히 선택에 대한 CRUD 이상이 필요합니다.
테스트 가능성과 유지 관리가 불가능한 표현 트리를 전달하는 것은 끔찍한 생각입니다.
또한 확실하게 수행 할 수있는 단일 저장소가있는 경우 종속성 삽입을 사용할 수 없습니다. 그러나 매우 낙심했다.
리포지토리의 책임을 분리해야합니다. 고체 원칙을 따르십시오. 좋은 API를 만들 수 있습니다.
지형지 물 저장소에 대한 아이디어가 필요하면 여기에서 아이디어를 얻을 수 있습니다 (웹 서비스를 다루지 만 웹 기반 또는 http 기반 또는 xml 기반 일 필요는 없습니다). http : /www.opengeospatial.org/standards/wfs – heltonbiker
내 필요에 대해 이것이 올바른 방법 일 것입니다. 저장소는 쉽게 유지됩니다. 약 10 가지 엔티티를 저장하면됩니다. 그러나 모든 것이 하나의 트랜잭션으로 이루어져야하므로, 이렇게하면 이러한 종류의 작업 단위를 구현하지 않아도됩니다. 다른 대답도 유용하기 때문에, 그것들을 upvoting. 여러분의 조언에 감사드립니다. – Fanda