[TodayKeywords] 오늘 공부한 키워드
DirtyChecking: 영속성 컨텍스트를 벗어난 객체의 변화가 감지되면, flush 시 변화를 자동으로 업데이트 해주는 것. 주로@Transactional어노테이션을 붙혀서 실행시킨다. DirtyChecking으로 업데이트 되는 필드는 같은 내용이 있더라도, 전체 필드를 업데이트를 한다. 이것을 막기위해선@DynamicUpdate어노테이션을 붙히면 DirtyChecking이라도 업데이트대상 필드만 업데이트된다.프록시 패턴vs파사드 패턴: 프록시 패턴은 핵심로직을 갖고 있는 어플리케이션을 프록시를 통해 숨기고, 핵심로직을 수행하기 전에 다양한 레이어들을 가변적으로 추가할 수 있다. 반면에 파사드는 어떤 한동작을 하기위해 그안에 있는 다양한 동작들을 보이지 않게 하기위해 사용한다.
[NextKeyworks] Study Queue
- HTTPS
- SOLID
- loop label
- CSV
- 파일입출력
- UML
- UTC
- epoch time / Instant time
- MVC
- URL ClassLoader
- Secure ClassLoader
- JNI
- GC
- HOF
- 자바 해시코드(hashCode)
- OSI 7 계층
- PCB
- 스프링 설계철학
- RESTful
- 준 영속성
- 지연로딩
- 프록시객체
- jpa - mybatis 의 차이
- orm - mapper 의 차이
- 쿠키/세션/로컬 스토리지
- HttpMessageConverter
[회고] 221220 : 리팩토링3 (DTO)
DTO의 범위 대해 이전조의 팀원분과 토론을 한바탕 나눴다. DTO에는 메소드에서 필요한 정보들과 불필요한 정보들이 한번에 전달될텐데, 그것을 실행하고자 하는 함수에 맞추는 것이 의존도를 높히는 것일까 낮추는 것일까에 대한 토론을 했다.
난 서비스를 정의할 때 DTO를 그대로 넘기기보단, 필요한 것들만 넘기는 것을 선호했다. 이유는, 서비스가 DTO에 의존하기 않기를 바랬기 때문이다. DTO에 들어오는 값은 항상 필요한 값들만 들어오는 것이 아니라, 여러가지 항목들이 추가되어 들어오기도 한다. 이 때, '의존'한다는 것에 대한 의미가 헷갈리기 시작했는데, 서비스 입장에서 항상 어떤 것이 들어온다는 보장이 있다면, 외부를 의식하지 않고 개발이 가능하기 때문에, 내가 기존에 하던 방식이 의존도가 낮다고 생각했다. 하지만, 팀원분이 제시한 의견은 달랐다. 오히려 DTO에 미리 정의된 값들이 들어있기 때문에, DTO하나만 넘기면 서비스는 밖에서 어떤게 넘어오던지 상관하지 않고 DTO하나만으로 개발이 가능해진다. 이것이 오히려 상호 의존도가 낮아지는 것이 아닌가 하는 의견을 주셨다. 나는 충분히 납득이 갔고, 쉼표를 이용해 여러개로 받아오던 인자를 DTO를 받아오는것으로 변경하였다.
다만, DTO 내부의 값 중에서 상황에 따라 노출되는 값들을 innerclass 로 차등을 두었다. 이렇게 되니, 서비스끼리만 주고받는 DTO와 Request시 주고받는 DTO와, Response 시 보여지는 DTO의 형식이 모두 달라지게 설정 할 수 있었다. 다만, DTO내부에 설정들이 많이 늘어나게 되었는데, 이것이 과연 맞는 것이지는 계속적으로 고민중이긴하다.
튜터님께서는 현업에서는 DTO를 세부적으로 쪼개는 것을 선호하신다고 했다. 그게 훨씬 비용적으로 나은게, 내 방식을 유지한다면 지금 하는 프로젝트의 규모가 작기에 망정이지 조금이라도 커지거나 서비스가 늘어날 때 계속 같은 클래스안에 innerclass가 추가되어야 할 것이다., DTO내부에 추가되는 코드가 매우 많아질 것이다. 이것은 좋지않은 패턴같다고 생각했다. 하지만, 이미 많은 부분을 innerclass를 이용해 작업을 해서, 이부분을 먼저 작업한 뒤, dto를 쪼개는 방식을 적용해보려고 한다.
하지만, 오늘 토론을 통해 각자의 역할이 확실한 DTO를 생성해주는 것이 의존도를 낮추는데 도움을 준다는 것이 확실시 되서 기분이 좋았다.