리포지토리 패턴 및 데이터 유형이 반환되었습니다

Question

저장소 패턴을 사용하고 있으며 어떤 데이터 유형을 반환 해야하는지 궁금했습니다. 내 데이터베이스에는 고정 길이를 기준으로 분해 해야하는 가변 길이의 문자열이 있습니다. 처음에는 문자열을 전달하고 서비스 계층이 구성된 열의 길이에 따라 구문 분석을하도록 생각했습니다. 나는 리포지토리 레이어에서 문자열을 전달한다는 아이디어가 마음에 들지 않고 오히려 완전한 개체를 전달할 것입니다. 문자열을 전달하는 것은 책임이 충분하지 않은 것처럼 보이지만, 저장소가 다른 방법으로 가야한다는 것은 문자열을 구문 분석하고 구문 분석을하는 방법을 얻는 방법을 얻는 방법을 얻는 방법을 보관해야합니다. 이 경우 저장소와 서비스의 책임이 무엇인지에 대한 제안이 있습니까?

Answer 1

저장소는 메모리 객체의 컬렉션 역할을해야하므로 응용 프로그램이 처리 할 예정인 객체 유형의 인스턴스를 반환해야합니다. 응용 프로그램이 구문 분석 된 개체를 기대하면 반환해야합니다.

구문 분석을 수행하기 위해 일부 서비스에 의존하는 것은 어쨌든 인프라의 일부입니다. 대부분의 리포지토리 구현에서는 반환하기 전에 지속 된 데이터로 무언가를해야하므로 좋은 일입니다.

예를 들어, 저장소가 도메인 레이어 객체를 반환하지만 지속성이 L2S를 사용하는 경우 L2S 데이터를 도메인 객체에 매핑 할 수 있습니다. 이 작업을 수행하려면 저장소 외부의 무언가에 의존해야합니다. 이를 서비스 또는 무엇이든 부르십시오. 아마도 매핑과 함께 저장소 코드를 Kluge하고 싶지 않을 것입니다.

Answer 2

저장소는 반드시 비즈니스 객체를 반환해야합니다.

누가 파싱을 해야하는지에 관해서는 여러 가지 일을 할 수 있습니다. 어쩌면 헬퍼 함수 또는 유사한 것을 사용하여 문자열을 올바른 형식으로 구문 분석 할 수 있습니다. Repo 외부에서 유용하지 않으면 코드를 리팩터링하여 더 읽기 쉽게 만들 수 있습니다.

당신은 당신의 저장소 클래스가 당신의 서비스 계층에 도달하지 않아야한다고 주장하는 데 맞습니다. 따라서 리포지토리를 정리하기 위해 취하는 모든 리팩토링 방법은 해당 레이어에서 수행해야합니다.

Answer 3

구문 분석 방법은 리포지토리 클래스 내에서 개인 메소드가 될 수 있으므로 대중의 실제 리포지토리 메소드에서 실제 구문 분석을 숨 깁니다. 또는 UTIL 클래스에 사는 확장 방법 일 수 있습니다.

SRP를 위반하는 것처럼 보이므로 SVC 레이어에 그 줄의 구문 분석을하지 않는 것에 대한 당신의 생각이 옳다고 생각합니다.

Answer 4

내가 선호하는 선택은 데이터를 고정형 구분 된 문자열에 저장하지 않는 것이 좋습니다. :)

내가 생각하는 방식은 이것입니다 : 누가 데이터의 실제 저장에 가장 관심이 있습니까? 문자열 형식이 일부 레거시 시스템의 아티팩트이고 비즈니스 로직의 필수 부분이 아닌 경우 (즉, 스토리지 메커니즘을 변경하려면 문자열을 제거 할 경우) 저장소 뒤에 숨 깁니다. 그것이 데이터의 필수 부분이지만 비즈니스 로직에서 그것을 추상화하는 경우 서비스에 넣으십시오.

저장소에 남겨두면 해당 문자열을 조작하기위한 특수 클래스를 생성하고 (인터페이스로) 저장소로 전달할 수 있습니다. 이렇게하면 Crazy와 같은 문자열 처리 코드를 테스트하고 (필요한 경우 다른 재사용) 저장소를 간단하게 남겨 둘 수 있습니다.