[레벨2] 지하철 노선도 협업 미션 학습로그

[Spring] NamedParameterJdbcTemplate - 3

내용

• JDBC 를 위한 템플릿 클래스
• 기존의 쿼리문 파라미터에 '?' 를 사용하는 대신 매개 변수명을 정해서 사용할 수 있습니다.

public int countOfActorsByFirstName(String firstName) {

    String sql = "select count(*) from T_ACTOR where first_name = :first_name";

    SqlParameterSource namedParameters = new MapSqlParameterSource("first_name", firstName);

    return this.namedParameterJdbcTemplate.queryForObject(sql, namedParameters, Integer.class);
}

• Map 을 사용해서 파라미터에 매핑할 수도 있습니다.
  • 이때 키(key)는 매개 변수명
  • 값(value)은 매개 변수에 넣을 데이터

public int countOfActorsByFirstName(String firstName) {

    String sql = "select count(*) from T_ACTOR where first_name = :first_name";

    Map<String, String> namedParameters = Collections.singletonMap("first_name", firstName);

    return this.namedParameterJdbcTemplate.queryForObject(sql, namedParameters,  Integer.class);
}

• SqlParameterSource 인터페이스를 사용하여 몇가지 구현체들을 사용할 수 있습니다.
  • MapSqlParameterSource : 이름에서도 유추할 수 있듯이 Map 을 내부적으로 가지며 키(key)를 매개변수, 값은 데이터로 이뤄집니다.
  • BeanSqlParameterSource : Object 타입을 파라미터로 하는 생성자를 가지는데 인자로 받은 객체가 Java빈을 준수했다면 자동으로 필드이름과 값을 매핑합니다.(이때  필드 변수명과 쿼리문의 매개변수명은 같아야합니다.)

참고자료

- https://docs.spring.io/spring-framework/docs/current/reference/html/data-access.html#spring-data-tier

 

---

[Spring] JdbcTemplate 을 빈으로 만들어서 사용하지 않는것을 추천 - 1

학습내용

•  JdbcTemplate는 아래와 같이 사용하는 것이 모범적인 사용

public class JdbcCorporateEventDao implements CorporateEventDao {

    private JdbcTemplate jdbcTemplate;

    public void setDataSource(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

    // JDBC-backed implementations of the methods on the CorporateEventDao follow...
}

• JdbcTemplate은 스레드 세이프하게 만들어짐
• 그렇다면 왜 빈으로 만들지 않고 Dao 마다 new 키워드를 통해 새로운 인스턴스를 만드는 것을 추천할까?
• 여러개의 다른 DB를 사용하게 되면 DataSource가 다른 여러개의 JdbcTemplate 인스턴스가 필요

---

[네트워크] Reverse Proxy - 2

학습내용

• Reverse Proxy는 우리가 만드는 WAS(Web Application Server)에 비지니스 로직만 담고 부가적인 기능은 다른곳이 대신 수행해줬으면 할 때 사용
• 통상의 Proxy는 LAN -> WAN의 요청을 대리로 수행. 
• ReverseProxy는 WAN -> LAN 의 요청을 대리로 수행.
• HTTP 요청 내용에 따른 시스템의 동작 제어
  • 클라이언트의 IP 주소를 보고 특정 IP 주소만 서버로의 접속을 허가
  • 클라이언트의 UserAgent를 보고 특별한 웹 서버로 접속되도록 유도
• 시스템 전체의 메모리 사용 효율 향상
  • 캐시 서버로 활용가능
  • 리소스 처리에 대한 부담을 덜 수 있음
• 웹 서버가 응답하는 데이터의 버퍼링의 역할
  • HTTP Keep-Alive로 서버와 한번 연결된 접속을 유지하는 것은 서버에 부하가 생기게 됨.
  • 클라이언트와 ReverseProxy 사이에만 Keep-Alive ON 을 사용하고 ReverseProxy와 WAS 사이에는 Keep-Alive OFF로 사용하면 WAS에 부하를 줄일 수 있습니다.
• SSL 처리를 WAS가 아닌 Reverse Proxy에서 담당할 수 있음

---

[설계] 프론트엔드와 협업 중 현재 도메인 설계에 맞지 않는 요구사항을 받았을 때 - 4

학습내용

• 협업을 진행하면서 프론트엔드 측에서 현재 도메인 설계에서는 불가능한(또는 가능하지만 복잡한 로직을 짜야함) 구조의 데이터를 요구
  • 하나의 노선 응답에 역목록과 각각의 역에서 환승 가능한 노선 정보를 담아주세요
• 도메인 설계를 바꿀지, 복잡한 쿼리 + DTO로 해결할 지 고민을 진행
  • 현재 시간이 없으므로 도메인 설계를 바꾸는 것은 불가능하다 판단
  • 빠른 요구사항 충족을 위해(프론트엔드 크루의 미션진행) 복잡한 쿼리와 DTO로 해결을 결정
• 복잡한 조회의 경우 쿼리와 DTO로 해결하는 것이 좋음
  • 단 자주 사용되는 조회가 아닌 특별한 상황에서만 사용하는 복잡한 조회를 의미
• 비지니스적인 관점, 성능, 라이프 사이클 등등 많은것들을 고려해야함

---