파이로가 DAO와 레포지토리의 차이점에 대한 떡밥을 던져줬다. 사실 현재 사용하는 프레임워크들에서 내부 구현에 조금씩 차이가 생기지만 구현 자체가 크게 달라지지는 않는다. 특히 마이바티스도 CRUDRepository는 사용 할 수 없겠지만, 겉으로는 JPA나 Spring Data JDBC와 크게 다르지 않아보이도록 구현할 수 있다. 내가 느끼기에 큰 차이점은 프레임워크 차원에서 객체지향이나 DDD를 강제하느냐 아니냐의 차이가 가장 큰 것 같다. 마이바티스같은 단순 쿼리 매퍼는 구현이 자유롭지만, 반대로 이로 인해 테이블 주도 개발이 되기 쉽다.
이러한 차이로 미뤄 봤을 때, 두 가지 용어의 차이점은 DDD의 aggregate root에서 도출해낸 단위인지, 아니면 단순히 테이블을 기준으로 도출해낸 단위인지에 따라 달라지는 것 같다. entity가 rich해야 한다는 말도 있는데, 이는 구현하기 나름이니까. 이것도 아마 어제 생각해봤던 개념과 구현의 차이에서 오는 혼동이 아닌가 싶다. entity가 rich해야 하는건 구현의 결과인거고 기본적으로는 DDD에서 사용하는 용어이냐 아니냐와 그 용어를 어떻게 가져와서 사용하는지가 결정적 차이가 아닐까
공룡책을 읽다가 모르는 개념이 나왔다. 발표 준비 할 때 참고하자.
Marsharlling은 여기에 통신의 개념이 추가 된 것이다. 두 가지를 혼용하여 쓰는 경우도 있지만, 통신이 이루어지거나 통신을 위해 객체를 바이트 스트림으로 변경하는 뉘앙스가 더 강한 것 같다.
컨트롤러 테스트를 추가했다. 인수테스트라고 할 수 있을지 모르겠으나, 어쨌든..
인코딩에서 애를 먹었는데, 예전에도 비슷한 문제가 있었던 것 같다. MockMvc
를 생성할 때 필터를 걸어주면 되는데, WebMvcTest를 사용할 경우는 이게 쉽지 않으니 강제로 response를 인코딩하도록 서블릿 옵션을 추가해줬다. 그런데 지금 생각해보니 어플리케이션 컨텍스트를 가져와도 상관없지 않나? 라는 생각이 들었다. 스프링을 이용하여 테스트 하려면 해당 컨트롤러만 들어있는 컨텍스트가 존재는 할테니까.
이외에 결과를 어떻게 판단할지 고민이 많은데, 리스폰스 바디를 잭슨으로 객체화시켜 비교하도록 했다. 좋은 방법인지 모르겠지만 더 좋은 방법이 생각나지 않는다.
지도 검색 시 내 위치(현재 위치는 숙소 검색에 적합하지 않을 수 있다?)
하지만 그렇게 하지 않으면 위치 검색을 해야하기 때문에 나중에 생각
알고리즘
Powered with by Gatsby 2.0