[Chapter 04] 비지니스 로직에 관해서 Controller, Service

[BvrPark]

Q1.

보통 Service단에 검증이나 계산과 같은 비지니스 로직을 구현하는 것으로 알고 있습니다.
그런데 Controller에도 비지니스 로직?과 같은 화면에 관련된 작업들을 하는 것으로 알고 있는데
코드를 작성할 때 Controller단에 어디까지 구현하고 어디부터 Service로직으로 넘겨서 처리를 해야 할 지 애매할 때가 있는데
혹시 스터디원 분들은 어떤 기준으로 나누는지 알 수 있을까요?

Q2.

DB를 사용할 때, 쿼리문으로 어느 정도 선까지 사용하는 것이 속도에 크게 영향을 안주는 것인지가 궁금합니다.

EX) SQL문으로 전체 목록을 부른뒤, Service단에서 필터링하기 VS 필터링을 할때, SQL문으로 필터링한 목록 각각 부르기

위의 예시에서는 데이터의 규모, 부르는 테이블의 갯수 등에 따라서 빠르기가 전자가 빠를 수도, 후자가 빠를 수도 있는 걸 아는데
그럼 보통 SQL은 어디까지 사용하는 것이 적정선(?)이라고 보시는 지 궁금합니다.
간단한 조건을 섞은 단순 CRUD? 아니면 적당한 조건까지도 괜찮은지?

[coalong]

비지니스 로직 관련한 내용은 특별한 경우가 아니라면 Service 단에서 구현하려했고,
Controller 에서는 간단한 데이터 조합, 검증 등 코드만 작성했습니다.
이 질문을 듣고 어떤 기준으로 나눌까 에 대해 고민해봤는데... 재사용 되는 코드면 서비스단으로 작성하려했고 일회성 (데이터 조합) 등의 코드는 컨트롤러 단에서 작성했던 것 같습니다.

저는 데이터가 많아질 것을 대비해 가능하면 쿼리문에서 모든 필터링과 조인을 거쳐 데이터를 조회하는 것을 선호하는데,
만약 불가능한 경우(e.g. 마이크로서비스아키텍처에서 DB 물리적 분리) 에는 단순한 CRUD 를 거쳐 코드 단에서 필터링을 한 경험이 있는데,
(이유는 요구사항이 달라지면 분리된 쿼리문 모두 수정해야 된다고 생각하여)
그래서 조회 속도가 눈에 띄게 느렸던 기억이 있습니다.
프로젝트 시간 상 인덱싱 작업 등을 통해 개선을 하진 못했지만, 단순한 CRUD 에서 필터링과 집계함수를 거쳐 성능을 향상 시켰습니다.

제가 생각했을 때는 쿼리상에서 해결할 수 있는 조건은 최대한 해결하면 좋다고 생각하는데... 다른 분들 의견 궁금합니다.!

[corock]

거의 정석 답변이 나와서 추가로 얘기할 것이 없네요 👍