스프링 MVC 1편 - 백엔드 웹개발 핵심기술 섹션 3 수강

섹션 3. 서블릿, JSP, MVC 패턴 수강 완료!!

이번 강의는 실습 위주로 진행해서 딱히 정리할 게 많지 않다... 다 코드라...

아무튼 처음엔 서블릿으로 회원 관리 웹 애플리케이션을 만들었다.
그런데 서블릿과 자바 코드만으로 HTML을 만들었더니 너무 번거롭고 비효율적이었다. 차라리 HTML 문서에 동적으로 변경해야 하는 부분만 자바 코드를 넣는 것이 더 편리할 것이다.

➡️ 템플릿 엔진(JSP, Thymeleaf 등)을 사용하면 HTML 문서에서 필요한 곳만 코드를 적용해 동적으로 변경할 수 있다.

---

JSP는 자바 코드를 그대로 다 사용할 수 있다.

<%@ page import="hello.servlet.domain.member.MemberRepository" %>
➡️ 자바의 import문과 같다.

<% ~~ %>
➡️ 자바 코드를 입력할 수 있다.

<%= ~~ %>
➡️ 자바 코드를 출력할 수 있다.

JSP를 사용한 덕분에 동적으로 변경이 필요한 부분에만 자바 코드를 적용할 수 있었다. 하지만 이 경우 JSP가 너무 많은 역할을 한다. 그래서 이를 해결하기 위해 MVC 패턴이 등장했다.

---

하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면 너무 많은 역할을 하게 되고 유지보수가 어려워진다.
JSP 같은 뷰 템플릿은 화면을 렌더링 하는 데 최적화되어 있기 때문에 이 부분의 업무만 담당하는 것이 가장 효과적이다.

---

Model View Controller

MVC 패턴은 하나의 서블릿이나 JSP로 처리하던 것을 Controller와 View라는 영역으로 서로 역할을 나눈 것을 말한다.

• Controller: HTTP 요청을 받아 파라미터를 검증하고 비즈니스 로직을 수행한다. 뷰에 전달할 결과 데이터를 조회하여 모델에 담는다.

• Model: 뷰에 출력할 데이터를 담아둔다.

• View: 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다.
  
  

Model은 HttpServletRequest 객체를 사용한다.
request는 내부에 데이터 저장소를 가지고 있는데, request.setAttribute(), request.getAttribute()를 사용하면 데이터를 보관하고 조회할 수 있다.

/WEB-INF
➡️ 이 경로 안에 JSP가 있으면 외부에서 직접 JSP를 호출할 수 없다. 컨트롤러를 통해서 JSP를 호출해야 한다.

---

MVC 패턴을 적용한 덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있었다.
하지만 컨트롤러는 중복이 많고 필요하지 않은 코드들도 많이 있었다. 또한, 기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많아질 것이다.
이 문제를 해결하려면 컨트롤러 호출 전에 먼저 공통 기능을 처리해야 한다.

➡️ Front Controller 패턴을 도입하면 이런 문제를 깔끔하게 해결할 수 있다.

---

토픽

+)22. 07. 18. 추가 완료!

1. JPA Entity Manager

엔티티 매니저(Entity Manager)는 커밋 시점에 영속성 컨텍스트(Persistence Context)에서 관리하고 있던 영속 객체의 변경 내역을 추적하여 데이터베이스에 반영하는 역할을 한다.

---

영속성 컨텍스트(Persistence Context)

그럼 영속성 컨텍스트란 무엇일까?
영속성 컨텍스트란 일종의 메모리 저장소로, 엔티티 타입과 식별자를 키로 사용하는 객체의 집합을 의미한다.
이렇게 설명하면 좀 어렵지만, ‘엔티티를 영구 저장하는 환경‘이라고 생각하면 쉽다.

EntityManager.persist(entity);
⬆️ 이렇게 엔티티 매니저를 통해 영속성 컨텍스트에 접근한다.

그런데, 이렇게 영속성 컨텍스트를 사용할 필요 없이 그냥 바로 DB에 데이터를 넣으면 안 될까? 왜 굳이 영속성 컨텍스트를 쓰는 걸까?
영속성 컨텍스트를 쓰는 이유는 다음과 같은 이점이 있기 때문이다.

1차 캐시

Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
    
//1차 캐시에 저장됨
em.persist(member);
    
//1차 캐시에서 조회
Member findeMember = em.find(Member.class, "member1");

em.find로 member1을 조회하면 DB에 가서 찾는 것이 아니라 1차 캐시부터 가서 찾는다.

1차 캐시는 트랜잭션이 시작하고 종료될 때까지만 유지되는 캐시다.

만약 member2를 찾는다면 1차 캐시에 없는 걸 확인하고 DB에서 조회한다. 그리고 1차 캐시에 저장한 뒤 반환한다.

동일성(identity) 보장

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
    
