초보의 일관성 있는 좋은 코드에 대한 질문

Question

안녕하세요. 주말을 잘 보내고 계신가요?제 질문들은 다음과 같습니다.[질문1]Service 계층 속 여러 함수들이 있을 때,어떤 함수는 User같은 순수객체로,다른 함수는 Long userId, String username 같은 단순 변수로, 또 다른 함수는 UserCreateForm 같은 form 형태로 받는다고 하면,이건 일관성이 없는 코드라고 할 수 있나요?매개변수를 하나의 방식으로 통일해야 좋은 코드인건지 궁금합니다.[질문2]Service계층이 Repository/SQLMapper계층에만 의존하지 않고, 다른 Service계층에 의존하는 것.이것이 바람직하지 않은지 궁금합니다.제 생각에 Service계층은 반드시 Repository계층에만 의존한다는 규칙을 정해두지 않으면,개발자의 실수로 순환참조 같은 문제가 발생할 수 있을거라고 보는데,제 생각이 올바른지도 궁금합니다.[질문3]Controller계층의 일부 매서드들이 Service계층을 거치지 않고,바로 Repository/SQLMapper 계층에 직접 의존하는 것. 이것도 바람직 하지 않은지 궁금합니다.[질문4]위 질문3과 이어지는데요.Controller 계층 속 매서드가 Service계층을 거치지 않고 바로 Repository/Mapper 계층에게 의존해도 되는 경우가 꽤 자주 있는데, 이런 경우에 Service계층을 반드시 거치도록 코드를 작성하면,Service계층의 코드는 단순 위임만을 하게 되더라고요.이것도 좋은 코드인지 궁금합니다.모든 질문 말고 하나만 골라서 답해주셔도 정말 감사합니다.

c큐리어티 · Answer

저도 초보개발자단계라서 조언보다는 의견으로 답변 달아봅니다 [질문1] restful한 api라는 가정하에 http메소드 사용법에 맞게 Pathvaripable이나, querytString 방식으로 받거나 JSON형식을 클래스로 받았을때 서비스 계층으로 그대로 넘기는건 일반적인 것 같습니다. 만약에 컨트롤러 계층에서 서비스계층으로 값을넘길때 한가지 패턴으로 넘기자면 전부 하나하나의 파라미터로 전달하는 방법 또는 DTO 클래스를 생성해서 보내는 경우가있을텐데 후자의 경우에는 컨트롤러와 서비스계층으로 전달할때 DTO클래스를 사용하는것이 의미가있는지 고민해볼 필요가 있다고 생각합니다. 개인적으로는 일관성 목적하나만으로는 일관성보다는 코드의 번잡함만 늘어날것 같아 다른 이유가 있었으면 좋겠습니다. 클래스의 역할이 명확한 UserCreateForm이 의미전달은 분명해서 좋지만 User라는 클래스로 전부 해결해도 코드해석에 문제가 되지않는다면 둘다혼용하는 것 또한 상관없을 것 같습니다. 문제가 되는 경우라함은 요청으로 받아야하는 값과 User클래스의 필드값목록이 불일치하는경우 또는 스웨거 문서를 표기하는데 api별로 명시해야하는 내용이다른 경우 정도일것같습니다. [질문2, 3]이건 각자의 생각이 정답인 것 같긴합니다.. 저같은경우는서비스 계층이 DB접근계층에 의존하는 것은 다른 서비스 계층을 거치지않고 데이터를 조회한다는의미이고이는 곧 서비스로직자체를 DB접근 계층에서 해결하게되어 유지보수 및 재사용이 어려운 구조로 개발되기쉬워질 것같습니다. 구조적으로 순환참조가 발생하지 않기위해 가능한 서비스계층이 디비접근 계층에 직접 의존하는것은순환참조 발생 자체를 막아버릴 수는 있지만 재사용에 용의한구조는 아니라고 생각라고 생각합니다.다만 복잡하지않다는 장점이있어서 객체지향적인 설계를 어려워하거나 아예 생각조차 하지 않는 개발자가개발또는 추후 유지보수한다는 경우에 선택하는것도 바람직하다고 생각합니다.[질문4]서비스 계층을 거치지않고 컨트롤러계층이 디비접근계층에 직접 접근하며 서비스계층을 거친다고하더라도 위임할정도의 코드라면 서비스로직이랄게 없는 단순한 코드이고 이런코드는 취향의차이로나뉘지좋다 말다 논의하지는 않지않을까 싶습니다. 그정도로 단순하다면 추후 서비스로직을 추가하는 확장성에도 문제가없을것이고 사이드이펙트도없을것이고코드리딩하기에도 어렵지 않을것이라는 이유때문입니다.좋은질문목록이어서 답변하면서 저도 다시한번 생각해보았습니다 감사합니다

wharup · Answer

통일된 규칙을 가지는게 좋습니다. 특히 Service 레이어는 어플리케이션의 중심이 되므로 내부 구현을 감추고 외부 의존성을 줄이려고 노력하므로 자신이 정의한 DTO로 Input/Output을 제공하는 경우가 많습니다.무엇보다 각 레이어의 역할을 정의하는 게 필요해보입니다. Controller는 View나 API와의 인터페이스, Service는 어플리케이션 로직 수행, Repository는 데이터 읽기/쓰기로 정하고 보면..[질문1] 질문 중 UserCreateForm을 Input으로 받는건 적절하지 않고, Form을 Input으로 받는 Controller가 Service가 요구하는 형태로 변환하는게 맞습니다. 또 User 같은 순수 객체가 Service나 Repository의 엔티티라면 외부로 노출하지 않는게 더 좋습니다.[질문2 ]A Service가 B Service를 거치지 않고 B Repository를 호출하면 A Service에 B Service의 로직이 중복되기 마련이고 B Service의 변경을 어렵게 합니다.[질문3] 외부 인터페이스를 담당하는 Controller의 월권 행위라고 봐야겠죠;;;[질문4] 같은 코드가 중복되는 것으로 보여 불편할 수 있습니다.. 실무에선 접근제어, 입력 값 검증, 이력 등등의 기능이 추가되므로 이렇게 고민하는 경우는 별로 없습니다.

초보의 일관성 있는 좋은 코드에 대한 질문

2개의 답변

#mvc 목록