request를 불변으로 보존할 이유가 있을까요?

Question

프로젝트 몇 개를 해보면서 느낀점입니다.각 프로젝트마다 DTO를 어떻게 사용하는지 다 다르더군요.한 군데서는REQ DTO, RES DTO 두 개만 선언해서 처리하더군요(REQUEST) CONTROLLER > SERVICE > DAO > DB (RESPONSE) DB > DAO > SERVICE > CONTROLLER다른 곳에서는컨트롤러에서 사용하는 INPUT, OUTPUT 선언하고SERVICE ~ DAO 단에서 사용하는 DTO 선언하고DAO ~ ENTITY 단에서 사용하는 ENTITY 선언해서총 6개의 DTO?를 만들어서 사용하더군요(INPUT) CONTROLLER(INPUT DTO) SERVICE > DAO(ENTITY) DAO > DB(ENTITY) DB > DAO(OUTPUT DTO) DAO > SERVICE(OUTPUT) SERVICE > CONTROLLER어느 쪽이 보다 정석에 가까운 걸까요?개인적으로는 전자는 너무 돌아가기만 하면 된다는 마인드 같고후자는 굳이 컨트롤러 단까지 나눠야 하나 싶은 생각도 들더군요.

강아지좋아하는개발자 · Answer

프로젝트 규모에 따라 다를 듯 합니다.작은 규모는 전자 큰 규모는 후자

NPE · Answer

후자는 도메인의 의미가 변할때만 변환하는거고, 그냥 무지성으로 레이어마다 변환하는거면 잘못된겁니다.

엡실론 · Answer

굳이 말하자면 후자가 정석입니다. 각 레이어는 각자 목적과 역할이 다르고, 독립적입니다. 따라서 각 레이어 만의 입출력을 따로 가지는 게 논리적으로는 더 적합합니다.실제로는 너무 번거롭지 않은 구조를 많이 씁니다. db 엔티티는 보통 따로 만드는 편이고, 컨트롤러 dto와 서비스 dto의 분리는 나중에 필요할때 해도 됩니다.

스프링 잘하고 싶어요 · Answer

레이어마다 다른 dto 하는 게 정석이면 클래스 내부의 필드들은 그대로 가져가면서 클래스만 갈아끼우는 건가요? db에서 갓 나온 엔티티 말고는 딱히 필드를 없애고 수정할 게 없어 보이는데 말이죠..?

지붕뚫고높이차 · Answer

최근 DTO 불변 관련한 글을 많이 쓰네요.서블릿의 request 객체를 통해 전달되는 데이터는 불변하지만 불변된 데이터를 가지고 실행되는 프로그램은 데이터를 변경합니다. 따라서 request 는 데이터(객체)를 관리할 수 있는 setAttribute() 등의 기능을 제공합니다.일반적으로 레이어는 서블릿의 request 객체를 그대로 사용하지 않습니다. 만들어진 레이어는 서블릿 기능을 사용해야 하는 문제가 생기기 때문입니다. 다른말로 서블릿에 종속 된다고 하죠. 그래서 보통 서블릿의 request 를 추상화한 객체를 프레임워크에서 제공하고 레이어에 사용됩니다.따라서 추상화된 request 객체는 불변할 수 없습니다. 프로그램은 데이터를 변경시키고 추상화된 reqeust 객체도 setAttribute 메소드를 제공해야 하기 때문입니다. request 객체를 불변으로 보존시킬 이유가 없습니다.우리가 만드는 프로그램을 레이어로 분리하는 이유는 재 사용 해야 하기 위함입니다. 이해 가능한 단위로 분리한 레이어 재 사용을 통해 개발 비용을 줄이는게 목적입니다.재용을 위해 분리 하는 레이어마다 DTO 를 만드는건 추천하지 않습니다. DTO 는 하드코딩된 클래스이고 그 DTO 를 사용해야지만 레이어를 재 사용 할 수 있기 때문입니다. 비용을 줄이기 위한 레이어가 DTO 변경 작업으로 오히려 비용을 증가시키는 문제가 됩니다.입력과 출력으로 프로그램의 목적을 설명할 수 있겠지만 입력과 출력의 구조가 복잡하면 그것 만 가지고 레이어를 설명하기 어려워집니다. DTO 도 마찬가지 입니다. DTO 는 복잡해 질 수 밖에 없고 DTO 로 레이어를 설명하기 어려운 경우가 생깁니다. 더욱 복잡한 DTO 를 단순하게 만들기 위해 분리하는 경우도 있는데 그것때문에 더욱 레이어를 이해하기 어렵게 만듭니다.DTO 의 수를 줄이는 것도 방법을 수 있지만 한계가 있습니다. 요구사항은 변경되고 소스코딩은 리펙토링 해야 하기 때문이죠. 그 시점에 DTO 를 변경하는건 힘듭니다. 레이어간 내용결합으로 하드코딩 되었잖아요.첫번째는 레이어간 결합도를 낮추기 위한 노력으로 생각합니다. 추상화된 request 객체로 레이어간 데이터 결합을 유도시키기 때문입니다.두번째 방법은 오버엔지리어링(쓸때없이 노력함)으로 봅니다. 레어마다 DTO 를 만들 필요가 없는데 만드는 것이 문제입니다. 그리고 만들어진 DTO 는 내용결합을 유도시키죠. 규모, 정석, 꼼수(땜빵)의 이유로 방법을 선택하기 보단 내가 편하게 개발할 수 있는 방법을 선택하는게 좋지 않을까요? 그런 면에서 전 첫번째 방법을 선택하겠습니다. 데이터는 변경되고 불변성을 유지 시킬 필요도 없으니까요? 첫번째 방법에서 더 개선시킨다면 request 와 response 를 합쳐 사용하겠습니다. 레이어간 데이터 결합도를 더 쉽게 유지 시킬 수 있기 때문입니다.

장독깨기 · Answer

Dto 를 왜 사용합니까? 먼저 질문을 던지고, ... ㅎ편의상 ReqDto, ServiceDto, DaoDto 이렇게 구분해보겠습니다.각각에 들어가는 속성은 다 같을 수도 있고, 다를 수도 있습니다.속성이 다 같다면 전자로 하면 되겠지요.속성이 다를 경우 전자로 하면 어케 됩니까?Dto 의 특정 속성이 Req 에 사용되는지 아닌지, 또는 Service 에 사용되는지 아닌지, ...Dto 만 보고 알 수가 없잖아요. 이럴거면 Dto 를 사용할 이유가 없어지는거죠.그러니, Dto 를 사용할거면 후자가 정석이라 볼 수 있습니다.근데, 대부분 요청에 각각의 속성이 같다면, 똑 같은걸 매번 만들어야 하니 번거롭기 짝이 없습니다.그래서, 가령, ReqDto 를 만들고, 그걸 상속해서 ServiceDto, DaoDto 를 만들어 사용하다가,속성이 추가되거나 변경되면 그때 해당 Dto 를 변경하면 일관성을 유지하면서 사용할 수 있을 겁니다.Dto 를 사용하려면 레이어별로 메소드 별로 정확하게 구분을 해야 그 의미가 있다 볼 수 있겠습니다.근데, 실무에서 제대로 관리하지 않고 대부분 개판 오분 전인거 잘 알고 있습니다. 귀찮고 번거롭거든요.전 저렇게 관리하기도 귀찮고 번거로우며 일도 많아지고 별 의미도 없다 생각하기 때문에,그냥 Map 사용 합니다. Map 사용하는거 싫어하는 분 많은 것도 잘 알고 있습니다. :)

request를 불변으로 보존할 이유가 있을까요?

6개의 답변

Q&A 목록