System.out.println(a == b); //동일성 비교 true

트랙잭션을 지원하는 쓰기 지연(transactional write-behind)

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
    
//엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
transaction.begin(); //[트랜잭션] 시작
    
em.persist(memberA);
em.persist(memberB);
//여기까지 INSERT SQL을 DB에 보내지 않는다.
    
//커밋하는 순간 DB에 INSERT SQL을 보낸다.
transaction.commit(); //[트랜잭션] 커밋

em.persist 하는 순간 INSERT SQL을 생성하고 쓰기 지연 SQL 저장소에 쿼리를 넣어놓는다. (DB에 안 넣고 기다린다.)
이렇게 쓰기 지연 SQL 저장소에 있는 쿼리를 DB에 보내는 과정을 플러시(flush)라 한다.

• 플러시가 발생할 때 실행되는 것
  • 변경 감지
  • 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
  • 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송(등록, 수정, 삭제 쿼리)

• 영속성 컨텍스트를 플러시하는 방법
  • em.flush() - 직접 호출
  • 트랜잭션 커밋 - 플러시 자동 호출
  • JPQL 쿼리 실행 - 플러시 자동 호출
    
    

변경 감지(Dirty Checking)
데이터 변경 시 엔티티와 스냅샷을 비교해 바뀐 부분이 있나 찾아보고 자동으로 UPDATE 쿼리문을 실행한다.
더 자세한 내용은 아래에 정리해놓았다.

지연 로딩(Lazy Loading)

@Entity
public class Member {
    
	@Id
	@GeneratedValue
	private Long id;
    
	@Column(name = "USERNAME")
	private String name;
    
	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "TEAM_ID")
	private Team team;
	...
}

단순히 member 정보만 사용하는 비즈니스 로직 println(member.getName()); 을 실행할 땐 Team까지 조회할 필요 없이 Member만 조회(em.find)하면 될 것이다.

Member member = em.find(Member.class, 1L);

이 때 LAZY를 사용할 경우 Team에 프록시 객체라는 가짜 객체가 들어가게 된다.

Team team = member.getTeam();
team.getName(); //실제 team을 사용하는 시점에 초기화한다. (DB 조회)

만약 지연 로딩이 아닌 즉시 로딩을 사용할 경우 예상치 못한 SQL이 발생할 수 있으며, JPQL에서 N+1 문제를 일으킨다.

---

엔티티 매니저(Entity Manager)

엔티티 매니저를 생성할 때 하나의 영속성 컨텍스트가 생성된다.
만약 동일한 식별자를 갖는 엔티티를 2번 조회한다면 엔티티 매니저에 의해 첫 번째는 쿼리가 실행되고, 두 번째는 쿼리가 실행되지 않고 영속성 컨텍스트에서 값을 가져온다.

엔티티 매니저는 DB에 액세스 하기 위해 사용되는 객체이므로 이를 통해 데이터를 조회, 등록, 수정, 삭제하는 작업을 수행한다.

---

엔티티 매니저 종류

1. 애플리케이션에서 관리하는 엔티티 매니저

   • 애플리케이션을 시작하면서 EntityManagerFactory를 초기화하고, 필요한 상황에서 EntityManager를 생성하여 사용한다.

   • EntityManager의 사용을 마치면 close하여 종료한다.

   • 애플리케이션 코드에서 엔티티 매니저를 관리하기 때문에 자원 누수에 대한 문제가 발생할 수 있다. (close를 안 해 줄 경우 메모리에 계속 축적될 수 있음.)

2. 컨테이너에서 관리하는 엔티티 매니저

   • JEE 컨테이너에서 EntityManagerFactory와 EntityManager의 라이프 사이클을 관리한다.

   • 애플리케이션 코드에서는 컨테이너가 제공하는 엔티티 매니저를 사용하면 된다. (별도의 close를 해 줄 필요가 없음.)

   • @PersistenceContext를 사용하여 구현한다.

   → 스프링에서 사용하는 JPA가 이런 방식이다.

---

참고 자료

1. 어라운드허브 스튜디오, “영속성 컨텍스트와 엔티티 매니저”, https://youtu.be/XlL0eq9Phws

2. SKplanet Tacademy, “JPA 프로그래밍 기본기 다지기 6강 - JPA 내부구조”, https://youtu.be/PMNSeD25Qko

---

2. JPA Dirty Checking

Dirty Checking이란 변경 감지를 말한다.
길게 말할 것 없이 아래 코드를 예시로 알아보자.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); //[트랜잭션] 시작

//영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

//영속 엔티티 데이터 수정
memberA.setUsername("rose");
memberA.setAge(100);

//em.update(member) <- 이런 코드가 있어야 하지 않을까?

transaction.commit(); //[트랜잭션] 커밋

