안녕하세요, 닷넷을 시작한지 얼마 안된 초보입니다.
현재 간단한 api 서버를 mvc 구조로 만들고 있는중입니다.
컨트롤러와 디비를 연결하려는 과정중에 몇가지 의문점이 생겨 질문 드립니다.
컨트롤러에서 디비 자료를 긁어오기위해 중간 Repository 를 통해, 자료를 긁어 오려고 계획중입니다.
Controller=> Repo=> DB 이런 구조인데,
래포부분에 디비 쿼리를 작성하여, 디비에서 다시 래포로 해당 데이터를 레포로 반환 해줍니다.
레포에서 반환 해준 값을 모델로 다시 감싸 컨트롤러로 다시 보내주려합니다.
여기서 질문,
그럼 api 상에서 필터 값을 컨트롤러로 부터 받은후 조건에 맞게 결과값을 필터하는 기능은
위 구조중 어디에 작성하는게 좋을까요?
개인적인 생각
필터 조건 파라미터들을 디비단까지 넘겨서 디비쪽에서 걸러내는게 맞아 보입니다.
혹은 모든 자료를 불러온후 레포 & 컨트롤러 부분에서 걸러내는방법(이건 오버해드가 너무 클거같아서…)
여러분들의 의견은 어떨지 궁금하네요.
레포에는 쿼리문 & 데이터를 모델로 전환 기능을 주로 맡아 하려고 하는데,
이게 맞을까요? 그리고 쿼리문이 너무 길경우 어떻게 처리하는게 좋을까요?
개인적인 생각으론 쿼리문만 따로 파일로 저장해서 관리(이건 오버해드가 너무 클것같아서…)
아니면 쿼리 빌더로 조금더 가독성을 좋게 하긴 했지만…
고수님들의 고견 부탁드리겠습니다.
위 관련하여 추천 키워드나 문서 책 남겨주시면 감사하겠습니다!
DB로 부터 데이터를 조회할때 특정 조건으로 조회가 되는 조건이라면 Repository 에
FindByName(string name) 같은 메서드를 구현해 놓고
해당 메서드를 통해 where 검색으로 데이터를 조회 하는 것이 맞습니다.
그런데, DB에서 where 검색이 아닌 자체적으로 필터링이 필요한 경우,
즉 DB에서 원본 데이터 조회 후 그 데이터를 가공하거나 자체 필터링이 필요한 경우라면
이것은 DB의CRUD에 해당 되지 않고
비즈니스 로직으로 볼 수 있습니다.
이런 상황은 Repository 담당으로 옳지 않고 별도의 비즈니스 로직을 담당하는 Service에서 처리 하는 것이 좋습니다.
첫 번째 답변 내용과 같이 데이터를 모델로 전환 하는 역할은
별도의 비즈니스 로직을 담당하는 Service를 구현 하여 처리 하는 것이 좋습니다.
정리하면 다음과 같이 역할을 나눌 수 있습니다.
Controller : 사용자에게 요청을 받아서
Service : 요청에 대한 비즈니스 로직을 처리하여 해당 Entity 모델 등으로 반환.
Repository : Service에서 비즈니스 로직 처리중 DB관련 CRUD 처리는 별도의 Repository가 담당
이렇게 각각 역할을 나누어 설계 할 수 있습니다.
Repository 패턴을 적용해서 구현 하셨다면