2021 06 04

atdd-subway-fare 피드백 사안¶

단위 테스트 작성하기 - 인수 테스트와 무관하게 작성하자 - 해당 기능이 변경되었을 때 빠르게 피드백 받아야함 - 인수 테스트는 이게 힘듦

Domain에서 검증하기 VS RequestDto에서 검증하기 - 각 Layer 별로 적절한 유효성 검사는 필요 - 확장성을 고려하여 각자 Validation의 기준을 잡자 - 그리고 앞단에서 valid 된 것은 신뢰하고 사용하자

기존 jdbc는 변수 매핑 "?" 로 했지만, NamedParameterJdbcTemplate은 변수명으로 매핑 가능 - :variable로 구분
기본적으로 변수를 Map 객체를 통해 받아서 적용
Map 객체를 통해 받아서 적용시킴 - NamedParameterJdbcTemplate.queryForObject(sql, params(Map), rowMapper) : 한 줄의 열 처리 - NamedParameterJdbcTemplate.update(sql, params, rowMapper) : Delete, Insert, Update 처리
NamedParameterJdbcTemplate - sql문에 파라미터 매핑 시 이름을 기반으로 해서 매핑시킬 수 있음 - Map을 생성해서 key로 이름, value에 넣을 값 투척

참고: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/namedparam/BeanPropertySqlParameterSource.html
SqlParameterSource의 구현체로, 주어진 JavaBean 객체의 속성에서 매개변수 값을 가져옴
Bean Property의 이름과 매개 변수 이름과 일치할 것
Bean 객체를 Map 객체로 변환
생성할 때 인자로 자바빈 클래스 넣어주면, 자동의 Bean 클래스 변수와 쿼리안의 : 콜론과 붙여쓰는 이름을 같게 해주면 자동 매핑

Dao 메서드들의 파라미터에 테이블과 1:1로 대응되는 변수들을 넘겨주기 - 해당 방식의 장점으로는 파라미터 자체로 Dao에 필요한 정보를 강제하기 때문에, Dao단에서 필요한 정보가 없어 실수할 일이 없었음
- DB로의 접근 쿼리와 실행로직만 필요했고, 비즈니스 로직이 없었기에 Dao를 얇게 유지할 수 있었음 - DB 접근의 실수를 최소화 할 수 있을 것 같음

도메인 자체를 Dao의 파라미터로 넘겨주기 - Dao 메서드 내부에서 필요한 정보를 도메인에서 추출하여 사용하게 됨 - 이렇다면 테이블의 필드와 도메인의 필드가 일치해야 할 것 - 이렇게 된다면, Dao의 메서드 파라미터를 통해 DB에 필요한 정보를 노출시키는 일이 없을 것
- 도메인의 필드만 수정하면 되니 유지보수에도 어쩌면 더 유리할 수 있음

참고 1: https://johngrib.github.io/wiki/spring-annotation-profile/
참고 2: https://2ham-s.tistory.com/259
하나 이상의 지정된 profile이 활성화되어 있다면 해당 profile의 설정을 등록할 수 있음 - ConfigurableEnvironment.setActive~~ 이걸로 프로그래밍 방식으로 활성화 - spring.profiles.active 속성을 JVM 시스템 속성이나 환경 변수로 지정 - web.xml에서 servlet context 파라미터 설정
스프링 부트 애플리케이션의 런타임 환경 관리 - 테스트 환경에서 실행? 프로덕션 환경에서 실행?
@Profile에 인자로 들어가는 값은 Profile이 현재 인자값과 일치할 시 아래 코드에서 명시한 스프링 빈 등록하라는 뜻!
- 각 환경에 맞게 Spring의 Bean들을 올릴 수 있도록!!!