만약 내가 유저 네임을 rose로, 나이를 100살로 바꿨다고 해보자.
그럼 이 때 내가 update를 하거나 persist를 다시 해 줘야 하지 않을까? JPA에게 데이터가 바뀌었다는 걸 알려줘야 하지 않을까? 싶을 것이다.
하지만 따로 그럴 필요 없이 commit만 하면 자동으로 업데이트 쿼리가 실행된다.

그럼 얘는 내가 데이터를 수정했다는 걸 어떻게 알까?
그건 바로 스냅샷 덕분이다.
JPA에서는 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷을 만들어놓는다.

플러시(영속성 컨텍스트의 변경 내용을 DB에 반영) 되는 순간 엔티티와 스냅샷을 비교해 바뀐 게 있다면 UPDATE 쿼리를 생성하여 DB에 보낸다.

영속성 컨텍스트에서 관리하는 데이터들은 어떤 것이 변경됐는지 걔네들이 다 안다. 그래서 우리가 따로 알려줄 필요가 없는 것이다. (→ 준영속, 비영속 상태의 엔티티는 더티 체킹 대상에 포함되지 않는다.)

참고
더티 체킹으로 생성되는 UPDATE 쿼리는 기본적으로 전체 필드를 업데이트 한다.
만약 변경된 필드만 업데이트 하고 싶을 경우, 엔티티 최상단에 @DynamicUpdate 를 선언하면 된다.

그럼 왜 em.update 뭐 이런 걸 안 쓰고 더티 체킹을 쓰는 걸까?
자바 컬렉션을 예로 들어보자.
리스트에서 데이터를 가져오고 값을 변경하면 그 후에 우리가 무슨 행위를 한 적이 있나? 우리는 리스트에 다시 값을 담지 않는다. 아무 행위를 하지 않아도 알아서 리스트에 바뀐 값이 저장된다.
마치 자바 컬렉션에서 값을 가져와 변경하는 것처럼 사용하기 위해 더티 체킹을 쓰는 것이다. 즉, 영속 상태의 데이터를 가져와서 바꾸고 커밋만 하면 된다.
이것이 바로 더티 체킹을 쓰는 이유다.

---

참고 자료

1. SKplanet Tacademy, “JPA 프로그래밍 기본기 다지기 6강 - JPA 내부구조”, https://youtu.be/PMNSeD25Qko

2. “더티 체킹 (Dirty Checking)이란?”, 기억보단 기록을, https://jojoldu.tistory.com/415

---

프로그래머스 코테 1문제

+) 22. 07. 21. 추가 완료!!

문자열 다루기 기본

⬆️ 문제 설명

⬇️ 내가 짠 코드

class Solution {
    public boolean solution(String s) {
        boolean answer = true;
        
        if(s.length() >= 1 && s.length() <= 8) {
            if(!((s.length() == 4 || s.length() == 6) && s.matches("^[0-9]*$"))) {
                answer = false;
            }
        }  
        
        return answer;
    }
}

점수는 12점 받음!! 굿!!

근데 뭔가 객체지향적으로(ㅎㅎ;;) 짜 보고 싶어서 인텔리제이 켜서 해 봄.

public class Main {
    public static void main(String[] args) {
        Main m = new Main();
        m.validateNumberLength("a234");
        m.validateNumber("a234");
        System.out.println(m.solution("a234"));
    }

    public boolean solution(String s) {
        boolean answer = true;
        if(!((s.length() == 4 || s.length() == 6) && s.matches("^[0-9]*$"))) {
            return answer = false;
        }

        return answer;
    }

    public void validateNumber(String s) {
        if(!(s.matches("^[0-9]*$"))) {
            throw new RuntimeException("숫자가 아닙니다.");
        }
    }

    public void validateNumberLength(String s) {
        if(!(s.length() >= 1 && s.length() <= 8)) {
            throw new IllegalArgumentException("s는 길이 1 이상 8 이하인 문자열입니다.");
        }
    }
}

물론 그지 같은 코드긴 한데;; 그래도 메서드를 한 번 나눠서 실행해 봤다. 같은 클래스 내에서 메서드 호출하는 법 맨날 헷갈렸는데 이제 좀 알겠음... 굿...

---

프로그래머스 sql문

+) 22. 07. 20. 추가 완료!!

IS NULL

1. 이름이 없는 동물의 아이디

SELECT ANIMAL_ID FROM ANIMAL_INS WHERE NAME IS NULL

2. 이름이 있는 동물의 아이디

SELECT ANIMAL_ID FROM ANIMAL_INS WHERE NAME IS NOT NULL

3. NULL 처리하기

SELECT ANIMAL_TYPE, IFNULL(NAME, 'No name') AS NAME, SEX_UPON_INTAKE FROM ANIMAL_INS ORDER BY ANIMAL_ID

➡️ 이거 자꾸 안 되길래 뭐가 문제지 했는데 'No name' 대소문자 때문이었음... 'No Name'으로 해서 안 되는 거였음...^^