[team-11 이노] FE, iOS에 따른 GitHub OAuth 구현, 프로젝트 API 구현

[eNoLJ]

새롭게 구현한 부분

• FE, iOS 각 어플리케이션에서 login 요청시 typeCode를 파라미터로 받아 구분하여 처리 하였습니다.
• JDBC Template을 사용하여 DAO를 만들어 사용했습니다.

이번에 처음 JDBC Template을 사용하면서 궁금한 점이 하나 생겼습니다.

DAO에서 쿼리에 해당하는 엔티티 클래스로 매핑을 진행했습니다. 여기서 궁금한 점이 생겼는데 테이블 join 시 컬럼이 늘어나게 되고 매핑 가능한 엔티티 클래스가 없어집니다. 이 때 엔티티 클래스가 아닌 별도의 클래스를 만들어 매핑을 진행하는 것이 좋은지 아니면 엔티티 클래스로 매핑하여 가져 온 뒤 코드 상에서 변환을 해주는 것이 좋은지 의견 주시면 감사하겠습니다.

전자의 경우 필요한 정보들을 얻기 위해 여러 DAO를 사용해야하는 단점이 있고, 후자의 경우 한번의 쿼리로 필요한 정보들을 얻을 수 있다는 장점이 있는 반면 엔티티 클래스가 아닌 다른 클래스가 db와 접촉을 한다는게 찝찝합니다. 그리고 그렇게 되면 자연스레 비지니스 로직 또한 매핑을 위해 새로 만든 별도의 클래스에 생기게 되는데 비지니스 로직은 service와 entity 에서 처리를 해줘야하는 걸로 알고 있어서 더 헷갈리네요.

지난 프로젝트에서는 API 만들어 지는게 늦어져 PR을 못 보냈기 때문에 엄청 오랜만에 PR을 보내게 되었네요.
OAuth든 JDBC Template이든 새롭게 적용한 것들이 많아 부족한 부분이 많으리라 생각됩니다. 사소한거 하나하나 다 지적해주시면 최대한 다 반영하도록 하겠습니다.
이번 리뷰도 잘 부탁드립니다!!

[eNoLJ]

@ksundong
으어어어 디온!!!
현재 적용 안된 리뷰가

application.properties 하나로 관리
uri 빌더 bean으로 만들어주기
user에 static 메소드 제거
URL path 설계
OAuth 판별은 host로

- dao 관련
필드 분리
사용자 지정 RowMapper 사용
stream안에 db접근 x
findAll 에는 WHERE, LIMIT 사용

정도인데 이렇게 주저리 말씀드리는 이유는 디온이 정말 정성스레 리뷰를 해주셨는데 다 하지 못할 수도 있을 것 같아 죄송해서 말씀드립니다.
이번에 다 못하더라고 꼭 잊지않고 다음 프로젝트에서 하나하나 적용해보도록 하겠습니다. 기회가 된다면 다음 프로젝트에서 pr 날릴 때 봐주세요!!
이번 리뷰로도 많이 배웠고 정말 너무너무 감사드립니다!!!!