Heee's Development Blog

[JUnit] JUnit5 사용법 - Parameterized Tests

Wed, 27 Nov 2019 00:00:00 +0000

계속해서 추가할 예정!

Maven Dependencies

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-params</artifactId>
    <version>5.4.2</version>
    <scope>test</scope>
</dependency>

testCompile("org.junit.jupiter:junit-jupiter-params:5.4.2")

Parameterized Tests

@ParameterizedTest
- 이 annotation을 추가하는 것을 제외하고는 다른 테스트와 동일하다.

e.g.

  @ParameterizedTest
  @ValueSource(ints = {1, 3, 5, -3, 15, Integer.MAX_VALUE}) // six numbers
  void isOdd_ShouldReturnTrueForOddNumbers(int number) {
      assertTrue(Numbers.isOdd(number));
  }

6번의 isOdd 메서드를 실행한다.
a source of arguments: an int array
a way to access them: the number parameter

1. Simple Value

@ValueSource
- 해당 annotation 에 지정한 배열을 파라미터 값으로 순서대로 넘겨준다.
- test method 실행 당 하나의 인수(argument) 만을 전달할 때 사용할 수 있다.
- 리터럴 값의 배열을 테스트 메서드에 전달한다.
- c.f. literal values 종류
  - short, byte, int, long, float, double, char, java.lang.String, java.lang.Class

e.g. 하나의 인수(String input)만을 가짐

  public class Strings {
      public static boolean isBlank(String input) {
          return input == null || input.trim().isEmpty();
      }
  }

  @ParameterizedTest
  @ValueSource(strings = {"", "  "})
  void isBlank_ShouldReturnTrueForNullOrBlankStrings(String input) {
      assertTrue(Strings.isBlank(input));
  }

2. Null and Empty Values

@NullSource
- primitive data 는 널(null) 값을 허용할 수 없으므로 primitive 인수에 @NullSource 를 사용할 수 없다.
@EmptySource
- 이 annotation 을 사용하여 빈 값을 인수에 전달할 수 있다.
- String 인수의 경우 ““(empty string), Collection types 과 Arrays 에도 빈 값을 넣을 수 있다.
@NullAndEmptySource
- null 값과 empty value 모두 전달하기 위해 해당 annotation 을 사용할 수 있다.
- @EmptySource와 마찬가지로 문자열, 컬렉션 및 배열에서 동작한다.
- 몇 가지 빈 문자열 변형을 parameterized test 로 전달하기 위해 @ValueSource, @NullSource 및 @EmptySource를 함께 결합할 수 있다.
```
  @ParameterizedTest
  @NullAndEmptySource
  void isBlank_ShouldReturnTrueForNullAndEmptyStrings(String input) {
  assertTrue(Strings.isBlank(input));
  }
```

3. Enum

@EnumSource
- enumeration(열겨형) 값의 배열을 테스트 메서드에 전달한다.
- test method 실행 당 하나의 인수(argument) 만을 전달할 때 사용할 수 있다.
- names 속성
  - 리터럴 문자열 외에도 정규 표현식(regular expression)을 names 속성에 전달할 수 있다.
  - 기본적으로 names 속성은 일치하는 enum 값을 가진다.
  - mode 속성을 EXCLUDE 로 설정하면 제외하는 enum 값을 가질 수 있다.

e.g. 모든 월(Month enum)을 확인하여 월 숫자가 1과 12 사이에 있는지 확인하는 경우

  @ParameterizedTest
  @EnumSource(Month.class) // passing all 12 months
  void getValueForAMonth_IsAlwaysBetweenOneAndTwelve(Month month) {
      int monthNumber = month.getValue();
      assertTrue(monthNumber >= 1 && monthNumber <= 12);
  }

e.g. 월의 ‘이름’ 속성을 사용하여 특정 개월만 선택하는 경우 (4, 6, 9, 11월의 기간이 30일인지 확인)

  @ParameterizedTest
  @EnumSource(value = Month.class, names = {"APRIL", "JUNE", "SEPTEMBER", "NOVEMBER"})
  void someMonths_Are30DaysLong(Month month) {
      final boolean isALeapYear = false;
      assertEquals(30, month.length(isALeapYear));
  }

e.g. 2, 4, 6, 9, 11월을 제외한 월의 기간이 31일인지 확인하는 경우

  @ParameterizedTest
  @EnumSource(
    value = Month.class,
    names = {"APRIL", "JUNE", "SEPTEMBER", "NOVEMBER", "FEBRUARY"},
    mode = EnumSource.Mode.EXCLUDE)
  void exceptFourMonths_OthersAre31DaysLong(Month month) {
      final boolean isALeapYear = false;
      assertEquals(31, month.length(isALeapYear));
  }

4. Method

@MethodSource
- 위의 argument sources들은 복잡한 object를 사용하여 전달하는 것이 어렵거나 불가능하다. 보다 복잡한 인수를 제공하는 방법 중 한 가지는 method를 argument source로 사용하는 것이다.
- 즉, @MethodSource는 test method 실행 당 복잡한 인수 를 전달할 때 사용하는 방법이다.
  - test method 호출 당 하나의 인수(argument)를 전달하는 경우는 <Arguments> 추상화를 사용하지 않아도 된다.
- @MethodSource 에 설정하는 이름은 존재하는 메서드 이름이어야 한다.
  - 이름을 설정하지 않으면 JUnit은 test method와 이름이 같은 source method를 찾는다.
- argument source method 조건
  - Stream<Arguments> (혹은 Iterable, Iterator) 또는 List와 같은 컬렉션과 유사한 interface 를 반환할 수 있다.
  - 클래스 단위 생명 주기가 아닌 경우, static method 여야 한다.
- @MethodSource를 이용하면 다른 테스트 클래스 간에 인수를 공유하는 것이 유용하다.
  - 이 경우 정규화된 이름 (FQN#methodName format)으로 현재 클래스 외부의 source method 를 참조할 수 있다.

e.g. 기본 사용 예제 - 복잡한 인수(String input, boolean expected)를 가짐

  @ParameterizedTest
  @MethodSource("provideStringsForIsBlank") // needs to match an existing method.
  void isBlank_ShouldReturnTrueForNullOrBlankStrings(String input, boolean expected) {
      assertEquals(expected, Strings.isBlank(input));
  }

  // a static method that returns a Stream of Arguments
  private static Stream<Arguments> provideStringsForIsBlank() { // argument source method
      return Stream.of(
        Arguments.of(null, true),
        Arguments.of("", true),
        Arguments.of("  ", true),
        Arguments.of("not blank", false)
      );
  }

e.g. 외부 source method 참조 예제

  class StringsUnitTest {
      @ParameterizedTest
      @MethodSource("com.baeldung.parameterized.StringParams#blankStrings") // 클래스 외부의 source method
      void isBlank_ShouldReturnTrueForNullOrBlankStringsExternalSource(String input) {
          assertTrue(Strings.isBlank(input));
      }
  }

  public class StringParams {
      static Stream<String> blankStrings() {
          return Stream.of(null, "", "  ");
      }
  }

References

Guide to JUnit 5 Parameterized Tests

[JUnit] JUnit5 사용법 - 기본

Tue, 26 Nov 2019 00:00:00 +0000

계속해서 추가할 예정!

Maven Dependencies

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>5.1.0</version>
    <scope>test</scope>
</dependency>

testRuntime("org.junit.jupiter:junit-jupiter-engine:5.1.0")

1. 기본 Annotation

@BeforeAll and @BeforeEach

@BeforeAll
- 해당 annotation 이 달린 메서드가 현재 클래스의 모든 테스트 메서드보다 먼저 실행된다.
- 해당 메서드는 static 이어야 한다.
- 이전의 @BeforeClass 와 동일
@BeforeEach
- 해당 annotation 이 달린 메서드가 각 테스트 메서드 전에 실행된다.
- 이전의 @Before 와 동일

@BeforeAll
static void setup() {
    log.info("@BeforeAll - executes once before all test methods in this class");
}
@BeforeEach
void init() {
    log.info("@BeforeEach - executes before each test method in this class");
}

@DisplayName and @Disabled

@DisplayName
- 테스트 클래스 또는 테스트 메서드의 이름을 정의할 수 있다.
@Disable
- 테스트 클래스 또는 메서드를 비활성화할 수 있다.
- 이전의 @Ignore 와 동일

@DisplayName("Single test successful")
@Test
void testSingleSuccessTest() {
    log.info("Success");
}
@Test
@Disabled("Not implemented yet")
void testShowSomething() {
}

@AfterEach and @AfterAll

@AfterAll
- 해당 annotation 이 달린 메서드가 현재 클래스의 모든 테스트 메소드보다 이후에 실행된다.
- 해당 메서드는 static 이어야 한다.
- 이전의 @AfterClass 와 동일
@AfterEach
- 해당 annotation 이 달린 메서드가 각 테스트 메서드 이후에 실행된다.
- 이전의 @After 와 동일

@AfterAll
static void done() {
    log.info("@AfterAll - executed after all test methods.");
}
@AfterEach
void tearDown() {
    log.info("@AfterEach - executed after each test method.");
}

2. Assertions and Assumptions

Assertions

org.junit.jupiter.api.Assertions로 이동

assertTrue, assertThat 등

  @Test
  void lambdaExpressions() {
      assertTrue(Stream.of(1, 2, 3)
        .stream()
        .mapToInt(i -> i)
        .sum() > 5, () -> "Sum should be greater than 5");
  }

assertAll

  @Test
  void groupAssertions() {
      int[] numbers = {0, 1, 2, 3, 4};
      assertAll("numbers",
          () -> assertEquals(numbers[0], 1),
          () -> assertEquals(numbers[3], 3),
          () -> assertEquals(numbers[4], 1)
      );
  }

assertAll()을 사용하여 assertions 을 그룹화하여 그룹 내에서 실패한 assertions 을 MultipleFailuresError 와 함께 기록할 수 있다.
즉, 실패의 정확한 위치를 정확히 파악할 수 있기 때문에 보다 복잡한 assertions 을 만들어도 안전하게 사용할 수 있다.

Assumptions

특정 조건이 충족되는 경우에만 테스트를 실행하는 데 사용된다.
- 일반적으로 테스트가 제대로 실행되기 위해 필요한 외부 조건에 사용된다.
- 테스트와 직접적인 관련은 없다.
assumptions 이 실패하면 TestAbortedException이 발생하고 테스트는 수행되지 않는다.

assumeTrue(), assumeFalse(), and assumingThat()

  @Test
  void trueAssumption() {
      assumeTrue(5 > 1);
      assertEquals(5 + 2, 7);
  }
  @Test
  void falseAssumption() {
      assumeFalse(5 < 1);
      assertEquals(5 + 2, 7);
  }
  @Test
  void assumptionThat() {
      String someString = "Just a string";
      assumingThat(
          someString.equals("Just a string"),
          () -> assertEquals(2 + 2, 4)
      );
  }

3. Exception Testing

assertThrows()

두 가지 예외 테스트 방법

모두 assertThrows() 메서드를 사용하여 구현할 수 있다.

발생한 예외의 세부 사항을 확인

  @Test
  void shouldThrowException() {
  Throwable exception = assertThrows(UnsupportedOperationException.class, () -> {
    throw new UnsupportedOperationException("Not supported");
  });
  assertEquals(exception.getMessage(), "Not supported");
  }

예외 유형의 유효성을 검사

  @Test
  void assertThrowsException() {
  String str = null;
  assertThrows(IllegalArgumentException.class, () -> {
    Integer.valueOf(str);
  });
  }

4. Test Suites

@SelectPackages

Test Suites 를 실행할 때 선택할 패키지 이름 지정

  @RunWith(JUnitPlatform.class)
  @SelectPackages("com.baeldung")
  public class AllUnitTest {} 

@SelectClasses

Test Suites 를 실행할 때 선택할 클래스 지정

  @RunWith(JUnitPlatform.class)
  @SelectClasses({AssertionTest.class, AssumptionTest.class, ExceptionTest.class})
  public class AllUnitTest {}

각 테스트는 하나의 패키지에 있지 않아도 된다.

5. Dynamic Tests

@TestFactory
- 해당 annotation 이 달린 메서드는 동적 테스트를 위한 test factory 메서드이다.
- 런타임에 생성된 테스트 케이스를 선언하고 실행할 수 있다.
- e.g. 각각 in, out 이라는 두 개의 ArrayList 를 사용하여 단어를 번역한다.
```
  @TestFactory
  public Stream<DynamicTest> translateDynamicTestsFromStream() {
      return in.stream()
        .map(word ->
            DynamicTest.dynamicTest("Test translate " + word, () -> {
              int id = in.indexOf(word);
              assertEquals(out.get(id), translate(word));
            })
      );
  }
```
- @TestFactory 메서드는 private 또는 static 이면 안된다.
- 테스트 수는 동적이며, ArrayList 크기에 따라 달라진다.
- @TestFactory 메서드는 Stream, Collection, Iterable 또는 Iterator 를 return 해야 한다.

6. ETC

@Nested
- 해당 annotation 이 달린 클래스는 중첩된 비정적(non-static) 테스트 클래스 임을 나타낸다.
- 테스트 클래스 안에서 내부 클래스(Inner Class)를 정의해 테스트를 계층화할 수 있다.
- 내부 클래스로 정의하기 때문에 부모 클래스의 멤버 필드에 접근할 수 있고, Before/After 와 같은 테스트 생명주기에 관계된 메소드들도 계층에 맞게 동작한다.
@Tag
- 테스트 필터링을 위한 태그를 선언할 수 있다.
@ExtendWith
- 사용자 정의 확장명을 등록하는 데 사용된다.
@RepeatedTest
- @RepeatedTest(반복횟수) 를 이용하면 해당 테스트를 반복 실행할 수 있다.

References

[IntelliJ] intellij에서 JPA Entitiy 기반의 ERD 그리기

Mon, 28 Oct 2019 00:00:00 +0000

들어가기 전

Hibernate를 사용한 프로젝트를 기준으로 설명한다.

Persistence Tab 설정

File > Project Structure > Project Settings > Facets > [+] 버튼 클릭
JPA 선택 > Choose Module 창 > [“ERD를 확인할 프로젝트 명”.main] 선택
Project Settings > Modules > 위에서 생성한 JPA 선택
Default JPA Provider 를 Hibernate 로 선택

JPA Entity 기반의 ERD 확인하기

intellij 왼쪽의 Persistence Tab 생성 확인

기본적인 ER Diagram 확인

Persistence 클릭 > 확인하고자 하는 Entity 구조 우클릭 > ER Diagram 클릭

조금 더 상세한 ERD 확인

ERD 창 임의의 위치에서 우클릭 > Show Edge Labels 클릭

[JPA] 값 타입(2) - 컬렉션 타입

Fri, 13 Sep 2019 00:00:00 +0000

인프런 강의 참고

Goal

기본값 타입

임베디드 타입 (복합 값 타입)

값 타입과 불변 객체

값 타입의 비교

값 타입 컬렉션

JPA의 최상위 데이터 타입 분류 (2가지)

1. 엔티티 타입

@Entity로 정의하는 객체
데이터가 변해도 식별자로 지속해서 추적이 가능하다.
e.g. 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식이 가능하다.

2. 값 타입

int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
식별자가 없고 값만 있으므로 변경시 추적이 불가능하다.
e.g. 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체된다.

구체적인 데이터 타입 분류 (3가지)

기본값 타입
- 자바 기본 타입 (int, double)
- 래퍼 클래스 (Integer, Long)
- String
임베디드 타입 (embedded type, 복합 값 타입)
- JPA에서 정의해서 사용해야 한다.
- e.g. 좌표의 경우, Position Class
컬렉션 값 타입 (collection value type)
- 마찬가지로 JPA에서 정의해서 사용해야 한다.
- 컬렉션에 기본값 또는 임베디드 타입을 넣은 형태이다.

기본값 타입과 임베디드 타입 참고 POST

3. 값 타입 컬렉션(collection value type)

값 타입을 컬렉션에 담아서 쓰는 것을 말한다.
- 연관관계 매핑에서 엔티티를 컬렉션으로 사용하는 것이 아니라 값 타입을 컬렉션에 쓰는 것이다.
값 타입 컬렉션은 값 타입을 하나 이상 저장할 때 사용한다.

public class Member {
    @Id
    private Long id;
    
    private Set<String> favoriteFoods;
    private List<Address> addressHistory;
}

RDB에는 내부적으로 컬렉션을 담을 수 있는 구조가 없다. 그냥 값만 넣을 수 있는 구조이다.
- 컬렉션은 1:N 의 개념이기 때문에 DB는 컬렉션을 하나의 테이블에 저장할 수 없다.
- 이런 관계를 DB 테이블에 저장하려면 별도의 테이블(Join이 가능하도록)이 필요하다.
Q. FAVORITE_FOOD, ADDRESS 에서 모든 속성으로 pk로 잡는 이유?
- A. 해당 테이블은 값 타입인데, 하나를 식별자로 두는 개념을 도입하면 엔티티가 될 수도 있기 때문이다.
- 즉, 테이블에 값들만 저장하고 이들을 묶어서 pk로 사용한다.

구현 예시

@Entity
public class Member {
    ...
    @ElementCollection
    @CollectionTable(
        name = "FAVORITE_FOOD",
        joinColumns = @JoinColumn(name = "MEMBER_ID"))
    @Column(name = "FOOD_NAME") // 컬럼명 지정 (예외)
    private Set<String> favoriteFoods = new HashSet<>();

    @ElementCollection
    @CollectionTable(
        name = "ADDRESS",
        joinColumns = @JoinColumn(name = "MEMBER_ID"))
    private List<Address> addressHistory = new ArrayList<>();
    ...
}

기본 사용 어노테이션
- @ElementCollection, @CollectionTable 어노테이션을 사용한다.
과정
- Member 클래스에 값 타입 컬렉션을 추가한다.
- addressHistory는 임베디드 타입이므로 컬럼명들을 그대로 사용하면 된다.
- favoriteFoods는 String 하나(내가 만든 것이 아님)에 대한 Set이기 때문에 컬럼명을 지정해준다.
- memberId를 외래키로 지정한다.
  - 어떤 memberId에 소속되는지 알아야하기 때문에 연관 관계가 필요하다.

예제

컬렉션 값 타입 저장

Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(new Address("homeCity", "street", "10000"));

member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getFavoriteFoods().add("피자");

member.getAddressHistory().add(new Address("old1", "street1", "10001"));
member.getAddressHistory().add(new Address("old2", "street2", "10002"));

em.persist(member);

tx.commit();

먼저 Member가 저장되고 값 타입 컬렉션을 저장하는 별도의 테이블에 대한 INSERT Query가 6개 나갔다.
- 값 타입 컬렉션(다른 테이블)에 대한 persist를 하지 않았는데 쿼리가 나갔다.
- 즉, Member 객체의 라이프 사이클과 동일하게 적용되었다.
Why?
- 값 타입이기 때문이다.
- Member에 소속된 값 타입들의 라이프 사이클은 Member에 의존한다. (별도의 생명주기가 없음)
- 즉, 값 타입은 별도로 persist 또는 update를 할 필요가 없이 Member에서 값을 변경만 하면 자동으로 처리해준다.
- 1:N 연관 관계에서 Cascade=ALL로 설정하고, orphanRemoval=true 로 설정한 것과 유사하다.
c.f. 값 타입 컬렉션은 영속성 전이(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

컬렉션 값 타입 조회

// ... 위와 동일한 코드 

em.flush();
em.clear();

System.out.println("============ START ============");
Member findMember = em.find(Member.class, member.getId());
// em.persist(member);

tx.commit();

em.flush(), em.clear()로 영속성 컨텍스트를 비운 후 Member를 조회한다.
결과
- Member에 소속된 Embedded 타입의 Address 속성은 모두 같이 조회된다.
- 그러나 컬렉션들은 조회 되지 않는다.

즉, 컬렉션 값 타입들은 지연 로딩(Lazy Loading) 전략을 취한다.

  System.out.println("============ START ============");
  Member findMember = em.find(Member.class, member.getId());
  // 
  List<Address> addressHistory = findMember.getAddressHistory();
  for (Address address : addressHistory) {
      System.out.println("address = " + address.getCity());
  }
  // 
  Set<String> favoriteFoods = findMember.getFavoriteFoods();
  for (String favoriteFood : favoriteFoods) {
      System.out.println("favoriteFood = " + favoriteFood);
  }

Why? @ElementCollection(fetch = LAZY) 어노테이션의 fetch 기본값이 LAZY 이다.

컬렉션 값 타입 수정

값 타입 수정에 대한 기본 개념

  System.out.println("============ START ============");
  Member findMember = em.find(Member.class, member.getId());

  // homeCity -> newCity 
  // findMember.getHomeAddress().setCity("newCity"); // 틀린 방법 

  Address address = findMember.getHomeAddress();
  findMember.setHomeAddress(new Address("newCity", address.getStreet(), address.getZipCode())); // 새로 생성 

  tx.commit();

값 타입은 불변(Immutable)이어야 한다.
따라서, 수정하고 싶은 임베디드 타입의 속성이 있는 경우 새로운 인스턴스를 생성하여 통으로 갈아 끼워야 한다.
- e.g. 새로운 Address 인스턴스로 변경

컬렉션 값 타입 수정 예시1 - Set<String> 수정
```
 System.out.println("============ START ============");
 Member findMember = em.find(Member.class, member.getId());
 // 치킨 -> 한식 
 findMember.getFavoriteFoods().remove("치킨");
 findMember.getFavoriteFoods().add("한식");
```
- String은 불변 객체 이므로 삭제하고, 다시 리스트에 넣어준다.
- String 자체가 값 타입이므로 업데이트를 할 수가 없다. 위와 마찬가지로 통으로 갈아 끼워야 한다.
- 컬렉션의 값만 변경해도 JPA가 변경 사항을 알아 내서 실제 DB에 Query를 날린다.
  - (영속성 전이가 되는 것처럼)
- 컬렉션은 Member 소속의 단순한 값이기 때문에 Member에 모든 생명 주기를 맡긴다.

컬렉션 값 타입 수정 예시2 - List<Address> 수정

 System.out.println("============ START ============");
 Member findMember = em.find(Member.class, member.getId());
 // old1 -> newCity1
 findMember.getAddressHistory().remove(new Address("old1", "street1", "10001")); // equals 로 비교 
 findMember.getAddressHistory().add(new Address("newCity1", "street1", "10001"));

equals(), hashCode() 에 대한 제대로 된 재정의가 필요하다.
AddressHistory 테이블에서 Member 에 소속된 Address 를 모두 지운다.
- 테이블에 있는 데이터를 갈아 끼운다.
- old2, newCity1 에 대한 Address 를 새로 INSERT 한다.
아래 제약사항 참고!

값 타입 컬렉션의 제약사항

값 타입 컬렉션은 값 타입은 엔티티와 다르게 식별자 개념이 없다.

값은 변경하면 추적이 어렵다.

  Hibernate: 
      create table ADDRESS (
          MEMBER_ID bigint not null,
          city varchar(255),
          street varchar(255),
          zipcode varchar(255)
      )

ADDRESS 에는 id가 존재하지 않는다.
그렇기 때문에 값이 중간에 변경되었을 때 DB가 해당 row만을 찾아서 변경할 수 없다.

값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. (중요!)
- 대안
  - @OrderColumn(name = "address_history_order")를 사용하여 UPDATE Query가 날라갈 수 있도록 할 수 있다.
  - 그러나, 의도한 대로 동작하지 않을 때가 많다.
- 결론
  - 값 타입 컬렉션을 사용하지 말자.
  - 대부분이 엔티티이다.
  - e.g. 주소
- Q. 그럼 값 타입 컬렉션은 언제 사용?
  - A. 정말 단순한 경우! 추적할 필요도 없고 값이 바뀌어도 업데이트를 할 필요가 없을 때
  - e.g. select box 에서 [치킨, 피자, …] 중 여러 메뉴를 선택할 때
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다.
- null 입력 X
- 중복 저장 X

값 타입 컬렉션 대안

실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려하는 것이 낫다.
- 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용하자.
영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션처럼 사용하자.
- @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
- 실무에서 쿼리 최적화에도 유리하다.

대안에 대한 예시 코드

@Entity
public class Member {
    ...
    @ElementCollection
    @CollectionTable(
        name = "FAVORITE_FOOD",
        joinColumns = @JoinColumn(name = "MEMBER_ID"))
    @Column(name = "FOOD_NAME")
    private Set<String> favoriteFoods = new HashSet<>();

    // 변경 
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "MEMBER_ID")
    private List<AddressEntity> addressHistory = new ArrayList<>();
    ...
}

@Entity
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
@Table(name = "ADDRESS")
public class AddressEntity {

    @Id @GeneratedValue
    private Long id;

    private Address address; // 값 타입 
}

Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(new Address("homeCity", "street", "10000"));

member.getAddressHistory().add(new AddressEntity("old1", "street1", "10001"));
member.getAddressHistory().add(new AddressEntity("old2", "street2", "10002"));

em.persist(member);

em.flush();
em.clear();

과정
- Member 클래스에서 List<Address> 를 List 엔티티로 대체한다.
  - @OneToMany와 @JoinColumn 으로 1:N 단방향 매핑을 한다.
  - 영속성 전이(Cascade) + 고아 객체 제거
- AddressEntity 클래스에서 내부적으로 Address 값 타입을 포함한다.
개념
- ADDRESS 테이블에 ID 라는 개념이 생겼다. 또한 MEMBER_ID를 FK로 가진다.
  - 즉, 식별자가 있다는 것은 ADDRESS는 엔티티라는 것이고, 값을 가져와서 마음대로 수정할 수 있다.
- 값 타입을 엔티티로 승급화한다.
  - 실제 실무에서 많이 사용
- c.f. 1:N 단방향에서 ADDRESS 테이블에 UPDATE Query가 나가는 것은 어쩔 수 없다.
  - Why? 다른 테이블 (Member)에 외래키가 있기 때문에
  - UPDATE Query를 없애려면 1:N, N:1 양방향으로 변경

정리

엔티티 타입의 특징
- 식별자가 있다.
- 생명 주기를 관리 한다.
- 공유할 수 있다.
값 타입의 특징
- 식별자가 없다.
- 생명 주기를 엔티티에 의존한다. (내가 제어하지 못함)
- 공유하지 않는 것이 안전하다. (복사해서 사용)
- 불변 객체로 만드는 것이 안전하다. (어쩔 수 없이 공유되더라도 불변으로 만든다.)
값 타입은 정말 값 타입이라 판단될 때만 사용하자.
엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안된다.
식별자가 필요하고, 지속해서 값을 추적하고 변경해야 한다면 그것은 값 타입이 아닌 엔티티이다.

Reference

인프런 강의 참고

[JPA] 값 타입(1) - 기본값 타입, 임베디드 타입

Thu, 12 Sep 2019 00:00:00 +0000

인프런 강의 참고

Goal

기본값 타입

임베디드 타입 (복합 값 타입)

값 타입과 불변 객체

값 타입의 비교

값 타입 컬렉션

JPA의 최상위 데이터 타입 분류 (2가지)

1. 엔티티 타입

@Entity로 정의하는 객체
데이터가 변해도 식별자로 지속해서 추적이 가능하다.
e.g. 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식이 가능하다.

2. 값 타입

int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
식별자가 없고 값만 있으므로 변경시 추적이 불가능하다.
e.g. 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체된다.

구체적인 데이터 타입 분류 (3가지)

기본값 타입
- 자바 기본 타입 (int, double)
- 래퍼 클래스 (Integer, Long)
- String
임베디드 타입 (embedded type, 복합 값 타입)
- JPA에서 정의해서 사용해야 한다.
- e.g. 좌표의 경우, Position Class
컬렉션 값 타입 (collection value type)
- 마찬가지로 JPA에서 정의해서 사용해야 한다.
- 컬렉션에 기본값 또는 임베디드 타입을 넣은 형태이다.

1. 기본값 타입

종류

자바 기본 타입 (int, double)
래퍼 클래스 (Integer, Long)
String

특징

생명 주기를 엔티티에 의존한다.
- e.g. 회원을 삭제하면 이름, 나이 필드도 함께 삭제된다.
값 타입은 공유하면 안된다.
- Why? Side Effect가 발생할 수 있기 때문에
- e.g. 회원 이름 변경 시 다른 회원의 이름도 함께 변경되면 안된다.

참고

자바의 기본 타입은 절대 공유되지 않는다.
```
  int a = 20;
  int b = a; // 20이라는 값을 복사
  b = 10; 
```
- int, double 같은 기본 타입(primitive type)은 절대 공유되지 않는다.
- 기본 타입은 공유되지 않고 항상 값을 복사한다.
- 즉, Side Effect가 발생하지 않는다.
Integer 같은 래퍼 클래스나 String과 같은 특수한 클래스는 공유 가능한 객체이지만 변경은 불가능하다.
```
  Integer a = new Integer(10);
  Integer b = a; // a의 참조를 복사 
  a.setValue(20); // Side Effect!! 
```
- 10이 복사되는 것이 아니라 a의 레퍼런스가 넘어가서 같은 인스턴스를 공유한다.
- a.setValue(20) 에서 b값도 20으로 변경되는 Side Effect가 발생할 수 있다.
- 그래서! Java에서는 변경 자체를 불가능(Immutable)하게 만들어서 Side Effect를 막았다.

2. 임베디드 타입 (embedded type, 복합 값 타입)

새로운 값 타입을 직접 정의할 수 있다.
JPA는 임베디드 타입(embedded type, 내장 타입)이라고 한다.
주로 기본 값 타입을 모아서 만들기 때문에 복합 값 타입이라고도 한다.

예시

회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다.
- startDate, endDate / city, street, zipcode 는 공통 필드로 사용 가능
회원 엔티티는 이름, 근무기간, 집주소 가진다.
- 실 생활에서는 위와 같이 추상화해서 쉽게 표현한다.
- 즉, 위와 같이 묶을 수 있는 것이 임베디드 타입이다.
임베디드 타입으로 구현한 형태
- 클래스를 새로 뽑는다.

특징 및 장점

재사용이 가능하다.
클래스 내에서의 응집도가 높다.
Period.isWork() 처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있다.
- 객체지향적인 설계가 가능하다.
임베디드 타입도 int, String과 같은 값 타입이다. (중요!)
- 엔티티가 아니다. 엔티티의 값일 뿐이다.
- 추적이 되지 않기 때문에 변경하면 끝난다.
- 임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존한다.
임베디드 타입의 값이 null 이라면 매핑한 컬럼 값은 모두 null로 저장된다.

기본 사용법

기본 생성자는 필수이다.
@Embeddable
- 값 타입을 정의 하는 곳에 표시한다.
@Embedded
- 값 타입을 사용하는 곳에 표시한다.
c.f. @Embeddable, @Embedded 중 하나만 명시하면 되지만, 둘 다 적는 것을 권장한다.

임베디드 타입과 테이블 매핑

값 타입 / 임베디드 타입에 상관없이 DB 회원 테이블의 형태는 동일하다.

하지만 객체의 경우는 데이터 뿐만 아니라 그에 맞는 기능(메서드)를 가지고 있기 때문에 공통으로 묶은 임베디드 타입으로 구성하면 이점이 있다.

@Entity
public class Member {
  ...
  @Embedded
  private Address homeAddress;
  @Embedded
  private Address workAddress;
  ...
}

@Embeddable
@NoArgsConstructor
public class Address {
  private String city;
  private String street;
  private String zipcode;
  ...
}
@Embeddable
@NoArgsConstructor
public class Period {
  private LocalDateTime startDate;
  private LocalDateTime endDate;
  ...
}

이점?
- 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다. (중요!)
  - 임베디드 타입은 엔티티의 값일 뿐이다.
- 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능하다.
- 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.
- 용어/코드를 공통으로 관리할 수 있게 된다.

임베디드 타입과 연관관계

임베디드 타입은 임베디드 타입을 가질 수 있다.
- e.g. Address «Value» 임베디드 타입은 Zipcode «Value» 라는 임베디드 타입을 가진다.
임베디드 타입은 엔티티 타입을 가질 수 있다.
- e.g. PhoneNumber «Value» 임베디드 타입이 PhoneEntity «Entity» 를 가질 수 있다.
- FK만 가지면 되기 때문이다.

Q. 한 Entity 안에서 같은 값 타입을 2개 이상 가지면 어떻게 될까?

  @Entity
  public class Member {
  ...
  @Embedded
  private Address homeAddress; // 주소 
  @Embedded
  private Address workAddress; // 주소 
  ...
  }

컬럼 명이 중복된다.
- MappingException: Repeated column Error

A. @AttributeOverrides, @AttributeOverride를 통해 속성을 재정의한다.

@Entity
public class Member {
  ...
  @Embedded
  private Address homeAddress;
  @Embedded
  @AttributeOverrides({ // 새로운 컬럼에 저장 (컬럼명 속성 재정의)
    @AttributeOverride(name="city", column=@Column(name = "WORK_CITY"),
    @AttributeOverride(name="street", column=@Column(name = "WORK_STREET"),
    @AttributeOverride(name="zipcode", column=@Column(name = "WORK_ZIPCODE")})
  private Address workAddress;
  ...
}

값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다.
따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

값 타입 공유 참조의 부작용

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 굉장히 위험하다.
- Side Effect(부작용)이 발생한다.

예시

Member Class가 같은 Address 객체를 가지고 있고, 두 Member 객체 중 첫 번째 Member의 Address(city) 속성만 변경하려고 하는 경우

  Address address = new Address("city", "street", "10000");
  // 
  Member member = new Member();
  member.setUsername("member1");
  member.setHomeAddress(address);
  em.persist(member);
  // 
  Member member2 = new Member();
  member2.setUsername("member2");
  member2.setHomeAddress(address);
  em.persist(member2);
  // 첫 번째 member의 Address(city) 속성만 변경하고 싶다.
  member.getHomeAddress().setCity("new city");
  tx.commit(); // UPDATE Query 2번 

결과
- UPDATE Query가 두 번 날라간다.
- 즉, DB에서의 member1과 member2의 city 값이 모두 변경된다.
- Side Effect와 같은 버그는 잡기가 굉장히 어렵다.
해결책
- 엔티티 간에 공유하고 싶은 값 타입은 엔티티로 만들어서 공유해야 한다.

값 타입 복사

위의 예시처럼 값 타입의 실제 인스턴스인 값을 공유하는 것은 굉장히 위험하다.

대신 값(인스턴스)를 복사해서 사용한다.

  Address address = new Address("city", "street", "10000");
  // 
  Member member = new Member();
  member.setUsername("member1");
  member.setHomeAddress(address);
  em.persist(member);
  // Address 객체 복사
  Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());
  // 
  Member member2 = new Member();
  member2.setUsername("member2");
  member2.setHomeAddress(copyAddress); // 복사한 것을 넣는다.
  em.persist(member2);
  // 첫 번째 member의 Address(city) 속성만 변경된다.!
  member.getHomeAddress().setCity("new city");

객체 타입의 한계

위의 예시처럼 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
그러나, 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입(primitive)이 아니라 객체 타입이다.
- 자바의 기본 타입에 값을 대입하면 자바는 기본적으로 값을 복사한다.
```
  int a = 10;
  int b = a; // 기본 타입은 값을 복사
  b = 4; 
```
- 객체 타입은 참조 값을 직접 대입하는 것을 막을 수 있는 방법이 없다.
```
  Address a = new Address("old");
  Address b = a; // 객체 타입은 참조를 전달 (같은 인스턴스를 가리킴)
  b.setCity("new"); // a, b 모두 city가 변경된다.
```
  - 객체 타입은 타입이 같으면 그냥 대입(=)해서 넣을 수 있다.
  - e.g. 누군가 실수로 복사하지 않은 address를 그대로 넣었다면 컴파일 단계에서 알 수 있는 방법이 없다. (member2.setHomeAddress(address))
따라서, 객체의 공유 참조는 피할 수 없다.
해결책
- 불변 객체 (Immutable Object)

불변 객체 (Immutable Object)

값 타입은 불변 객체(immutable object)로 설계해야 한다.
- 객체 타입을 수정할 수 없게 만들면 부작용(Side Effect)을 원천 차단할 수 있다.
- 불변이라는 작은 제약으로 부작용이라는 큰 재앙을 막을 수 있다
불변 객체란
- 생성 시점 이후 절대 값을 변경할 수 없는 객체
- 생성자로만 값을 설정하고 Setter를 만들지 않으면 된다.
- c.f. Integer, String은 자바가 제공하는 대표적인 불변 객체이다.
Q. 원래 값 객체의 필드를 실제로 바꾸고 싶으면?

A. Address 를 통으로 변경해야 한다.

  Address address = new Address("city", "street", "10000");
    
  Member member = new Member();
  member.setUsername("member1");
  member.setHomeAddress(address);
  em.persist(member);
    
  Address newAddress = new Address("NewCity", address.getStreet(), address.getZipcode());
  member.setHomeAddress(newAddress); // 통으로 변경 
    
  tx.commit();

값 타입의 비교

깂 타입은 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 한다.
```
int a = 10;
int b = 10;
System.out.println("a == b: " + (a == b)); // true
```

객체 타입은 값이 같아도 주소가 다르기 때문에 == 비교 시 false를 반환한다.

Address address1 = new Address("서울시");
Address address2 = new Address("서울시");
System.out.println("address1 == address2: " + (address1 == address2)); // false

동일성(identity) 비교
- 인스턴스의 참조 값을 비교한다.
- == 사용
- primitive 타입
동등성(equivalence) 비교
- 인스턴스의 값을 비교한다.
- equals() 사용
- 임베디드 타입
- System.out.println("address1 == address2: " + (address1.equals(address2))); // 재정의 시 true
값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 한다.
값 타입의 equals() 메소드를 적절하게 재정의해야 한다.
- 자동으로 만들어주는 equals()를 이용한다.
- (주로 모든 필드를 사용하여 재정의 한다.)
- equals()에 맞게 hashCode()도 재정의 해줘야 한다.

컬렉션 타입 참고 POST

Reference

인프런 강의 참고

[JPA] 양방향 연관관계란

Wed, 14 Aug 2019 00:00:00 +0000

인프런 강의 참고

양방향 연관관계와 연관관계의 주인

양방향 연관관계

연관관계를 찾는 방법
- 객체는 참조, DB는 외래 키를 이용한 JOIN
- 이 둘 간의 차이를 이해해야 한다.

테이블 연관관계는 단방향 연관관계에서와 동일하다.
- Why?
  - Member에서 Team을 알고 싶으면 TEAM_ID인 FK로 JOIN을 하면 된다.
  - Team에서 Member를 알고 싶으면 마찬가지로 나의 PK로 JOIN을 하면 된다.
  - 즉, 테이블의 연관관계는 사실상 방향이 없다. (FK로 서로를 알 수 있기 때문)
객체에서의 연관관계를 위해서는 Team에서도 List members 가 필요하다.
- 즉, 객체 설계에서 양방향을 구현하고 싶으면 Member에서는 Team을 가지고 있고, Team에서는 List Members를 가지고 있도록 설계하면 된다.
- 이렇게 하면 Team에서도 getMemberList()로 특정 팀에 속한 멤버 리스트를 가져올 수 있다.

예제

@Entity
public class Member {
  @Id
  @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;
  
  @Column(name = "USERNAME")
  private String username;
  
  private int age;

  @ManyToOne // N:1
  @JoinColumn(name = "TEAM_ID")
  private Team team;
  ...
}

@Entity
public class Team {
  @Id
  @GeneratedValue
  @Column(name = "TEAM_ID")
  private Long id;
  
  private String name;
  
  @OneToMany(mappedBy = "team") // 1:N
  private List<Member> members = new ArrayList<Member>(); // 초기화 (관례) - NullPointerException 방지 
  ...
}

Member —N:1— Team
- Member 입장에서는 다대일, Team 입장에서는 일대다의 관계를 갖는다.
- Member 엔티티
  - 단방향과 동일하다.
  - @ManyToOne
- Team 엔티티
  - Member 컬렉션을 추가한다.
  - @OneToMany(mappedBy = "team")
  - mappedBy로 team과 연관이 있는 것을 알려준다.

반대 방향으로도 객체 그래프를 탐색할 수 있다.

// Member 조회
Member findMember = entityManager.find(Member.class, member.getId());
// team에서 멤버들 조회
List<Member> members = findMember.getTeam().getMembers();

연관관계 주인과 mappedBy

mappedBy
- JPA의 멘탈붕괴 난이도
- 처음에는 이해하기 어렵지만, 객체와 테이블간에 연관관계를 맺는 차이를 이해하면 쉬워진다.
객체는 방향을 가지고 있고, DB는 방향성이 없다.
- DB 테이블에서는 FK 하나로 양방향 관계(서로 JOIN)를 맺을 수 있다.

객체와 테이블간에 연관관계를 맺는 차이

객체 연관관계 = 2개

회원 -> 팀 연관관계 1개 (단방향)
팀 -> 회원 연관관계 1개 (단방향)
객체의 양방향 관계
- 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.
- 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.
  - A -> B(a.getB())
    class A { B b; }
  - B -> A(b.getA())
    class B { A a; }

테이블 연관관계 = 1개

회원 <-> 팀의 연관관계 1개 (양방향, 사실 방향이 없음)
테이블의 양방향 연관관계
- 테이블은 외래 키 하나로 두 테이블의 연관관계를 관리한다.
- MEMBER.TEAM_ID 외래 키(FK) 하나로 양방향 연관관계를 가진다. (양쪽에서 서로 JOIN 가능)
```
SELECT *
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID
```
```
SELECT *
FROM TEAM T
JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID
```

둘 중 하나로 외래 키를 관리해야 한다

객체에서의 양방향 관계
- Member도 Team을 가지고, Team도 Member를 가지면 이제 둘 중에 뭘로 연관관계를 매핑해야 할까?
- Q.
  - Member의 team 값을 업데이트 했을 때, Member의 TEAM_ID(FK)를 업데이트?
  - 아니면 Team의 members 값을 업데이트 했을 때, Member의 TEAM_ID(FK)를 업데이트?
- Q.
  - 팀에 멤버를 바꾸고 싶거나 새로운 팀으로 들어가고 싶을 때,
  - Member의 team 값을 업데이트? 아니면 Team의 members 값을 업데이트?
- A.
  - DB에서는 객체가 참조를 어떻게 하든 외래 키값(Member의 TEAM_ID)만 업데이트하면 된다.
  - 객체에서는
    - 단방향 연관관계 매핑: 참조와 외래 키만 업데이트 하면 된다.
    - 양방향 연관관계 매핑: 외래 키를 관리하는 명확한 하나의 관계가 필요하다.
  - 양방향 연관관계에서의 외래 키 관리 주인의 기준을 명확하게 하기 위해 연관관계의 주인이라는 개념이 나왔다.

연관관계의 주인(Owner)

양방향 매핑 규칙

객체의 두 관계 중 하나를 연관관계의 주인으로 지정한다.
연관관계의 주인만이 외래 키를 관리한다.
- 진짜 매핑
- 주인만이 DB에 접근하여 값을 등록, 수정, 변경할 수 있다.
- 주인이 아닌 객체가 값을 변경하더라도 DB에는 영향이 없다.
주인이 아닌쪽은 읽기(SELECT)만 가능하다.
- 가짜 매핑

누구를 주인으로 해야 할까?

외래 키가 있는 곳을 주인으로 정해라.
- DB에서는 N에 해당하는 테이블이 FK를 가지고 있다. (N쪽이 연관관계의 주인)
- 즉, @JoinColumn이 있는 쪽이 주인이다.

N:1 의 관계에서 N에 해당하는 쪽(FK를 가짐)이 연관관계의 주인이 된다.
- 여기서는 Member.team이 연관관계의 주인이다.
연관관계의 주인은 비즈니스 적으로 중요하지 않다.
- 단지 FK를 가진 N쪽이 주인이 된다.
- Ex. [자동차 —1:N— 바퀴] 에서는 바퀴가 연관관계의 주인이다.
이렇게 해야 성능 이슈도 없고 설계도 깔끔한 구조가 된다.
- 깔끔한 구조
  - 엔티티 하나에서 관리가 된다.
  - 즉, FK가 있는 엔티티에서 연관관계도 관리할 수 있다.
  - Ex. Member의 team을 바꿨더니 Member의 UPDATE Query가 날라간다.
Q. Team.members를 주인으로 선택하고 Team의 List members를 변경했다. 그 결과는?
- A. 다른 테이블인 Member의 UPDATE Query가 날라간다.

주인인 객체와 주인이 아닌 객체의 구현 방법

Member —N:1— Team
- Member 입장에서는 다대일, Team 입장에서는 일대다의 관계를 갖는다.
- Member가 Owner가 된다.
주인인 객체
- mappedBy 속성을 사용하지 않는다.
- @ManyToOne, @JoinColumn 필요
- mappedBy의 뜻?
  - 어떤 대상에 의해서 매핑이 되었다.
주인이 아닌 객체
- mappedBy 속성으로 주인을 지정한다.
- @OneToMany 필요

Reference

인프런 강의 참고

[JPA] 단방향 연관관계란

Tue, 13 Aug 2019 00:00:00 +0000

인프런 강의 참고

단방향 연관관계

Goal

객체와 테이블 연관관계의 차이를 이해한다.

객체의 참조와 테이블의 외래 키를 어떻게 매핑하는지 안다.

용어 이해

방향 (Direction)

단방향, 양방향

다중성 (Multiplicity)

다대일 (N:1), 일대다 (1:N), 일대일 (1:1), 다대다 (N:N)

연관관계의 주인 (Owner)

객체 양방향 연관관계는 관리하는 주인이 필요하다.

연관관계가 필요한 이유

‘객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다’ - 조영호(객체지향의 사실과 오해)
객체를 테이블에 맞추어 모델링 -> 객체 지향 모델링 (객체 연관관계 사용)

예제 시나리오

회원과 팀이 있다.
회원은 하나의 팀에만 소속될 수 있다.
회원과 팀은 다대일 관계다.

1. 객체를 테이블에 맞추어 모델링 (연관 관계가 없는 객체)

N:1의 연관관계를 가지는 테이블
- Member —N:1— Team
연관관계가 없는 객체
- 참조 대신 외래 키(teamId)를 그대로 사용한다.

@Entity
public class Member {
  @Id
  @GeneratedValue
  private Long id;
  
  @Column(name = "USERNAME")
  private String username;
  
  private int age;
  
  @Column(name = "TEAM_ID")
  private Long teamId;
  ...
}

@Entity
public class Team {
  @Id
  @GeneratedValue
  private Long id;
  
  private String name;
  ...
}

Q. 객체를 테이블에 맞추어 모델링 했을 때의 문제점?

저장의 경우,
```
// 팀 저장
Team team = new Team();
team.setName("TeamA");
entityManager.persist(team);	// PK값이 세팅된 상태 (영속 상태)
// 회원 저장
Member member = new Memeber();
member.setName("member1");
member.setTeamId(team.getId());	// 외래키 식별자를 직접 다룸  
entityManager.persist(member);
```
- A. 외래 키의 식별자를 직접 다뤄야 하는 문제가 있다.
  - Team 객체를 영속화한 후 Member의 teamId값(FK)에 직접 값을 세팅해줘야 한다.
  - member.setTeamId(team.getId();은 위에서 team이 영속 상태 이므로 getId()해서 가져올 수 있지만, 객체 지향적인 방법이 아니다.
  - member.setTeam(team);과 같이 사용하고 싶다는 생각이 들 것이다.

조회의 경우,

// 조회
Member findMember = entityManager.find(Member.class, member.getId());
// 연관 관계가 없음 (못가져옴)
Team findTeam = entityManger.find(Team.class, team.getId());

// 먼저 식별자를 가져와야 함 (가져옴)
Long findTeamId = findMember = findMember.getTeamId();
Team findTeam = entityManger.find(Team.class, team.getId());

A. 연관 관계가 없기 때문에 식별자를 통해 다시 팀을 조회해야 한다.
즉, 조회를 두 번 해야 한다.
객체 지향적인 방법은 아니다.

결론
- 객체를 테이블에 맞추어 데이터 중심으로 모델링하면 협력 관계를 만들 수 없다.
  - 테이블: 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.
  - 객체: 참조를 사용해서 연관된 객체를 찾는다.
  - 테이블과 객체 사이에는 이런 큰 간격이 존재한다.

단방향 연관관계 매핑 이론

2. 객체 지향 모델링 (객체 연관관계 사용)

N:1의 연관관계를 가지는 테이블
- Member —N:1— Team
객체 연관관계 사용
- 객체의 참조와 테이블의 외래 키를 매핑한다.

@Entity
public class Member {
  @Id
  @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;
  
  @Column(name = "USERNAME")
  private String username;
  
  private int age;
  
//  @Column(name = "TEAM_ID")
//  private Long teamId;
  
  @ManyToOne
  @JoinColumn(name = "TEAM_ID") // 매핑 
  private Team team;
  ...
}

외래 키 대신에 Team 객체를 넣고 TEAM_ID를 매핑한다.
조인할 컬럼을 명시한다.
- @JoinColumn으로 조인 컬럼을 명시한다.
- 안적어도 default로 들어가지만, 적어 주는 것이 좋다.
연관관계를 맺는다.
- Member —N:1— Team
- Member 입장에서는 다대일, Team 입장에서는 일대다의 관계를 갖는다.
- @ManyToOne으로 연관관계를 설정한다.
- Team 이라는 필드가 DB의 “TEAM_ID”라는 외래 키와 매핑된다.

ORM 매핑

객체의 참조와 테이블의 외래 키를 매핑하여 단방향 연관관계를 설정한다.

저장의 경우

// 팀 저장
Team team = new Team();
team.setName("TeamA");
entityManager.persist(team);
// 회원 저장
Member member = new Memeber();
member.setName("member1");
member.setTeam(team);    // 단방향 연관관계 설정, 참조 저장
entityManager.persist(member);

Member findMember = entityManager.find(Member.class,  member.getId());

Team 객체를 그대로 넣는다.

조회의 경우

// 조회
Member findMember = em.find(Member.class, member.getId());
// 참조를 사용해서 연관관계 조회
Team findTeam = findMember.getTeam();

select
  member.MEMBER_ID
  member.TEAM_ID
  member.USERNAME
  team.TEAM_ID
  team.name
from
  Member member
left outer join
  Team team on member.TEAM_ID=team.TEAM_ID
where
  member.MEMBER_ID=?

Member의 getTeam()을 통해 연관된 Team을 바로 조회할 수 있다.
- 참조로 연관관계를 조회할 수 있다.
위의 SELECT Query문을 보면
- JPA가 조인을 통해 Member와 Team을 한 번에 가지고 오는 것을 확인할 수 있다.
- 하지만, 처음부터 조인해서 가져오지 않고 일단 멤버만 가져오고 싶다라고 하면

FetchType 옵션

@ManyToOne(fetch = FetchType.LAZY)
- 지연 로딩 전략
- 실제 연관관계를 가진 팀이 Touch 될 때, 그 때 Team을 조회하는 쿼리를 날려서 가져온다.
@ManyToOne(fetch = FetchType.EAGER)
- 기본값
- 연관관계를 가진 객체를 조인해서 먼저 모두 가져온다.

[참고] 영속성 1차 캐시에서 가져오지 않고 DB Query를 날려서 직접 확인하고 싶으면,

entityManager(member);

// 추가
entityManager.flush(); // 현재 영속성 컨텍스트에 있는 것을 DB에 던져서 sync를 맞춘다.
entityManager.clear(); // 영속성 컨텍스트를 초기화시킨다.

Member findMember = entityManager.find(Member.class, member.getId()); // find 시 날라가는 쿼리를 확인한다.

flush()와 clear()가 없으면 아래의 find()에서는 SELECT Query는 날라가지 않는다.
영속성 컨텍스트의 1차 캐시에 쿼당 객체를 저장하기 때문에 쿼리를 날리지 않고 1차 캐시에서 객체 정보를 가져오기 때문이다.

연관관계 수정

// 새로운 팀B
Team teamB = new Team();
teamB.setName("TeamB");
entityManager.persist(teamB);

// 회원1에 새로운 팀B 설정
member.setTeam(teamB);

setTeam()을 통해 기존의 팀을 새로운 팀으로 변경하면, 연관관계가 바뀐다.
UPDATE Query를 통해서 FK 가 업데이트된다.

Reference

인프런 강의 참고

[JPA] 기본키(PK) 매핑 방법 및 생성 전략

Mon, 12 Aug 2019 00:00:00 +0000

인프런 강의 참고

Goal

기본 키 매핑 방법

기본 키 자동 생성 전략 4가지

IDENTITY

SEQUENCE

TABLE

AUTO

기본 키 생성 전략

기본 키 매핑

@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

직접 할당
- @Id 만 사용
자동 생성
- @Id와 @GeneratedValue를 같이 사용
- 네 가지 전략이 있다.

자동 생성 전략 (네 가지)

IDENTITY

개념

@GeneratedValue(strategy = GenerationType.IDENTITY)
기본 키 생성을 데이터베이스에 위임
즉, id 값을 null로 하면 DB가 알아서 AUTO_INCREMENT 해준다.
- Ex) MySQL, PostgreSQL, SQL Server DB2 등

public class Member {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id; 
}

// H2
create table Member (
  id varchar(255) generated by default as identity,
  ...
)
// MySQL
create table Member (
  id varchar(255) auto_increment,
  ...
)

특징

IDENTITY 전략은 entityManager.persist() 시점에 즉시 INSERT SQL을 실행하고 DB에서 식별자를 조회한다.
- JPA는 보통 트랜잭션 commit 시점에 INSERT SQL을 실행한다.
- [추가 설명]
  - IDENTITY 전략은 id 값을 설정하지 않고(null) INSERT Query를 날리면 그때 id의 값을 세팅한다.
    - AUTO_INCREMENT는 DB에 INSERT SQL을 실행한 이후에 id 값을 알 수 있다.
    - 즉, id 값은 DB에 값이 들어간 이후에서야 알 수 있다는 것이다.
  - Q. id 값을 DB에 값이 들어간 이후에 알게 됐을 때의 문제점?
    - 영속성 컨텍스트에서 해당 객체가 관리되려면 무조건 pk 값이 있어야 한다.
    - 하지만 이 경우 pk 값은 DB에 들어가봐야 알 수가 있다.
    - 다시 말해서, IDENTITY 전략의 경우 영속성 컨텍스트의 1차 캐시 안에 있는 @Id 값은 DB에 넣기 전까지는 세팅을 할 수 없다는 것이다. (JPA 입장에서는 Map의 key 값이 없으니까 해당 객체의 값을 넣을 수 있는 방법이 없다.)
  - A. 해결책?
    - IDENTITY 전략에서만 예외적으로 entityManager.persist()가 호출되는 시점에 바로 DB에 INSERT 쿼리를 날린다. (다른 전략에서는 이미 id 값을 알고 있기 때문에 commit 하는 시점에 INSERT 쿼리를 날린다.)
    - 위의 과정을 통해 entityManager.persist()가 호출되자마자 INSERT SQL을 통해 DB에서 식별자를 조회하여 영속성 컨텍스트의 1차 캐시에 값을 넣는다. (SELECT 문을 다시 날리지 않아도 된다.)
단점: 모아서 INSERT 하는 것이 불가능하다.
- 하지만, 버퍼링해서 Write 하는 것이 큰 이득이 있지 않기 때문에 크게 신경쓰지 않아도 된다.
- 하나의 Transaction 안에서 여러 INSERT Query가 네트워크를 탄다고 해서 엄청나게 비약적인 차이가 나지 않는다.

SEQUENCE

개념

@GeneratedValue(strategy = GenerationType.SEQUNCE)
데이터베이스 Sequence Object를 사용
- DB Sequence는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트
- 테이블 마다 시퀀스 오브젝트를 따로 관리하고 싶으면 @SequenceGenerator에 sequenceName 속성을 추가한다.
즉, DB가 자동으로 숫자를 generate 해준다.
- Ex) Oracle, PostgreSQL, DB2, H2 등
@SequenceGenerator 필요

@Entity
@SequenceGenerator(
  name = "MEMBER_SEQ_GENERATOR", 
  sequenceName = "MEMBER_SEQ", // 매핑할 데이터베이스 시퀀스 이름 
  initialValue = 1,
  allocationSize = 1)
public class Member {
  @Id
  @GeneratedValue(strategy = GenerationType.SEQUENCE,
                  generator = "MEMBER_SEQ_GENERATOR")
  private Long id; 
}

// 1부터 시작해서 1씩 증가 
create sequence MEMBER_SEQ start with 1 increment by 1

특징

SEQUENCE 전략은 id 값을 설정하지 않고(null) generator에 매핑된 Sequence 전략(“MEMBER_SEQ”)에서 id 값을 얻어온다.
- 해당 Sequence Object는 DB가 관리하는 것이기 때문에 DB에서 id 값을 가져와야 한다.
Q1. id 값을 DB에 값이 들어간 이후에 알게 됐을 때의 문제점?
- 위의 IDENTITY 전략과 마찬가지의 상태
A1. 해결책?
- 1) entityManager.persist()를 호출하기 전에 DB의 Sequence에서 pk 값을 가져와야 한다.
  - hibernate: call next value for MEMBER_SEQ이 수행됨.
  - 현재의 값: member.id = 1
- 2) DB에서 가져온 pk 값을 해당 객체의 id 에 넣는다.
- 3) 이후에 entityManager.persist()를 통해 영속성 컨텍스트에 해당 객체가 저장되는 것이다.
  - 이 상태에서는 아직 DB에 INSERT 쿼리가 날라가지 않고, 영속성 컨텍스트에 쌓여있다가 트랜잭션 commit 하는 시점에 INSERT 쿼리가 날라간다.
- 4) 필요한 경우 버퍼링이 가능하다.
  - IDENTITY 전략에서는 INSERT 쿼리를 날려야 pk를 알 수 있었기 때문에 버퍼링이 불가능하다.
Q2. 위의 해결책이면 계속 네트워크를 왔다갔다 해야되기 때문에 성능 상의 저하가 있지 않을까?
- SEQUENCE 전략을 사용할 경우, Sequence를 매번 DB에서 가지고오는 과정에서 네트워크를 타기 때문에 성능 상의 저하를 가져올 수 있다.
- 차라리 INSERT Query를 한 번에 날리는 것이 낫지 않을까?
A2. allocationSize 속성값 (기본값: 50) 이용
- 이를 해결하기 위한 성능 최적화의 방법으로 allocationSize 옵션을 사용한다.
- 1) 이 옵션을 사용하면 next call을 할 때 미리 DB에 50개를 한 번에 올려 놓고 (DB는 sequence가 51로 세팅된다.) 메모리 상에서 1개씩 쓰는 것이다.
- 2) 50개를 모두 사용하면 그 때 또 next call을 날려서 다시 50개를 올려 놓는다. (DB는 sequence가 101로 세팅된다.) 메모리에서 sequence를 가져와 51부터 사용할 수 있다.
  - create sequence MEMBER_SEQ start with 1 increment by 50
- 예시)
```
// 1(1로 맞추기 위한 dummy 호출), 51(최적화를 위한 호출)
em.persist(member1); // next call 2번 호출 
em.persist(member2); // MEM
em.persist(member3); // MEM
```
Q3. 옵션값을 50보다 큰 수로 정하면 좋지 않나?
A3. 이론적으로는 더 큰 수로 설정할수록 성능은 좋아진다.
- 하지만, 중간에 애플리케이션(웹 서버)를 내리는 시점에 사용하지 않는 seq 값이 날라간다. 즉, 중간에 구멍이 생긴다.
- 중간의 seq 공백이 큰 문제가 되는 것은 아니지만, 그래도 낭비가 되는 것이므로 적당한 50~100 사이로 설정하는 것이 좋다.

@SequenceGenerator 속성

속성	설명	기본값
name	식별자 생성기 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 때 처음 1 시작하는 수를 지정한다.	1
allocationSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용), 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야 한다.	50
catalog, schema	데이터베이스 catalog, schema 이름

TABLE

개념

@GeneratedValue(strategy = GenerationType.TABLE)
키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
@TableGenerator 필요

@Entity
@SequenceGenerator(
  name = "MEMBER_SEQ_GENERATOR", 
  table = "MY_SEQUENCES", // 데이터베이스 이름 
  pkColumnValue = "MEMBER_SEQ",
  allocationSize = 1)
public class Member {
  @Id
  @GeneratedValue(strategy = GenerationType.TABLE,
                  generator = "MEMBER_SEQ_GENERATOR")
  private Long id; 
}

create table MY_SEQUENCES (
  sequence_name varchar(255) not null,
  next_val bigint,
  primaty key ( sequence_name )
)

특징

장점: 모든 데이터베이스에 적용 가능
단점: 최적화 되어있지 않은 테이블을 직접 사용하기 때문에 성능상의 이슈가 있음
운영 서버에서는 사용하기에 적합하지 않다.
- Why? DB에서 관례로 쓰는 것이 있기 때문에
Q. Table 전략에서 allocationSize = 50이고, 서버가 여러 대인 경우에는 문제가 없을까?
A. 문제 없다.
- 미리 값을 올려두는 방식이기 때문에 여러 대의 서버가 붙더라도 상관이 없다.
- 웹 서버 10대가 동시에 호출하는 경우, 순차적으로 사용하여 값이 올라가 있을 것이다.
  - A 서버: 1~50
  - B 서버: 51~100 …

@TableGenerator 속성

속성	설명	기본값
name	식별자 생성기 이름	필수
table	키 생성 테이블 명	hibernate_sequences
pkColumnName	시퀀스 컬럼명	sequence_name
valueColumnNa	시퀀스 값 컬럼명	next_val
pkColumnValue	키로 사용할 값 이름	엔티티 이름
initialValue	초기 값, 마지막으로 생성된 값이 기준	0
allocationSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용)	50
catalog, schema	데이터베이스 catalog, schema 이름
uniqueConstraints(DDL)	유니크 제약 조건을 지정할 수 있다.

AUTO

개념

@GeneratedValue(strategy = GenerationType.AUTO)
기본 설정 값
방언에 따라 위의 세 가지 전략을 자동으로 지정한다.

권장하는 식별자 전략

기본 키 제약 조건

null이 아니다.
유일하다.
변하면 안된다.

미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 그 대신 대리키/대체키를 사용하자.
- 자연키 (Natural Key)
  - 비즈니스적으로 의미가 있는 키
  - Ex) 전화번호, 주민등록번호 등
- 대리키/대체키 (Generate Value)
  - 비즈니스적으로 상관없는 키
  - Ex) Generate Value, 랜덤 값, 유휴 값 등
예를 들어, 주민등록번호도 기본 키로 적절하지 않다.
- Why? 갑자기 개인정보 보호의 목적으로 DB에 주민등록번호를 저장하지 말라 조건이 들어온다. 이때, 주민등록번호를 pk로 사용하고 있는 테이블뿐만 아니라 해당 테이블의 pk를 fk로 JOIN하고 있는 다른 테이블에서도 문제가 생긴다.
- 즉, 주민등록번호를 fk로 참조하고 있는 모든! 테이블을 마이그레이션 해야 한다.

권장하는 식별자 구성 전략

(Long형) + (대체키) + (적절한 키 생성 전략) 사용

Long Type (아래 참고)
대체키 사용: 랜덤 값, 유휴 ID 등 비즈니스와 관계없는 값 사용
AUTO_INCREMENT 또는 Sequnce Object 사용

[참고] Q. id 값(pk 값)은 어떤 타입을 써야 할까?
- int
  - 0이 있다.
- Integer
  - 10억 정도 까지만 가능하다.
- Long
  - 채택!
  - Long의 크기가 Integer의 2배지만 애플리케이션 전체로 봤을 때의 영향은 작다고 볼 수 있다.
  - 오히려 10억이 넘어갔을 때 해당 id 값을 타입을 변경하는 것이 더 어렵다.

Reference

인프런 강의 참고

[JPA] 엔티티 매핑 방법 (Entity Mapping)

Sun, 11 Aug 2019 00:00:00 +0000

인프런 강의 참고

[들어가기 전] JPA에서 중요한 것!

영속성 컨텍스트, JPA 내부 동작 등의 매커니즘 측면
- JPA가 내부적으로 어떤 매커니즘으로 동작하는지.
설계 측면
- 객체와 RDB를 어떻게 매핑해서 사용하는지.

엔티티 매핑

기본적인 엔티티 매핑 소개
- 객체와 테이블 매핑
  - @Entity
  - @Table
- 필드와 컬럼 매핑
  - @Column
- 기본 키 매핑
  - @Id
- 연관관계 매핑
  - Ex) Member와 Team
  - @ManyToOne
  - @JoinColumn

객체와 테이블 매핑

@Entity

@Entity가 붙은 클래스는 JPA가 관리하는 클래스로, 해당 클래스를 엔티티라고 한다.
JPA를 사용해서 테이블과 매핑할 클래스는 반드시 @Entity 를 붙여야 한다.
[주의]
- 기본 생성자 필수
  - 파라미터가 없는 public 또는 protected 생성자가 필요하다.
  - JPA spec으로 규정되어 있다.
    - Why? JPA를 구현해서 쓰는 라이브러리들이 다양한 기술(Ex. Reflection)을 사용해서 객체를 프록싱할 때 필요하기 때문.
- final 클래스, enum, interface, inner 클래스는 엔티티로 사용할 수 없다.
- DB에 저장하고 싶은 필드에는 final을 사용할 수 없다.
Entity 속성
- name
  - @Entity(name = "Member")
  - JPA에서 사용할 엔티티 이름을 지정한다.
  - 기본값: 클래스 이름을 그대로 사용
  - 같은 클래스 이름이 없으면 가급적 기본값을 사용하도록 한다.

@Table

@Table은 엔티티와 매핑할 테이블을 지정하는 것이다.
@Table 속성
- name
  - @Table(name = "MBR")
  - 매핑할 테이블 이름을 지정한다.
  - 기본값: 엔티티 이름을 사용
- catalog
  - 데이터베이스 catalog 매핑
- schema
  - 데이터베이스 schema 매핑
- uniqueConstraints(DDL)
  - DDL 생성 시에 유니크 제약 조건 생성

데이터베이스 스키마 자동 생성

DDL을 애플리케이션 실행 시점(loading)에 자동으로 생성한다.
테이블 중심 -> 객체 중심
데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL을 생성한다.
- Ex) oracle: varchar2, MySQL: varchar 등
이렇게 생성된 DDL은 개발 로컬 장비에서만 사용한다.
- 즉, 운영 서버에서는 사용하지 않거나, 적절히 다듬은 후 사용한다.
- 로컬 PC에서 개발할 때 사용한다.

<property name="hibernate.hbm2ddl.auto" value="create"/>

hibernate.hbm2ddl.auto 옵션의 속성값

옵션	설명
create	기존 테이블 삭제 후 다시 생성 (DROP + CREATE)
create-drop	create와 같으나 종료 시점에 테이블 DROP (테스트에서 사용하면 도움됨)
update	변경 분만 반영 (운영 DB에서는 사용하면 안됨) `alter table ~`
validate	엔티티와 테이블이 정상 매핑되었는지만 확인
none	아무 속성도 사용하지 않음

[주의]
- 운영 장비에는 절대 create, create-drop, update를 사용하면 안된다.
- 개발 초기 단계(로컬 개발 서버)
  - create 또는 update
- 테스트 서버(여러 명이 같이 사용하는 개발 서버)
  - update 또는 validate
  - 웬만하면 테스트 서버에서도 validate나 none을 쓰는 것이 좋다.
  - Why? 데이터가 많은 상태에서 alter를 했을 때 자칫 시스템이 중단될 수도 있기 때문이다.
  - 직접 스크립트를 짜서 적용해보고 문제가 없으면 DBA에게 검수를 받은 후 운영 서버에 적용하는 것을 권장한다.
- 스테이징과 운영 서버
  - validate 또는 none
[참고] 데이터베이스 방언이란?

DDL 생성 기능

제약 조건 추가 가능
- @Column(nullable = false, length = 10)
  - 회원 이름은 필수
  - 10글자 초과 X
- @Column(unique = true)
  - DB에 영향을 주는 것
  - 해당 필드는 unique 함을 의미
- @Table(uniqueConstraints = {@UniqueConstraint(name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"})})
  - Unique 제약 조건 추가
DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.
- 즉, DB에만 영향을 주는 것이지 애플리케이션에 영향을 주는 것이 아니다.
- JPA의 실행 매커니즘에 영향을 주는 것이 아니라 alter table과 같은 스크립트가 실행되는 것을 말한다.
- Cf) insert, update는 Runtime에 영향을 준다.

필드와 컬럼 매핑

요구 사항 추가

회원은 일반 회원과 관리자로 구분해야 한다.
회원 가입일과 수정일이 있어야 한다.
회원을 설명할 수 있는 필드가 있어야 한다. 이 필드는 길이 제한이 없다.

public enum RoleType {
  USER, ADMIN
}

@Entity
@Table(name = "MBR")
public class Member {
  @Id
  private Long id;

  @Column(name = "name")
  private String username;

  private Integer age;

  @Enumerated(EnumType.String)
  private RoleType roleType;

  @Temporal(TemporalType.TIMESTAMP)
  private Date createDate;

  @Temporal(TemporalType.TIMESTAMP)
  private Date lastModifiedDate;

  @Lob
  private String description;

  @Transient
  private int temp;

  public Member() {

  }
}

create table Member (
  id bigint not null,
  age integer,
  createdDate timestamp,
  description clob,
  lastModifiedDate timestamp,
  roleType varchar(255),
  name varchar(255),
  primary key (id)
)

@Id

pk 매핑

@Column

컬럼 매핑
@Column 속성
- name
  - @Colunm(name = "name")
  - 객체명과 DB 컬럼명을 다르게 하고 싶은 경우, DB 컬럼명으로 설정할 이름을 name 속성으로 적는다.
- insertable
- updatable
  - 컬럼을 수정했을 때 DB에 추가를 할 것인지 여부
  - update 문이 나갈 때 해당 컬럼을 반영할 것인지 여부
  - @Column(updatable = false): 변경이 되어도 DB에 반영되지 않는다.
- nullable
  - @Column(nullable = false): NOT NULL 제약조건이 된다.
- unique
  - 잘 사용하지 않는다.
    - Why? constraint UK_ewkrjwel239flskdfj01 unique (name) 과 같이 이름을 랜덤으로 만든다.
  - 이름에 대한 설정을 직접하려면 아래의 방법을 사용해야 한다.
    - @Table(uniqueConstraints = {@UniqueConstraint(name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"})})
- columnDefinition
  - @Column(columnDefinition = "varchar(100) default 'EMPTY'"): 직접 컬럼 정보를 작성할 수 있다.
- length
  - 문자 길이 제약 조건
  - String 타입에만 사용한다.
- precision
  - 숫자가 엄청 큰 BigDecimal 의 경우 (Ex.private BigDecimal age;)

@Enumerated

Enum Type 매핑
- Enum 객체 사용 시 해당 annotation을 사용
- DB에는 Enum Type이 없다.
EnumType.ORDINAL
- enum 순서를 데이터베이스에 저장 (기본값)
EnumType.String
- enum 이름을 데이터베이스에 저장
[주의]
- EnumType.ORDINAL 은 사용하지 않는다.
- Why? 요구 사항에 따라 새로운 Type이 추가될 수 있기 때문에 순서가 변경될 수 있다.
  - 즉, GUEST를 enum class 맨 앞에 추가 했을 때 GUEST와 USER 모두가 ‘0’으로 저장된다.
- 즉, 필수처럼 EnumType.String 을 사용한다.

@Target({ElementType.METHOD, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Enumerated {
    EnumType value() default EnumType.ORDINAL;
}

public enum EnumType {
    ORDINAL, STRING;
    private EnumType() { }
}

@Temporal

날짜 Type (java.util.Date, java.util.Calendar) 매핑
- 날짜 타입 사용 시 해당 annotation을 사용
java의 Date에는 날짜와 시간이 모두 존재한다. 그러나 DB의 Date에는 아래의 세 가지로 구분해서 사용한다
TemporalType enum class에는 세 가지가 존재한다.
- DATE: 날짜, DB의 date 타입과 매핑
  - Ex. 2019-08-13
- TIME: 시간, DB의 time 타입과 매핑
  - Ex. 14:20:38
- TIMESTAMP: 날짜와 시간, DB의 timestamp 타입과 매핑
  - Ex. 2019-08-13 14:20:38
지금은 필요 없음
- java 8의 LocalDate(date), LocalDateTime(timestamp) 을 사용할 때는 생략이 가능하다.
- hibernate에서 지원
- Ex. private LocalDate createDate 또는 private LocalDateTime createDateTime

@Lob

DB에서 varchar를 넘어서는 큰 내용을 넣고 싶은 경우에 해당 annotation을 사용
@Lob에는 지정할 수 있는 속성이 없다.
매핑하는 필드의 타입에 따라 DB의 BLOB, CLOB과 매핑된다.
- 필드의 타입이 문자열: CLOB
  - String, char[], java.sql.CLOB
- 그 외 나머지: BLOB
  - byte[], java.sql.BLOB

@Transient

특정 필드를 컬럼에 매핑하지 않음.
DB에 관계없이 메모리에서만 사용하고자 하는 객체에 해당 annotation을 사용
- 즉, 주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용한다.
해당 annotation이 붙은 필드는 DB에 저장, 조회가 되지 않는다.

Reference

인프런 강의 참고

[JPA] 엔티티의 생명주기 (Entity LifeCycle)

Thu, 08 Aug 2019 00:00:00 +0000

인프런 강의 참고

엔티티의 생명주기 (Entity LifeCycle)

비영속(new/transient)

영속성 컨텍스트와 전혀 관계가 없는 상태
객체를 생성’만’ 한 상태

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

영속(managed) (아래 추가 설명)
- 영속성 컨텍스트에 저장된 상태
- Entity가 영속성 컨텍스트에 의해 관리되는 상태
- EntityManager.persist(entity);
  - 영속 상태가 된다고 바로 DB에 쿼리가 날라가지 않는다. (즉, DB 저장 X)
- transaction.commit();
  - 트랜잭션의 commit 시점에 영속성 컨텍스트에 있는 정보들이 DB에 쿼리로 날라간다.
- ```
// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
EntityManager entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
// 객체를 저장한 상태 (영속)
entityManager.persist(member);
```
준영속(detached) (아래 추가 설명)
- 영속성 컨텍스트에 저장되었다가 분리된 상태
- 영속성 컨텍스트에서 지운 상태
```
// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
entityManager.detach(member);
```

삭제(removed)

실제 DB 삭제를 요청한 상태

// 객체를 삭제한 상태
entityManager.remove(member);

영속 상태와 준영속 상태

영속 상태란
- 1) entityManager.persist(); 로 영속성 컨텍스트에 저장된 상태
- 2) entityManager.find(); 로 조회할 때 영속성 컨텍스트 1차 캐시에 없어서 DB에서 조회한 후 해당 Entity를 1차 캐시에 올라간 상태 (엔티티 매니저가 관리하는 상태)
준영속 상태
- 영속 상태의 엔티티가 영속성 컨텍스트에서 분리(detached)된 상태
- 준영속 상태에서는 영속성 컨텍스트가 제공하는 기능을 사용하지 못한다.
  - Dirty Checking, Update Query

기본 예시

Member member = entityManager.find(Member.class, 150L); // 영속 상태
member.setName("AAAAA");
transaction.commit();

entityManager.find(): 1차 캐시에 없으므로 DB에서 조회한 Entity를 1차 캐시에 넣는다. (영속 상태)
변경 감지(Dirty Checking)
- 이름 변경에 대한 Entity 데이터 변화를 감지한다.
- 1차 캐시의 Entity와 Snapshot이 다른 것을 감지하고 UPDATE Query를 날린다.

준영속 상태로 만드는 방법 (영속 -> 준영속)

entityManager.detach(entity): 특정 엔티티만 준영속 상태로 전환
entityManager.clear(): 영속성 컨텍스트를 완전히 초기화
entityManager.close(): 영속성 컨텍스트를 종료

detach

// 영속 상태 (Persistence Context 에 의해 Entity 가 관리되는 상태)
Member findMember = entityManager.find(Member.class, 150L);
findMember.setName("AAAAA");

entityManager.detach(findMember); // 영속성 컨텍스트에서 떼넨다. (더 이상 JPA 의 관리 대상이 아님.)

tx.commit(); // DB에 insert query 가 날라가는 시점 (아무 일도 발생하지 않음.)

entityManager.detach();: 해당 Entity를 영속성 컨텍스트에서 분리한다.
- JPA가 관리하지 않는 객체가 된다.
Transaction commit에서 아무 일도 발생하지 않는다.
즉, Entity가 변경이 되었는데 실제로 UPDATE Query가 나가지 않는다.
직접 쓸 일이 거의 없다.

clear

// 영속 상태 (Persistence Context 에 의해 Entity 가 관리되는 상태)
Member findMember = entityManager.find(Member.class, 150L);
findMember.setName("AAAAA");

entityManager.clear(); // 영속성 컨텍스트를 완전히 초기화

Member findMember2 = entityManager.find(Member.class, 150L); // 간은 Entity 를 다시 조회

tx.commit(); // DB에 insert query 가 날라가는 시점 (아무일도 발생하지 않음.)

entityManager.clear();: EntityManager 안에 있는 영속성 컨텍스트를 모두 지운다.
- 영속성 컨텍스트를 완전히 초기화
clear 후 같은 Entity를 다시 조회할 때는 SELECT Query가 다시 나간다.
- 총 2번의 SELECT 쿼리가 발생한다.
- clear는 1차 캐시에 상관없이 쿼리를 확인하고 싶을 때 즉, testcase 작성 시에 도움이 된다.

close

영속성 컨텍스트를 종료시킨다.
JPA 의 관리 대상이 아니게 된다.

Reference

인프런 강의 참고

[JPA] 플러시(Flush)란

Wed, 07 Aug 2019 00:00:00 +0000

인프런 강의 참고

플러시 (Flush)

영속성 컨텍스트의 변경 내용을 DB 에 반영하는 것을 말한다.
Transaction commit 이 일어날 때 flush가 동작하는데, 이때 쓰기 지연 저장소에 쌓아 놨던 INSERT, UPDATE, DELETE SQL들이 DB에 날라간다.
- 주의! 영속성 컨텍스트를 비우는 것이 아니다.
쉽게 얘기해서 영속성 컨텍스트의 변경 사항들과 DB의 상태를 맞추는 작업이다.
- 플러시는 영속성 컨텍스트의 변경 내용을 DB에 동기화한다.

플러시의 동작 과정

변경을 감지한다. (Dirty Checking)
수정된 Entity를 쓰기 지연 SQL 저장소에 등록한다.
쓰기 지연 SQL 저장소의 Query를 DB에 전송한다. (등록, 수정, 삭제 Query)

flish가 발생한다고 해서 commit이 이루어지는 것이 아니고 flush 다음에 실제 commit이 일어난다.
플러시가 동작할 수 있는 이유는 데이터베이스 트랜잭션(작업 단위)이라는 개념이 있기 때문이다.
- 트랜잭션이 시작되고 해당 트랜잭션이 commit 되는 시점 직전에만 동기화 (변경 내용을 날림) 해주면 되기 때문에, 그 사이에서 플러시 매커니즘의 동작이 가능한 것이다.
[참고] JPA는 기본적으로 데이터를 맞추거나 동시성에 관련된 것들은 데이터베이스 트랜잭션에 위임한다.

영속성 컨텍스트를 플러시하는 방법

1. em.flush() 을 통한 직접 호출

// 영속 상태 (Persistence Context 에 의해 Entity 가 관리되는 상태)
Member member = new Member(200L, "A");
entityManager.persist(member);

entityManager.flush(); // 강제 호출 (쿼리가 DB 에 반영됨)

System.out.println("DB INSERT Query 가 즉시 나감. -- flush() 호출 후 --  Transaction commit 됨.");
tx.commit(); // DB에 insert query 가 날라가는 시점 (Transaction commit)

Q. 플러시가 일어나면 1차 캐시가 모두 지워질까?
- NO! 그대로 남아있다.
- 쓰기 지연 SQL 저장소에 있는 Query들만 DB에 전송까지만 되는 과정일뿐이다.

2. 트랜잭션 커밋 시 플러시 자동 호출

3. JPQL 쿼리 실행 시 플러시 자동 호출

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

// 중간에 JPQL 실행
query = entityManager.createQuery("select m from Member m", Member.class);
List<Member> members = query.getResultList();

Q. memberA, B, C 를 영속성 컨텍스트에 저장한 상태에서 바로 조회하면 조회가 될까?
- 조회가 되지 않는다.
- DB 에 Query로도 날라가야 반영이 될텐데 INSERT Query 자체가 날라가지 않은 상태이다. 이런 상태에서 JPQL로 DB에서 가져오는 SELECT Query 요청을 한 것이므로 당연히 조회되지 않는다.
- JPQL은 SQL로 번역이 돼서 실행되는 것이다.
이 때문에 JPA의 기본 모드는 JPQL 쿼리 실행 시 flush()를 자동으로 날린다.
- 즉, JPQL 쿼리 실행 시 플러시 자동 호출로 인해 위의 코드는 조회가 가능하다.

플러시 모드 옵션

em.setFlushMode(FlushModeType.COMMIT);
FlushModeType.AUTO
기본 설정 값
Transaction 을 commit 하거나 Query를 실행할 때 flush()를 먼저 수행한다.
FlushModeType.COMMIT
Transaction commit 할때만 flush()를 먼저 수행한다.
Query를 실행할 때는 flush()를 먼저 수행하지 않는다.
이점: persist 한 것과 전혀 다른 테이블을 조회하는 경우

Reference

인프런 강의 참고

[JPA] 영속성 컨텍스트(Persistence Context)란

Tue, 06 Aug 2019 00:00:00 +0000

인프런 강의 참고

영속성 관리

JPA 에서 가장 중요한 2가지
- 객체와 관계형 DB 매핑하기 (Object Relational Mapping) - 설계 관련
- 영속성 컨텍스트 - JPA 내부 동작

EntityManagerFactory와 EntityManager

EntityManagerFactory는 고객의 요청이 올 때마다 (thread가 하나 생성될 때마다) EntityManager를 생성한다.
EntityManager는 내부적으로 DB connection pool을 사용해서 DB에 접근한다.
EntityManagerFactory
- JPA 는 EntityManagerFactory 를 만들어야 한다.
- application loading 시점에 DB 당 딱 하나만 생성되어야 한다. EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("hello");
- entityManagerFactory.close();
  - WAS 가 종료되는 시점에 EntityManagerFactory 를 닫는다.
  - 그래야 내부적으로 Connection pooling 에 대한 Resource 가 Release 된다.
EntityManager
- 실제 Transaction 단위를 수행할 때마다 생성한다.
- 즉, 고객의 요청이 올 때마다 사용했다가 닫는다.
- thread 간에 공유하면 안된다. (사용하고 버려야 한다.)
- entityManager.close();
  - Transaction 수행 후에는 반드시 EntityManager 를 닫는다.
  - 그래야 내부적으로 DB Connection 을 반환한다.
EntityTransaction
- Data 를 “변경”하는 모든 작업은 반드시 Transaction 안에서 이루어져야 한다.
  - 단순한 조회의 경우는 상관없음.
- EntityTransaction tx = entityManager.getTransaction();
- tx.begin(); : Transaction 시작
- tx.commit(); : Transaction 수행
- tx.rollback(); : 작업에 문제가 생겼을 시

영속성 컨텍스트(Persistence Context)란

JPA를 이해하는데 가장 중요한 용어이다.
- 논리적인 개념으로, 눈에 보이지 않는다.
- “Entity를 영구 저장하는 환경”이라는 뜻
EntityManager.persist(entity); 의 동작 설명
- 실제로는 DB에 저장하는 것이 아니라 영속성 컨텍스트를 통해서 Entity를 영속화한다는 뜻이다.
- 정확히 말하면 persist() 시점에는 Entity를 영속성 컨텍스트에 저장하는 것이다.
EntityManager를 통해서 영속성 컨텍스트에 접근한다.
- EntityManager가 생성되면 1:1로 영속성 컨텍스트가 생성된다.

엔티티의 생명주기 (Entity LifeCycle)

비영속(new/transient)

영속성 컨텍스트와 전혀 관계가 없는 상태

객체를 생성’만’ 한 상태

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

영속(managed)
- 영속성 컨텍스트에 저장된 상태
- Entity가 영속성 컨텍스트에 의해 관리되는 상태
```
// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
EntityManager entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
// 객체를 저장한 상태 (영속)
entityManager.persist(member);
```
- EntityManager.persist(entity);
  - 영속 상태가 된다고 바로 DB에 쿼리가 날라가지 않는다. (즉, DB 저장 X)
- transaction.commit();
  - 트랜잭션의 commit 시점에 영속성 컨텍스트에 있는 정보들이 DB에 쿼리로 날라간다.
준영속(detached)
- 영속성 컨텍스트에 저장되었다가 분리된 상태
- 영속성 컨텍스트에서 지운 상태
```
// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
entityManager.detach(member);
```

삭제(removed)

실제 DB 삭제를 요청한 상태

// 객체를 삭제한 상태
entityManager.remove(member);

영속성 컨텍스트의 이점

Applicaion 과 DB 사이의 중간 계층의 영속성 컨텍스트가 존재하는 이유
- 버퍼링, 캐싱 등의 이점

1. 1차 캐시

영속성 컨텍스트 내부에는 1차 캐시가 존재한다.
- 1차 캐시를 영속성 컨텍스트라고 이해해도 된다.
Map<Key, Value> 로 1차 캐시에 저장된다.
- key : @Id로 선언한 필드 값 (DB pk)
- value : 해당 Entity 자체

Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
/* 영속 상태 (Persistence Context 에 의해 Entity 가 관리되는 상태) */
// DB 저장 X, 1차 캐시에 저장됨
entityManager.persist(member); 
// 1차 캐시에서 조회
Member findMember = entityManager.find(Member.class, "Member1"); 

1차 캐시에 Entity 가 있을 때의 이점
- 조회
- entityManager.find() 를 하면 DB보다 먼저, 1차 캐시를 조회한다.
- 1차 캐시에 해당 Entity가 존재하면 바로 반환한다.
Q. 1차 캐시에 조회하고자하는 Entity가 없다면?
- 1) DB에서 조회 한다.
- 2) 해당 Entity를 DB에서 꺼내와 1차 캐시에 저장한다.
- 3) Entity를 반환한다.
- 이후에 다시 해당 Entity를 조회하면 1차 캐시에 있는 Entity를 반환한다.
그러나, 사실 1차 캐시는 큰 성능 이점을 가지고 있지 않다.
- EntityManager는 Transaction 단위로 만들고 해당 DB Transaction이 끝날 때 (사용자의 요청에 대한 비지니스가 끝날 때) 같이 종료된다.
- 즉, 1차 캐시도 모두 날라가기 때문에 굉장히 짧은 찰나의 순간에만 이득이 있다. (DB의 한 Transaction 안에서만 효과가 있다.)
- 하지만, 비지니스 로직이 굉장히 복잡한 경우에는 효과가 있다.
[참고] 2차 캐시
- 여러 명이 사용하는 캐시
- Applicaion 전체에서 공유하는 캐시

2. 동일성 보장 (Identity)

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

영속 Entity의 동일성(== 비교)을 보장한다.
- 즉, “==” 비교가 true 임을 보장한다.
- member1에 해당하는 Entity를 2번 조회하면 1차 캐시에 의해 같은 Reference 로 인식된다.
- 하나의 Transaction 안에서 같은 Entity 비교 시 true
1차 캐시로 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 DB가 아닌 아닌 애플리케이션 차원에서 제공한다.

3. 엔티티 “등록” 시 트랜잭션을 지원하는 쓰기 지연 (Transactional Write-Behind)

EntityManager entityManager = emf.createEntityManager();
EntityTransaction transaction = entityManager.getTransaction();
// EntityManager는 데이터 변경 시 트랜잭션을 시작해야 한다.
transaction.begin(); // Transaction 시작

entityManager.persist(memberA);
entityManager.persist(memberB);
// 이때까지 INSERT SQL을 DB에 보내지 않는다.

// 커밋하는 순간 DB에 INSERT SQL을 보낸다.
transaction.commit(); // Transaction 커밋 

entityManager.persist()
- JPA가 insert SQL을 계속 쌓고 있는 상태
transaction.commit()
- 커밋하는 시점에 insert SQL을 동시에 DB에 보낸다.
- 동시에 쿼리들을 쫙 보낸다.(쿼리를 보내는 방식은 동시 or 하나씩 옵션에 따라)

entityManager.persist(memberA)
- 1) memberA가 1차 캐시에 저장한다.
- 2) 1)과 동시에 JPA가 Entity를 분석하여 insert Query를 만든다.
- 3) insert Query를 쓰기 지연 SQL 저장소 라는 곳에 쌓는다.
- 4) DB에 바로 넣지 않고 기다린다.
- 5) memberB도 동일.
transaction.commit()
- 6) 쓰기 지연 SQL 저장소에 쌓여있는 Query들을 DB로 날린다. (flush())
  - flush() 는 1차캐시를 지우지는 않는다. 쿼리들을 DB에 날려서 DB와 싱크를 맞추는 역할을 한다.
- 7) flush() 후에 실제 DB Transaction이 커밋된다. (commit())
버퍼링 기능 이라고 할 수 있다.
- DB에 쿼리를 날리는 것에 대한 옵션 설정을 통한 최적화 가능
  - jpa의 이런 기능을 잘 활용하면 성능 개선을 쉽게 할 수 있다.
- jdbc 일괄 처리 옵션 (jdbc batch option)
  - persistence.xml에 아래와 같은 옵션을 줄 수 있다.
  - commit 직전까지 insert query를 해당 사이즈 만큼 모아서 한번에 처리한다.
- <property name="hibernate.jdbc.batch_size" value=10/>

4. 엔티티 “수정” 시 변경 감지 (Dirty Checking)

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
transaction.begin(); // Transaction 시작

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

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

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

transaction.commit(); // Transaction 커밋

Entity 데이터 수정 시 update()나 persist()로 영속성 컨텍스트에 해당 데이터를 업데이트 해달라고 알려줘야 하지 않을까?
- NO!
Entity 데이터만 수정하고 commit 하면 알아서 DB에 반영된다.
즉, 데이터를 set하면 해당 데이터의 변경을 감지하여 자동으로 UPDATE Query가 나가는 것이다.

변경 감지 (Dirty Checking)

1차 캐시
- @Id, Entity, Snapshot (값을 읽어온 최초의 상태)
- Snapshot: 영속성 컨텍스트에 최초로 값이 들어왔을 때의 상태값을 저장한다.
변경 감지 매커니즘
- transaction.commit() 을 하면
- 1) flush()가 일어날 때 엔티티와 스냅샷을 일일이 비교한다.
- 2) 변경사항이 있으면 UPDATE Query를 만든다.
- 3) 해당 UPDATE Query를 쓰기 지연 SQL 저장소에 넣는다.
- 4) UPDATE Query를 DB에 반영한 후 commit()한다.
[참고] @DynamicUpdate
- Dirty Checking으로 생성되는 update 쿼리는 기본적으로 모든 필드를 업데이트한다.
- @DynamicUpdate를 통해 엔티티 수정 시 변경된 필드만 반영되도록 할 수 있다.
- https://jojoldu.tistory.com/415

5. 엔티티 삭제

Member memberA = em.find(Member.class, "memberA");

em.remove(memberA); // 엔티티 삭제

위의 Entity 수정에서의 매커니즘과 동일
Transaction의 commit 시점에 DELETE Query가 나간다.

Reference

인프런 강의 참고

[JPA] JPA란

Sun, 04 Aug 2019 00:00:00 +0000

인프런 강의 참고

Goal

ORM이란

JPA란

JPA의 동작 과정

JPA를 사용해야 되는 이유

ORM(Object-relational mapping) 이란

Object-relational mapping (객체 관계 매핑)
- 객체는 객체대로 설계하고, 관계형 데이터베이스는 관계형 데이터베이스대로 설계한다.
- ORM 프레임워크가 중간에서 매핑해준다.
대중적인 언어에는 대부분 ORM 기술이 존재한다.
ORM은 객체와 RDB 두 기둥 위에 있는 기술 이다.

JPA(Java Persistence API) 란

EJB
- 과거의 자바 표준 (Entity Bean)
- 과거의 ORM
- 문제?
  - 코드가 매우 지저분하다.
  - API의 복잡성이 높다. (interface를 많이 구현해야 함)
  - 속도가 느리다.
Hibernate
- ORM 프레임워크, Open Source SW
- ‘Gavin King’ 과 시러스 테크놀로지스 출신 동료들이 EJB2 스타일의 Entity Beans 이용을 대체할 목적으로 개발하였다.
JPA (Java Persistence API)
- 현재 자바 진영의 ORM 기술 표준으로, 인터페이스의 모음이다.
  - 즉, 실제로 동작하는 것이 아니다.
  - JPA 인터페이스를 구현한 대표적인 오픈소스가 Hibernate라고 할 수 있다.
- JPA 2.1 표준 명세를 구현한 3가지 구현체: Hibernate, EclipseLink, DataNucleus
- 버전
  - JPA 1.0(JSR 220) 2006년 : 초기 버전. 복합 키와 연관관계 기능이 부족
  - JPA 2.0(JSR 317) 2009년 : 대부분의 ORM 기능을 포함, JPA Criteria 추가
  - JPA 2.1(JSR 338) 2013년 : 스토어드 프로시저 접근, 컨버터(Converter), 엔티티 그래프 기능이 추가
Cf) Spring Framework
- Application 프레임워크, Open Source SW
- ‘Rod Johnson’ 이 EJB의 여러 문제를 해결하고, 엔터프라이즈 애플리케이션 개발을 좀 더 쉽게 하기 위한 목적으로 만들었다.

JPA의 동작 과정

JPA는 애플리케이션과 JDBC 사이에서 동작한다.
- 개발자가 JPA를 사용하면, JPA 내부에서 JDBC API를 사용하여 SQL을 호출하여 DB와 통신한다.
- 즉, 개발자가 직접 JDBC API를 쓰는 것이 아니다.

저장 과정

Ex) MemberDAO에서 객체를 저장하고 싶을 때
- 개발자는 JPA에 Member 객체를 넘긴다.
- JPA는
  - 1) Member 엔티티를 분석한다.
  - 2) INSERT SQL을 생성한다.
  - 3) JDBC API를 사용하여 SQL을 DB에 날린다.

조회 과정

Ex) Member 객체를 조회하고 싶을 때
- 개발자는 member의 pk 값을 JPA에 넘긴다.
- JPA는
  - 1) 엔티티의 매핑 정보를 바탕으로 적절한 SELECT SQL을 생성한다.
  - 2) JDBC API를 사용하여 SQL을 DB에 날린다.
  - 3) DB로부터 결과를 받아온다.
  - 4) 결과(ResultSet)를 객체에 모두 매핑한다.
쿼리를 JPA가 만들어 주기 때문에 Object와 RDB 간의 패러다임 불일치를 해결할 수 있다.

JPA를 왜 사용해야 하는가?

1. SQL 중심적인 개발에서 객체 중심으로 개발

SQL 중심적인 개발의 문제점 참고

2. 생산성

JPA를 사용하는 것은 마치 Java Collection에 데이터를 넣었다 빼는 것처럼 사용할 수 있게 만든 것이다.
간단한 CRUD
- 저장: jpa.persist(member)
- 조회: Member member = jpa.find(memberId)
- 수정: member.setName("변경할 이름")
- 삭제: jpa.remove(member)
특히, 수정이 굉장히 간단하다.
- 객체를 변경하면 그냥 알아서 DB에 UPDATE Query가 나간다.

3. 유지보수

기존: 필드 변경 시 모든 SQL을 수정해야 한다.
JPA: 필드만 추가하면 된다. SQL은 JPA가 처리하기 때문에 손댈 것이 없다.

4. Object와 RDB 간의 패러다임 불일치 해결

1) JPA와 상속

저장
- 개발자가 할 일
  - jpa.persist(album);
- 나머진 JPA가 처리
  - INSERT INTO ITEM ...
  - INSERT INTO ALBUM ...
조회
- 개발자가 할 일
  - Album album = jpa.find(Album.class, albumId);
- 나머진 JPA가 처리
  - SELECT I.*, A.* FROM ITEM I JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID

2) JPA와 연관관계

객체의 참조로 연관관계 저장 가능
- member.setTeam(team);
- jpa.persist(member);

3) JPA와 객체 그래프 탐색

신뢰할 수 있는 엔티티, 계층

class MemberService { 
      ...
      public void process() { 
          /* 직접 구현한 DAO에서 객체를 가져온 경우 */
          Member member1 = memberDAO.find(memberId); 
          member1.getTeam(); // 엔티티를 신뢰할 수 없음 
          member1.getOrder().getDelivery(); 
          /* JPA를 통해서 객체를 가져온 경우 */
          Member member2 = jpa.find(Member.class, memberId); 
          member2.getTeam(); // 자유로운 객체 그래프 탐색
          member2.getOrder().getDelivery(); 
      } 
}

내가 아닌 다른 개발자가 직접 구현한 DAO에서 가져오는 경우
- DAO에서 직접 어떤 쿼리를 날렸는지 확인하지 않는 이상, 그래프 형태의 관련된 객체들을 모두 잘 가져왔는지 알 수가 없다.
- 즉, 반환한 엔티티를 신뢰하고 사용할 수 없다.
JPA를 통해서 가져오는 경우
- 객체 그래프를 완전히 자유롭게 탐색할 수 있게 된다.
- 지연 로딩 전략(Lazy Loading) 사용
  - 관련된 객체를 사용하는 그 시점에 SELECT Query를 날려서 객체를 가져오는 전략

4) JPA와 비교하기

동일한 트랜잭션에서 조회한 엔티티는 같음을 보장한다.

String memberId = "100"; 
Member member1 = jpa.find(Member.class, memberId); // DB에서 가져옴 
Member member2 = jpa.find(Member.class, memberId); // 1차 캐시에서 가져옴
member1 == member2; //같다.

5. JPA의 성능 최적화 기능

중간 계층이 있는 경우 아래의 방법으로 성능을 개선할 수 있는 기능이 존재한다.
- 모아서 쓰는 버퍼링 기능
- 읽을 때 쓰는 캐싱 기능
JPA도 JDBC API와 DB 사이에 존재하기 때문에 위의 두 기능이 존재한다.

1) 1차 캐시와 동일성(identity) 보장 - 캐싱 기능

같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상 (크게 도움 X)

String memberId = "100"; 
Member m1 = jpa.find(Member.class, memberId); // SQL 
Member m2 = jpa.find(Member.class, memberId); // 캐시 (SQL 1번만 실행, m1을 가져옴)
println(m1 == m2) // true

결과적으로, SQL을 한 번만 실행한다.

DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

2) 트랜잭션을 지원하는 쓰기 지연(transactional write-behind) - 버퍼링 기능

INSERT

/** 1. 트랜잭션을 커밋할 때까지 INSERT SQL을 모음 */
transaction.begin();  // [트랜잭션] 시작
em.persist(memberA); 
em.persist(memberB); 
em.persist(memberC); 
// -- 여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.
// 커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다. --
/** 2. JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송 */
transaction.commit(); // [트랜잭션] 커밋

[트랜잭션]을 commit 할 때까지 INSERT SQL을 메모리에 쌓는다.
- 이렇게 하지 않으면 DB에 INSERT Query를 날리기 위한 네트워크를 3번 타게 된다.
JDBC Batch SQL 기능을 사용해서 한 번에 SQL을 전송한다.
- JDBC Batch를 사용하면 코드가 굉장히 지저분해진다.
- 지연 로딩 전략(Lazy Loading) 옵션을 사용한다.

UPDATE

/** 1. UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화 */
transaction.begin();  // [트랜잭션] 시작
changeMember(memberA);  
deleteMember(memberB);  
비즈니스_로직_수행();     // 비즈니스 로직 수행 동안 DB 로우 락이 걸리지 않는다.    
// 커밋하는 순간 데이터베이스에 UPDATE, DELETE SQL을 보낸다.
/** 2. 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋 */
transaction.commit(); // [트랜잭션] 커밋

UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋

3) 지연 로딩(Lazy Loading)

지연 로딩
- 객체가 실제로 사용될 때 로딩하는 전략
- memberDAO.find(memberId)에서는 Member 객체에 대한 SELECT 쿼리만 날린다.
- Team team = member.getTeam()로 Team 객체를 가져온 후에 team.getName()처럼 실제로 team 객체를 건드릴 때!
  - 즉, 값이 실제로 필요한 시점에 JPA가 Team에 대한 SELECT 쿼리를 날린다.
- Member와 Team 객체 각각 따로 조회하기 때문에 네트워크를 2번 타게 된다.
  - Member를 사용하는 경우에 대부분 Team도 같이 필요하다면 즉시 로딩을 사용한다.
즉시 로딩
- JOIN SQL로 한 번에 연관된 객체까지 미리 조회하는 전략
- Join을 통해 항상 연관된 모든 객체를 같이 가져온다.
애플리케이션 개발할 때는 모두 지연 로딩으로 설정한 후에, 성능 최적화가 필요할 때에 옵션을 변경하는 것을 추천한다.

6. 데이터 접근 추상화와 벤더 독립성

7. 표준

Reference

인프런 강의 참고

[JPA] JPA를 사용하는 이유

Sat, 03 Aug 2019 00:00:00 +0000

인프런 강의 참고

Goal

SQL에 의존적인 개발을 하게 된 배경

SQL 중심적인 개발의 문제점

지루한 코드의 무한 반복

객체 지향과 관계형 데이터베이스 간의 패러다임 불일치

객체(Object)와 관계형 데이터베이스(RDB)의 차이

모델링 과정에서의 문제

객체 그래프 탐색에서의 문제

“비교하기” 에서의 차이

배경

JPA와 모던 자바 데이터 저장 기술
- 애플리케이션 객체 지향 언어 (Java, Scala 등) + 관계형 DB (Oracle, MySQL 등)
- 객체를 영구 보관하는 다양한 저장소 (RDB, NoSQL, File, OODB 등) 가 존재하지만 현실적인 대안은 관계형 DB다.
즉, 객체를 관계형 DB에 저장해서 관리하는 것이 중요하다.
- 관계형 DB를 사용하려면 SQL을 짤 수 밖에 없다.
- 관계형 DB를 쓰는 상황에서는 SQL에 의존적인 개발을 피하기 어렵다.
하지만! SQL 중심적인 개발에는 여러 문제점이 있다.

SQL 중심적인 개발의 문제점

1. 지루한 코드의 무한 반복

CRUD의 반복
자바 객체를 SQL로, SQL을 자바 객체로 변환하는 과정의 반복
Ex)
- 회원에 나이 정보를 추가하고자 한다.
- Member 클래스에 private int age'를 추가한다.
- INSERT, SELECT, UPDATE 등 관련된 모든 쿼리에 age 정보를 추가한다.

2. 객체 지향과 관계형 데이터베이스 간의 패러다임 불일치

객체 지향
- ‘객체 지향 프로그래밍은 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공한다.’ - 어느 객체지향 개발자
- 필드와 메서드 등을 묶어서 잘 캡슐화해서 사용하는 것이 목표
관계형 데이터베이스 (RDB)
- 데이터를 잘 정규화해서 보관하는 것이 목표
패러다임이 다른 두 가지를 가지고 억지로 매핑하기 때문에 여러 가지 문제가 발생한다.
- Object를 RDB에 넣으려고 하니까 문제가 발생한다.
하지만, RDB가 인식할 수 있는 것은 SQL뿐이기 때문에 결국, Object를 SQL로 짜야한다.
- Object -> [SQL 변환] -> RDB에 저장
- [개발자 == SQL 매퍼] 라고 할만큼 SQL 작업을 너무 많이 하고 있다.

3. 객체(Object)와 관계형 데이터베이스(RDB)의 차이

1) 상속

Object
- 상속 관계가 있다.
RDB
- 상속 관계가 없다.
- Object의 상속 관계와 유사한 물리 모델로, Table 슈퍼타입-서브타입 관계가 존재한다.
- Album 객체를 DB에 저장하는 과정
  1. 객체를 분해한다. (Album 객체는 Item의 속성을 모두 가짐)
  2. 각각 다른 테이블에 대한 INSERT 쿼리를 두 번 날린다.
    - INSERT INTO ITEM ...
    - INSERT INTO ALBUM ...
- Album 을 조회하는 과정 (문제!!!)
  1. 각각의 테이블에 따른 Join SQL을 작성한다.
    - Item과 Album을 Join해서 데이터를 가져온다.
  2. 각각의 객체를 생성하고 모든 필드값을 세팅한다.
    - Item과 Album 각각 모든 필드값을 세팅한다.
  3. Movie, Book을 조회하고 싶으면 위의 과정을 또 반복해야 한다…
    - 그래서! DB에 저장할 객체에는 상속 관계를 사용하지 않는다.
자바 컬렉션에 저장하면?
- 저장: list.add(album);
- 조회: Album album = list.get(albumId);
- 다형성 활용: Item item = list.get(albumId);
  - 심지어 객체 세상이기 때문에 필요하면 부모 타입으로 조회한 후 다형성으로 활용할 수도 있다.
자바 컬렉션에 저장하면 굉장히 단순한 작업이 관계형 데이터베이스에 넣고 빼는 순간, 중간 중간의 Object와 RDB의 매핑 작업을 개발자가 직접 해줘야 하기 때문에 굉장히 번잡한 일이 된다.

2) 연관 관계

Object
- 참조(Reference)를 사용하여 연관 관계를 찾는다.
  - Ex) member.getTeam();
- 단방향으로만 관계가 존재한다.
  - Member -> Team은 가능하지만, Team -> Member는 불가능하다.
RDB
- 외래키(FK)를 사용하여 Join 쿼리를 통해 연관 관계를 찾는다.
  - Ex) JOIN ON M.TEAM_ID = T.TEAM_ID
- 양방향으로 모두 조회가 가능하다. 즉, 단방향이 존재하지 않는다.
  - Member -> Team 가능: MEMBER.TEAM_ID(FK)와 TEAM.ID(PK)를 Join
  - Team -> Member 가능: TEAM.ID(PK)와 MEMBER.TEAM_ID(FK)를 Join

3) 데이터 타입

4) 데이터 식별 방법

4. 모델링 과정에서의 문제

# 객체를 테이블에 맞추어 모델링

class Member { 
    String id;       // MEMBER_ID 컬럼 사용
    Long teamId;     // TEAM_ID FK 컬럼 사용 //**
    String username; // USERNAME 컬럼 사용
}
class Team { 
    Long id;         // TEAM_ID PK 사용
    String name;     // NAME 컬럼 사용
}

MEMBER.TEAM_ID에 해당하는 FK를 그대로 필드에 추가한다.
- Long teamId;
이렇게 설계된 객체를 DB에 저장 하려면,
- INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...
문제!: 객체지향스럽지 않다.
- Team 객체의 참조값 자체가 필드에 들어가는 것이 더 객체지향스럽다고 할 수 있다.

# 객체다운 모델링

class Member { 
    String id;        // MEMBER_ID 컬럼 사용 
    Team team;        // 참조로 연관관계를 맺는다. //** 
    String username;  // USERNAME 컬럼 사용 
                     
    Team getTeam() { 
        return team; 
    } 
}
class Team { 
    Long id;         // TEAM_ID PK 사용 
    String name;     // NAME 컬럼 사용 
}

Team 객체의 참조값 자체를 필드에 넣는다.
- Team team;
이렇게 설계된 객체를 DB에 저장 하려면,
- member.getTeam().getId() 로 값을 얻어와 TEAM_ID에 넣는다.
- INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...
Member 객체를 조회 하려면,
1. MEMBER와 TEAM을 Join해서 데이터를 한 번에 모두 가져온다.
2. Member와 Team에 대한 값을 각각 모두 세팅한다.
3. member.setTeam(team);과 같이 직접 연관 관계를 맺어 준다.
4. 해당 member 객체를 반환한다.

문제!: 데이터 조회의 복잡성

SELECT M.*, T.* 
FROM MEMBER M 
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID  

public Member find(String memberId) { 
  // SQL 실행 ... 
  Member member = new Member(); 
  // 데이터베이스에서 조회한 회원 관련 정보를 모두 입력 ...
  Team team = new Team(); 
  // 데이터베이스에서 조회한 팀 관련 정보를 모두 입력 ...
  member.setTeam(team); // 회원과 팀 관계 설정  //**
  return member; 
}

객체다운 모델링을 자바 컬렉션에 관리하면?
- 데이터 조회의 복잡성이 사라져, 좋은 설계가 된다.
- 저장
  - list.add(member);
- 조회
  - Member member = list.get(memberId);
  - Team team = member.getTeam();
- 이런 모델링을 DB에 넣는 순간, 굉장히 복잡해지며 생산성(조회 복잡)이 나빠진다.
생산성이 높은 방법?
- Member, Team 을 모두 포함한 큰 클래스(Super DTO)를 하나 만든다.
- Super DTO 하나를 반환한다.
- 오히려 이런 방법이 생산성 측면에서는 좋은 방법일 수도 있다.

5. 객체 그래프 탐색에서의 문제

객체는 자유롭게 객체 그래프(연관 관계가 있는 객체 사이)를 탐색할 수 있어야 한다.
- member.getTeam(), member.getOrder().getOrderItem() 등 …
하지만, 서비스 로직에서 RDB와 연결된 데이터를 탐색할 때 객체 그래프를 탐색할 수 없다.
- Why? 처음 실행하는 SQL에 따라 탐색 범위가 결정되기 때문이다.
- Ex) 처음 SQL에서 Member와 Team을 가져왔다고 하면, Order는 가져오지 않았기 때문에 member.getOrder()는 null이 된다.
```
  SELECT M.*, T.*
  FROM MEMBER M
  JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID  
```
```
  member.getTeam();  // OK
  member.getOrder(); // null
```

문제점

문제!: Entity 신뢰 문제

class MemberService { 
  ...
  public void process() { 
      Member member = memberDAO.find(memberId); 
      member.getTeam(); // ??? 
      member.getOrder().getDelivery(); // ??? 
  } 
}

Ex) 개발자 A가 DAO를 구현하고 개발자 B가 위의 서비스 로직(process())을 구현했을 때,
- 개발자 B는 DAO에서 반환한 엔티티를 신뢰하고 사용할 수 없다.
- DAO에서 직접 어떤 쿼리를 날렸는지 확인하지 않는 이상, 알 수가 없다.
이와 같은 계층형 아키텍처(Layered 아키텍처)에서는 그 다음 계층에서 신뢰하고 사용해야 하는데, 여기에서는 엔티티를 신뢰할 수 없는 문제가 발생하게 된다.
- 물리적으로는 Service Layer, DAO Layer 등으로 계층이 분리되어 있지만,
- 논리적으로는 DAO 내부 코드를 직접 확인한 후에 엔티티를 제대로 가져오는지 신뢰를 할 수 있기 때문에 각 계층이 엮여 있는 상태라고 할 수 있다.

해결책?

그렇다고 모든 객체를 미리 로딩할 수는 없다.
- 대안: 여러 상황에 따른 동일한 회원 조회 메서드를 여러 개 만들어 둔다.
- 문제: 다양한 상황을 고려한 너무 많은 메서드를 생성해야 한다.
```
memberDAO.getMember();  // Member만 조회
memberDAO.getMemberWithTeam();  // Member와 Team 조회
memberDAO.getMemberWithOrderWithDelivery();  // Member, Order, Delivery 조회 
```
이렇게 SQL을 직접 다루면 계층형 아키텍처(Layered 아키텍처)에서 진정한 의미의 계층 분할이 어렵다.
- 물리적으로는 계층이 나누어져 있지만, 논리적으로는 굉장히 강결합되어 있다.

6. “비교하기” 에서의 차이

# 일반적인 SQL을 사용하는 경우

String memberId = "100"; 
Member member1 = memberDAO.getMember(memberId); 
Member member2 = memberDAO.getMember(memberId);

member1 == member2; // 다르다!!!

class MemberDAO { 
    public Member getMember(String memberId) { 
        String sql = "SELECT * FROM MEMBER WHERE MEMBER_ID = ?"; 
        ... 
        // JDBC API, SQL 실행 
        return new Member(...); 
    }
}

식별자가 같아도 DAO의 getMember()에서
- 각각에 대해서 SELECT Query를 날리고 (두 번 날림)
- new Member()로 객체를 생성하기 때문에 당연히 다르다.

# 자바 컬렉션에서 조회하는 경우

String memberId = "100";
Member member1 = list.get(memberId);
Member member2 = list.get(memberId);
member1 == member2; // 같다!!! (참조값이 같다.)

식별자가 같을 때 컬렉션에서의 두 객체의 참조값은 같기 때문에 두 객체는 같다.

마무리

객체답게 모델링 할수록 매핑 작업만 늘어난다.
객체를 자바 컬렉션에 저장하고 불러오듯이 DB에 저장할 수는 없을까?
- 이 고민의 결과가 바로 JPA(Java Persistence API) 이다!!

Reference

인프런 강의 참고

[IntelliJ] intellij 유용한 단축키 정리

Tue, 21 May 2019 00:00:00 +0000

인프런 강의 참고

코드 Edit

포커스

검색

자동완성

리팩토링

디버깅

Git

플러그인

계속해서 추가할 예정입니다!

기본 단축키

디렉터리, 패키지, 클래스 등 생성 목록 보기

MacOS: Cmd + n
Win/Linux: Alt + Insert

코드 Edit

Main method 생성 및 실행

메인 메서드 선언
- live template 이용: psvm
- (live template은 아래 참고)
메인 메서드 실행
1. 좌측 실행 버튼
2. 단축키
  - 현재 Focus 가 해당 메서드에 있어야 함
  - MacOS: Ctrl + Shift + r
  - Win/Linux: Ctrl + Shift + F10 - 이전 실행문 재실행 (우측 상단에 실행문 목록 확인 가능)
  - MacOS: Ctrl + r
  - Win/Linux: Shift + F10

라인 수정하기

라인 복제하기
- MacOS: Cmd + d
- Win/Linux: Ctrl + d
라인 삭제하기
- MacOS: Cmd + 백스페이스
- Win/Linux: Ctrl + y
문자열 라인 합치기
- MacOS: Ctrl + Shift + j
- Win/Linux: Ctrl + Shift + j
라인 단위로 옮기기
- 1) 문법에 관계 없이 라인 이동
  - MacOS: Opt + Shift + ↑↓
  - Win/Linux: Alt + Shift + ↑↓
- 2) 구문 안에서만 라인 이동 (메서드를 벗어날 수 없음)
  - MacOS: Cmd + Shift + ↑↓
  - Win/Linux: Ctrl + Shift + ↑↓
Element 단위로 옮기기
- Ex. html, xml 등의 규격이 정해진 마크업 언어에서 활용
- MacOS: Cmd + Opt + Shift + ←→
- Win/Linux: Ctrl + Alt + Shift + ←→

코드 즉시 보기

인자값 즉시 보기 (Parameter Info)
- MacOS: Cmd + p
- Win/Linux: Ctrl + p
코드 구현부 즉시 보기 (Quick Definition)
- 클래스- 클래스 전체 코드
- 인스턴스- 인스턴스 생성 코드
- 메서드- 메서드 정의 코드
- MacOS: Opt + Space
- Win/Linux: Ctrl + Shift + i
Doc 즉시 보기 (Quick Documentation)
- MacOS: F1
- Win/Linux: Ctrl + q

포커스

포커스 에디터

단어별 이동
- MacOS: Opt + ←→
- Win/Linux: Ctrl + ←→
단어별 선택 (Move Caret to Next Word with Selection)
- MacOS: Opt + Shift + ←→
- Win/Linux: Ctrl + Shift + ←→
라인 첫/끝 이동
- MacOS: fn + ←→
- Win/Linux: Home, End
라인 전체 선택
- MacOS: fn + Shift + ←→
- Win/Linux: Shift + Home, End
Page Up/Down
- MacOS: fn + ↑↓
- Win/Linux: Page Up, Page Down

포커스 특수키

포커스 범위 한 단계씩 늘리기 (Extend Selection)
- 해당 커서의 단어 포커스하기
- MacOS: Opt + ↑↓
- Win/Linux
  - 위: Ctrl + w
  - 아래: Ctrl + Shift + w
포커스 뒤로/앞으로 가기 (Navigate -> Back/Forward)
- 이전 커서가 있던 화면으로 돌아갈 때 유용
- 클래스 이동도 가능
- MacOS: Cmd + [ 또는 ]
- Win/Linux: Ctrl + Alt + ←→
멀티 포커스 (Clone Caret Below)
- MacOS: Opt + Opt + ↓ (Opt 누른 상태)
- Win/Linux: Ctrl + Ctrl + ↓ (Ctrl 누른 상태)
오류 라인으로 자동 포커스 (Navigate -> Next Highlighted Error)
- MacOS: F2
- Win/Linux: F2

검색

검색 텍스트

현재 파일에서 검색 (Find)
- MacOS: Cmd + f
- Win/Linux: Ctrl + f
현재 파일에서 교체 (Replace)
- MacOS: Cmd + r
- Win/Linux: Ctrl + r
전체에서 검색 (Find in Path)
- MacOS: Cmd + Shift + f
- Win/Linux: Ctrl + Shift + f
전체에서 교체 (Replace in Path)
- MacOS: Cmd + Shift + r
- Win/Linux: Ctrl + Shift + r
정규표현식으로 검색, 교체
- [Find/Replace] -> Regex 체크

검색 기타

파일 검색 (Navigate -> File)
- MacOS: Cmd + Shift + o
- Win/Linux: Ctrl + Shift + n
메서드 검색 (Navigate -> Symbol)
- MacOS: Cmd + Opt + o
- Win/Linux: Ctrl + Shift + Alt + n
Action 검색 (Find Action: Enter action or option name)
- MacOS: Cmd + Shift + a
- Win/Linux: Ctrl + Shift + a
최근 열었던 파일 목록 보기 (Recent Files)
- MacOS: Cmd + e
- Win/Linux: Ctrl + e
최근 수정한 파일 목록 보기 (Recently Changed Files)
- MacOS: Cmd + Shift + e
- Win/Linux: Ctrl + Shift + e

자동완성

기본 자동완성 (Completion -> Basic)
- MacOS: Ctrl + Space
- Win/Linux: Ctrl + Space
스마트 자동완성 (Completion -> SmartType)
- MacOS: Ctrl + Shift + Space
- Win/Linux: Ctrl + Shift + Space
static method 자동완성
- MacOS: Ctrl + Space + Space
- Win/Linux: Ctrl + Space + Space
getter/setter/생성자 자동완성 (Generate)
- MacOS: Cmd + n
- Win/Linux: Alt + Insert
Override 메서드 자동완성 (Implement Methods)
- MacOS: Ctrl + i
- Win/Linux: Ctrl + i

Live Template (Code Template)

live template 목록 확인하기 (Insert Live Template)
- [Find Action] -> Live Templates 입력
- MacOS: Cmd + j
- Win/Linux: Ctrl + j
자주 사용하는 live template 예시
- psvm: 메인메서드 선언
- sout: System.out.println(); 자동 생성
나만의 live template 추가하기
1. [Find Action] -> Live Templates 입력
2. other 선택 -> “+” 버튼 -> Live Template
3. Abbreviation(축약어)
  - Ex. ent
4. Description(설명)
  - Ex. Entity Class Header
5. Template text(텍스트)
  - 아래 예시
6. Error(No applicable contexts yet.)에서 Define 클릭
  - Ex. Java 선택
7. Apply & OK

// ORM에서의 반복적인 코드 (live template로 설정)
@Getter
@NoArgsConstructor(access = AccessLevel.PROOTECTED)
@Entity
/** Entity Class */
public class Comment {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private long id;
}

리팩토링

리팩토링 Extract

변수 추출하기 (Extract -> Variable)
- MacOS: Cmd + Opt + v
- Win/Linux: Ctrl + Alt + v
파라미터 추출하기 (Extract -> Parameter)
- MacOS: Cmd + Opt + p
- Win/Linux: Ctrl + Alt + p
메서드 추출하기 (Extract -> Method)
- MacOS: Cmd + Opt + m
- Win/Linux: Ctrl + Alt + m
이너클래스 추출하기
- MacOS: F6
- Win/Linux: F6

리팩토링 기타

이름 일괄 변경하기 (Rename)
- MacOS: Shift + F6
- Win/Linux: Shift + F6
타입 일괄 변경하기 (Type Migration)
- MacOS: Cmd + Shift + F6
- Win/Linux: Ctrl + Shift + F6
Import 정리하기 (Optimize Imports)
- MacOS: Ctrl + Opt + o
- Win/Linux: Ctrl + Alt + o
- 자동 설정: [Find Action] -> Optimize imports on 입력 -> “Auto import: …”
코드 자동 정렬하기 (Reformat Code)
- MacOS: Cmd + Opt + l
- Win/Linux: Ctrl + Alt + l

디버깅

Break Point 걸기 (Toggle Line Breakpoint)
- 해당 라인 number 옆 클릭
- MacOS: Cmd + F8
- Win/Linux: Ctrl + F8
- Break Point의 라인은 아직 실행하기 전 상태이다.
Conditional Break Point
- 반복문에서 특정값을 가지고 있는 객체가 나왔을 때만 멈추고자 할 때 유용
- Break Point (빨간원) 우클릭 -> 조건 입력
  - Ex. “HEEE”.equals(user.name)
Debug 모드로 실행하기 - 즉시 실행 (Debug)
- 현재 Focus 가 해당 메서드에 있어야 함
- 좌측 디버그 실행 버튼
- MacOS: Ctrl + Shift + d
- Win/Linux: 없음 (커스텀해서 사용하거나 마우스 이용)
Debug 모드로 실행하기 - 이전 실행
- 이전 실행문 재실행 (우측 상단에 실행문 목록 확인 가능)
- MacOS: Ctrl + d
- Win/Linux: Shift + F9

Breaking 상태에서의 기능

Resume (다음 Break Point로 넘어가기)
- MacOS: Opt + Cmd + r
- Win/Linux: F9
참고 Debugger 탭 설명
- Debugger 탭 좌측 창 - Call Stack
  - 현재 Break Point로 넘어오기까지 실행한 메서드 목록
  - 오픈 소스 코드를 분석할 때 유용
- Debugger 탭 우측 창 - Variables
  - 현재 Break Point에서 볼 수 있는 변수값 목록
Step Over (다음 라인으로 넘어가기)
- MacOS: F8
- Win/Linux: F8
Step Into (해당 라인 안(다음 메서드)으로 들어가기)
- MacOS: F7
- Win/Linux: F7
Step Out (현재 포커스를 밖으로 빼기)
- MacOS: Shift + F8
- Win/Linux: Shift + F8
Evaluate Expression (현재 Breaking 상태에서 즉시 코드 실행하기)
- MacOS: Opt + F8
- Win/Linux: Alt + F8
- 데이터가 잘 들어갔는지 확인할 때 유용
- 켤 때마다 초기화 - 단발성 코드를 실행할 때 유용
Watch (Breaking 이후의 코드 변경 확인하기)
- MacOS: 없음
- Win/Linux: 없음
- 다음 Break Point 전까지 확인하고 싶은 값을 계속 주시하고자할 때 유용

Git & Github

Git 기본 기본 기능 사용하기

Git View On
- View 탭 -> Tool Windows -> Version Control
- MacOS: Cmd + 9
- Win/Linux: Alt + 9
Git Option Popup (VCS Operations Popup)
- MacOS: Ctrl + v
- Win/Linux: Alt + `(Back Quote)
Git History
- MacOS: Ctrl + v => 4
- Win/Linux: Alt + ` => 4
Branch
- MacOS: Ctrl + v => 7
- Win/Linux: Alt + ` => 7
Commit
- MacOS: Cmd + k
- Win/Linux: Ctrl + k
Push
- MacOS: Cmd + Shift + k
- Win/Linux: Ctrl + Shift + k
Pull
- MacOS: [Find Action] => git pull 검색
- Win/Linux: [Find Action] => git pull 검색

플러그인

플러그인 설치 방법

[Find Action] -> plugins 입력 -> Preferences/Settings의 Plugins 선택
Browse repositories… 클릭
Sort by: Downloads 로 설정

Reference

https://www.inflearn.com/course/intellij-guide/lecture/13200

이미지 참고

[VIM] vim 유용한 단축키 정리

Tue, 14 May 2019 00:00:00 +0000

Goal

vim의 단축키 사용법에 대해 이해한다.

이동

편집 (삽입, 삭제, 수정, 복사, 붙여넣기 등)

선택

검색

기타 (매크로, 이어 붙이기, 취소하기/되돌리기 및 들여쓰기/내어쓰기, 대소문자 전환, 숫자 증감, 창 열기/탭 이동 등 )

이동

기본 이동

h, j, k, l: 좌,하,상,우 커서 이동
-: 줄의 처음 위치로 커서 이동
gg: 맨 위로 커서 이동
[shift + g]: 맨 아래로 커서 이동

단어 단위로 이동

w: 단어의 시작 위치로 커서 이동 (forward 방향)
- Ex. 3w: 세 단어 앞으로 커서 이동
e: 단어의 마지막 위치로 커서 이동 (forward 방향)
b: 단어의 시작 위치로 커서 이동 (backward 방향)
ge: 단어의 마지막 위치로 커서 이동 (backward 방향)

한 문장 내에서의 이동

0(숫자): 라인 맨 앞으로 커서 이동
^: 문장 맨 앞으로 커서 이동
$: 문장 맨 뒤로 커서 이동

대략적인 위치로 이동 (현재 보이는 페이지 기준)

[shift + h]: 현재 보이는 페이지를 기준으로 맨 위로 커서 이동
[shift + m]: 현재 보이는 페이지를 기준으로 중간 라인으로 커서 이동
[shift + l]: 현재 보이는 페이지를 기준으로 맨 아래로 커서 이동

페이지 이동

[ctrl+ f]: 다음 페이지의 첫 줄로 커서 이동
[ctrl+ b]: 다음 페이지의 마지막 줄로 커서 이동
[ctrl+ d]: 페이지의 절반 크기만큼 아래로 커서 이동
[ctrl+ u]: 페이지의 절반 크기만큼 위로 커서 이동

원하는 줄 번호로 한 번에 이동

줄 번호 설정 및 해지
- [: + set number]: 줄 번호 설정
- [: + set nonumber]: 줄 번호 설정
방법1
1. [esc] 를 눌러 표준 모드로 진입
2. [:] 를 누른 후 원하는 [줄 번호] 입력
방법2
1. [esc] 를 눌러 표준 모드로 진입
2. 원하는 [줄 번호] 입력
3. [shift + g] 입력

`{}`(컬리 블레이스, Curly Brace) 을 기준으로 이동

]]: {로 커서 이동 (forward 방향)
- 없으면 페이지의 맨 아래로 커서 이동
- {은 가장 상위의 블록을 감싸고 있는 문자만 찾는다.
[[: {로 커서 이동 (backward 방향)
][: }로 커서 이동 (forward 방향)
- 없으면 페이지의 맨 위로 커서 이동
- }은 가장 상위의 블록을 감싸고 있는 문자만 찾는다.
[]: }로 커서 이동 (backward 방향)
%: {}나 ()에서 현재 괄호의 짝으로 커서 이동

편집

삽입 관련 단축키 (입력 가능한 상태로 변경)

i: 현재 커서가 위치한 문자의 앞에 Insert 하기
I: 현재 커서가 위치한 줄 맨 앞에 Insert 하기
a: 현재 커서가 위치한 문자의 뒤에 Insert 하기
A: 현재 커서가 위치한 줄 맨 뒤에 Insert 하기
O: 현재 커서가 위치한 줄 바로 윗줄에 Insert 하기
o: 현재 커서가 위치한 줄 바로 아랫줄에 Insert 하기

삭제/잘라내기 및 수정 관련 단축키

dd: 커서가 위치한 줄 잘라내기
dw: 커서가 위치한 곳부터 단어의 마지막까지 잘라내기
- Ex. 숫자 + dd: 커서가 위치한 줄부터 숫자에 해당하는 수만큼의 줄 잘라내기
[shift + d]: 현재 커서의 위치부터 줄의 끝까지 잘라내기
x: 커서가 위치한 문자 잘라내기
[shift + x]: 커서가 위치한 문자 바로 앞에 있는 문자 잘라내기
s: 커서가 위치한 문자 잘라내고 Insert 하기
cc 또는 [shift + s]: 커서가 위치한 줄 전체 잘라내고 Insert 하기
cw: 커서가 위치한 곳부터 단어의 마지막까지 잘라내고 Insert 하기
[shift + c]: 현재 커서의 위치부터 줄의 끝까지 잘라내고 Insert 하기
[r + 변경할 문자]: 커서가 위치한 문자 하나 수정하기
- Ex. 4rx: 현재 커서 이후 4개의 글자를 “x”로 수정한다.

복사/붙여넣기 관련 단축키

yl: 현재 커서가 위치한 문자 하나만 복사하기
- Ex. 3yl: 현재 커서 이후 3개의 문자를 복사한다.
yy: 현재 커서가 위치한 줄 복사하기
yw: 현재 커서의 위치부터 단어가 끝나는 위치까지 복사하기
y: 블럭 단위로 체크한 내용(비주얼 모드 이용) 복사하기 - 한 문자만 복사 X
- Ex. 숫자 + y: 커서가 위치한 줄부터 숫자에 해당하는 수만큼의 줄 복사하기
- Ex. y$: 커서가 위치한 곳부터 줄의 마지막까지 복사하기
p:
- 단어 복사: 현재 커서가 위치한 바로 다음 위치에 붙여넣기
- 행 복사: 현재 커서가 위치한 줄 바로 아랫줄에 붙여넣기
[shift + p]:
- 단어 복사: 현재 커서가 위치한 바로 앞 위치에 붙여넣기
- 행 복사: 현재 커서가 위치한 줄 바로 윗줄에 붙여넣기
숫자 + p: 해당 숫자 만큼 붙여넣기를 반복하기

선택

한 줄 선택

[shift + v]: 라인 단위로 블럭지정이 가능하다.

단어 단위로 여러 줄 선택

[esc] 를 눌러 표준 모드로 진입
v 를 눌러 여러 줄을 선택할 수 있는 상태를 만든다.
- v: 단어 단위
- [shift + v]: 라인 단위

멀티 포커스

[ctrl + v]: 블럭 단위로 여러 줄 선택. 즉, 사각형의 블럭지정이 가능하다.

검색

/ + 찾을 단어 + Enter: 문서에서 단어 찾기
- n 또는 *: 다음 찾기 (forward 방향)
- N 또는 #: 이전 찾기 (backward 방향)

기타

매크로

추가 예정

다음 줄을 현재 커서가 있는 줄의 끝으로 이어 붙이기

[shift + j]: 다음 줄을 현재 커서가 있는 줄의 끝으로 이어 붙인다.

취소하기/되돌리기 및 들여쓰기/내어쓰기

u: Undo, 이전으로 취소하기
[ctrl + r]: Redo, 취소한 것을 다시 되돌리기
> 2번 클릭: 들여쓰기
- >}: 한 문단 전체를 들여쓰기
- Ex. 2»: 2번 들여쓰기
< 2번 클릭: 내어쓰기
.: - 이전 명령어를 다시 실행

대소문자 전환

[shift + ~]: 현재 커서가 위치한 문자의 대소문자를 변경한다.

숫자 증감

[ctrl + a]: 현재 커서가 위치한 하나의 문자가 숫자라면 해당 명령어로 숫자를 증가시킬 수 있다.
[ctrl + x]: 현재 커서가 위치한 하나의 문자가 숫자라면 해당 명령어로 숫자를 감소시킬 수 있다.

창 열기/탭 이동 등

[: + vs]: 현재의 창을 세로로 분할된 창으로 하나 더 열기
[: + new]: 새 창을 현재의 창 아래(세로로)에 분할된 창으로 열기
[: + tabnew]: 새 창을 현재의 창과 같은 위치에 열기
[ctrl + w] 2번 클릭: 분할 창 간에 이동
[gt]: 오른쪽 탭으로 이동
[gT]: 왼쪽 탭으로 이동

코드 형식 관련

zc: 코드 접기 (fold)
zM: 코드 모두 접기 (fold)
zo: 접힌 코드 펼치기
zR: 접힌 코드 모두 펼치기
zd: fold 지우기
zD: 모든 fold 지우기

Reference

https://blog.outsider.ne.kr/540

https://vim.rtorr.com/lang/ko

http://egloos.zum.com/kwon37xi/v/1501256

https://vim.rtorr.com/lang/ko

https://devanix.tistory.com/170

http://ickhyun82.blogspot.com/2012/02/vi.html

vimgolf - vi 학습 프로그램

[DB] SQL문 기본 문법 - 데이터 추가, 삭제, 갱신

Mon, 13 May 2019 00:00:00 +0000

Goal

INSERT 명령문 (SQL 기본 문법)

UPDATE 명령문 (SQL 기본 문법)

DELETE 명령문 (SQL 기본 문법)

INSERT 명령문 (SQL의 DML)

DB의 테이블에 행 추가
- 웹 페이지에서 ‘신규등록’이나 ‘추가’와 같은 버튼을 클릭했을 때 처리되는 데이터 추가 기능
SELECT 명령의 경우 실행하면 그 결과가 클라이언트에게 반환되자만, INSERT 명령은 데이터가 클라이언트에서 서버로 전송되므로 반환되는 결과가 없다.

기본 사용 예시

> INSERT INTO 테이블명 VALUES(값1, 값2, ...);
> INSERT INTO sample VALUES(1, 'HEEE', '2019-04-27');

값을 저장할 열 지정

> INSERT INTO 테이블명 (열1, 열2, ...) VALUES(값1, 값2, ...);
> INSERT INTO sample (name, no) VALUES('HEEE2', 2);

NOT NULL 제약
- NULL을 허용하고 싶지 않은 열에 NOT NULL 제약을 걸어둔다.
DEFAULT
- 명시적으로 값을 지정하지 않았을 경우 사용하는 초깃값을 말한다.
- DESC 테이블명으로 테이블의 열 구성을 살펴보면 Default라는 항목에서 초깃값 확인 가능

DELETE 명령문 (SQL의 DML)

DB의 테이블에서 행을 삭제
삭제는 행 단위로 수행되며, 열을 지정하여 해당 열만 삭제할 수는 없다.
DELETE 명령을 실행할 때는 재확인을 위한 대화창 같은 것이 표시되지 않기 때문에 주의해야 한다.

기본 사용 예시

> DELETE FROM 테이블명 WHERE 조건식;

// sample 테이블의 모든 데이터 삭제
> DELETE FROM sample;
// sample 테이블의 no 열이 2인 행 삭제 
> DELETE FROM sample where no=2;

물리삭제와 논리삭제
- DB에서 데이터를 삭제하는 방법은 용도에 따라 크게 ‘물리삭제’와 ‘논리삭제’로 나뉜다.
- 물리삭제
  - SQL의 DELETE 명령을 사용해 직접 데이터를 삭제하는 것
  - Ex) SNS 서비스에서의 사용자 탈퇴
- 논리삭제
  - 테이블에 ‘삭제 플래그’를 두어 행을 삭제하는 대신, SQL의 UPDATE 명령을 사용해 해당 플래그의 값을 유효하게 갱신해두는 것
  - 장점: 삭제 되기 전의 상태로 간단히 되돌릴 수 있다.
  - 단점: 삭제해도 DB의 저장공간이 늘어나지 않는다. 이로 인해 DB 크기가 증가하여 검색속도가 떨어진다.
  - Ex) 쇼핑 사이트에서의 주문 취소

UPDATE 명령문 (SQL의 DML)

DB의 테이블에서 데이터를 갱신
- 웹 페이지에서 ‘등록’이나 ‘갱신’와 같은 버튼을 클릭했을 때 처리되는 데이터 갱신 기능
DELETE 명령어와 달리 셀 단위로 데이터를 갱신할 수 있다.
WHERE 구를 생략한 경우에는 테이블의 모든 행이 갱신된다.
테이블에 존재하지 않는 열을 지정하면 에러가 발행하여 해당 명령은 실행되지 않는다.

기본 사용 예시

> UPDATE 테이블명 SET 열1=값1, 열2=값2, ... WHERE 조건식;

> UPDATE sample SET name='HEEE' WHERE no=2;
> UPDATE sample SET name='HEEE', date='2019-04-26' WHERE no=2;
> UPDATE sample SET name=NULL; // NULL로 초기화 

SET 구의 실행순서
```
> UPDATE sample SET no=no+1, a=no; // 1번
> UPDATE sample SET a=no, no=no+1; // 2번
```
- MySQL에서는 기술한 식의 순서에 따라 갱신 처리가 일어난다.
  - 1번에서의 no 열의 값은 갱신된 이후의 값을 반환하고 a 열은 갱신된 값을 참조한다.
  - Ex) 1번의 경우, 초기 no: 2, 3 -> 갱신 후 no: 3, 4 / a: 3, 4
  - 2번에서의 a 열은 갱신되기 전의 값을 참조하고 이후에 no 열이 갱신된다.
  - Ex) 2번의 경우, 초기 no: 2, 3 -> 갱신 후 no: 3, 4 / a: 2, 3
  - 즉, MySQL 의 경우 갱신식 안에서 열을 참조할 때는 처리 순서를 고려할 필요가 있다.
- Oracle에서는 SET 구에 기술한 식의 순서가 처리에 영향을 주지 않는다.
  - 1, 2번 모두 no 열의 값이 항상 갱신 이전의 값을 반환하기 때문에 no 열을 참조하는 a 열의 값은 갱신 전의 값이 된다.
  - 이후에 no 열이 갱신된다.
  - Ex) 1, 2번 모두, 초기 no: 2, 3 -> 갱신 후 no: 3, 4 / a: 2, 3

Reference

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788968482311

[DB] SQL문 기본 문법 - 검색편(select)

Thu, 25 Apr 2019 00:00:00 +0000

Goal

SQL이란

SQL 명령의 종류

SELECT 명령문 (SQL 기본 문법)

검색 조건 지정

검색 조건 조합

패턴 매칭에 의한 검색

SQL문

SQL은 “관계형 데이터베이스” 관리 시스템(RDBMS, Relational Database Management System)을 조작할 때 사용하는 언어이다.

RDBMS: 행과 열을 가지는 표 형식 데이터(2차원 데이터)를 저장하는 형태의 DB
- 행(레코드), 열(컬럼/필드), 셀(행과 열이 만나는 부분, 하나의 데이터 값)
- 수치형, 문자열형, 날짜시간형, NULL(값이 없는 데이터) 등의 자료형이 존재

SQL 명령의 종류

DML (Data Manipulation Language)
- 데이터 조작, SQL의 가장 기본이 되는 명령셋(set)
- DB에 새롭게 데이터를 추가하거나 삭제하거나 내용을 갱신하는 등에 사용
DDL (Data Definition Language)
- 데이터 정의
- DB 객체(object)라는 데이터 그릇을 이용하여 데이터를 관리하는데, 이 같은 객체를 만들거나 삭제하는 명령어
- DB 객체에는 테이블, 뷰(View) 등이 있다.
DCL (Data Control Language)
- 데이터 제어
- 트랜잭션을 제어하는 명령과 데이터 접근 권한을 제어하는 명령 포함

DESC 명령 (SQL 명령 아님)

테이블의 구조 참조
- 테이블에 어떤 열이 정의되어 있는지 알 수 있다.
- 열 이름(Field), 열의 자료형(Type), NULL 제약사항(Null), Key 지정 정보(Key), 생략된 경우의 기본값(Default) 등 해당 테이블의 구조 정보를 확인할 수 있다.

> desc tablename;

SELECT 명령문 (SQL의 DML)

DML에 속하는 명령으로 “질의”나 “쿼리”라 불리기도 한다.

// tableName에 해당하는 테이블의 모든 열을 읽는다.
> select * from tablename;

// 위와 동일 (대소문자 구별 X)
> SELECT * from tableName;

예약어와 DB 객체명은 대소문자를 구별하지 않는다.

검색 조건 지정

열 지정

> select 열1, 열2 from 테이블명 where 조건식
> SELECT address, name FROM sample;

행 지정

// select 구 -> from 구 -> where 구 (순서 중요)
> select 열 from 테이블명 where 조건식

// 수치형
> SELECT * FROM sample WHERE id=2; // id 열 값이 2와 동일한 행만 검색
> SELECT * FROM sample WHERE id<>2; // id 열 값이 2가 아닌 행만 검색

// 문자열형
> SELECT * FROM sample WHERE name='아무개'; 

// NULL값
> SELECT * FROM sample WHERE birthday IS NULL;

where 구(조건식)는 ‘열과 연산자, 상수로 구성되는 식’이다.

검색 조건 조합

AND, OR, NOT

> 조건식1 AND 조건식2
> SELECT * FROM sample WHERE a<>0 AND b<>0; // a열, b열이 모두 0이 아닌 행 검색

> 조건식1 OR 조건식2
> SELECT * FROM sample WHERE a<>0 OR b<>0; // a열이 0이 아니거나 b열이 0이 아닌 행 검색

> NOT 조건식
> SELECT * FROM sample WHERE NOT(a<>0 OR b<>0); // a열이 0이 아니거나 b열이 0이 아닌 행을 제외한 나머지 행 검색

AND는 OR에 비해 우선 순위가 높다.

패턴 매칭에 의한 검색

특정 문자나 문자열이 포함되어 있는지를 검색하고 싶은 경우 ‘패턴 매칭’(부분 검색)을 사용
LIKE

> 열 LIKE '패턴'

// text 열에 'SQL'을 포함하는 행을 검색
> SELECT * FROM sample WHERE text LIKE 'SQL%'; // (전방일치) 
> SELECT * FROM sample WHERE text LIKE '%SQL%'; // (중간일치) 

// text 열에 '%'(메타문자)을 포함하는 행을 검색
> SELECT * FROM sample WHERE text LIKE '%\%%'; // 이스케이프 문자(/) 사용 

// text 열에 'It's'을 포함하는 행을 검색
> SELECT * FROM sample WHERE text LIKE 'It''s'; // '를 문자열 상수 안에 포함할 경우 2개를 연속해서 기술 

사용할 수 있는 메타문자(또는 와일드카드)는 ’%’와 ‘_‘가 있다.
%(퍼센트): 임의의 문자열과 매치, 빈 물자열에도 매치한다.
_(언더스코어): 임의의 문자 하나
*는 사용할 수 없다.

Reference

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788968482311

[JavaScript] 호이스팅(Hoisting)이란

Mon, 22 Apr 2019 00:00:00 +0000

Edwith 강의 참고

Goal

호이스팅(Hoisting)이란 무엇인지 이해한다.

함수선언문과 함수표현식에서의 호이스팅 차이를 이해한다.

let/const와 var 변수 선언에서의 호이스팅 예시

같은 이름의 var 변수 선언과 함수 선언에서의 호이스팅에 대해 이해한다.

호이스팅(Hoisting)의 개념

함수 안에 있는 선언들을 모두 끌어올려서 해당 함수 유효 범위의 최상단에 선언하는 것을 말한다.

호이스팅이란

자바스크립트 함수는 실행되기 전에 함수 안에 필요한 변수값들을 모두 모아서 유효 범위의 최상단에 선언한다.
- 자바스크립트 Parser가 함수 실행 전 해당 함수를 한 번 훑는다.
- 함수 안에 존재하는 변수/함수선언에 대한 정보를 기억하고 있다가 실행시킨다.
- 유효 범위: 함수 블록 {} 안에서 유효
즉, 함수 내에서 아래쪽에 존재하는 내용 중 필요한 값들을 끌어올리는 것이다.
- 실제로 코드가 끌어올려지는 건 아니며, 자바스크립트 Parser 내부적으로 끌어올려서 처리하는 것이다.
- 실제 메모리에서는 변화가 없다.

호이스팅의 대상

var 변수 선언과 함수선언문에서만 호이스팅이 일어난다.
- var 변수/함수의 선언만 위로 끌어 올려지며, 할당은 끌어 올려지지 않는다.
- let/const 변수 선언과 함수표현식에서는 호이스팅이 발생하지 않는다.

간단한 예시 (var 변수 vs let/const 변수)

  console.log("hello");
  var myname = "HEEE"; // var 변수 
  let myname2 = "HEEE2"; // let 변수 

  /** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 - 위와 동일 --- */
  var myname; // [Hoisting] "선언"
  console.log("hello");
  myname = "HEEE"; // "할당"
  let myname2 = "HEEE2"; // [Hoisting] 발생 X

간단한 예시 (함수선언문 vs 함수표현식)

  foo();
  foo2();

  function foo() { // 함수선언문
          console.log("hello");
  }
  var foo2 = function() { // 함수표현식
          console.log("hello2");
  }

  /** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 - 위와 동일 --- */
  var foo2; // [Hoisting] 함수표현식의 변수값 "선언"

  function foo() { // [Hoisting] 함수선언문
          console.log("hello");
  }

  foo();
  foo2(); // ERROR!! 

  foo2 = function() { 
          console.log("hello2");
  }

호이스팅은 함수선언문과 함수표현식에서 서로 다르게 동작하기 때문에 주의해야 한다.
- 변수에 할당된 함수표현식은 끌어 올려지지 않기 때문에 이때는 변수의 스코프 규칙을 그대로 따른다.

함수선언문과 함수표현식에서의 호이스팅

들어가기 전: 함수선언문과 함수표현식의 차이는 다음 POST를 참고하자.

함수선언문에서의 호이스팅

함수선언문은 코드를 구현한 위치와 관계없이 자바스크립트의 특징인 호이스팅에 따라 브라우저가 자바스크립트를 해석할 때 맨 위로 끌어 올려진다.

/* 정상 출력 */
function printName(firstname) { // 함수선언문 
    var result = inner(); // "선언 및 할당"
    console.log(typeof inner); // > "function"
    console.log("name is " + result); // > "name is inner value"

    function inner() { // 함수선언문 
        return "inner value";
    }
}

printName(); // 함수 호출 

/** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 - 위와 동일 --- */
/* 정상 출력 */
function printName(firstname) { 
    var result; // [Hoisting] var 변수 "선언"

    function inner() { // [Hoisting] 함수선언문
        return "inner value";
    }

    result = inner(); // "할당"
    console.log(typeof inner); // > "function"
    console.log("name is " + result); // > "name is inner value"
}

printName(); 

즉, 해당 예제에서는 함수선언문이 아래에 있어도 printName 함수 내에서 inner를 function으로 인식하기 때문에 오류가 발생하지 않는다.

함수표현식에서의 호이스팅

함수표현식은 함수선언문과 달리 선언과 호출 순서에 따라서 정상적으로 함수가 실행되지 않을 수 있다.
- 함수표현식에서는 선언과 할당의 분리가 발생한다.

함수표현식의 선언이 호출보다 위에 있는 경우 - 정상 출력

 /* 정상 */
 function printName(firstname) { // 함수선언문
     var inner = function() { // 함수표현식 
         return "inner value";
     }
        
     var result = inner(); // 함수 "호출"
     console.log("name is " + result);
 }

 printName(); // > "name is inner value"

 /* 정상 */
 /** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 - 위와 동일 --- */
 function printName(firstname) { 
     var inner; // [Hoisting] 함수표현식의 변수값 "선언"
     var result; // [Hoisting] var 변수값 "선언"

     inner = function() { // 함수표현식 "할당"
         return "inner value";
     }
        
     result = inner(); // 함수 "호출"
     console.log("name is " + result);
 }

 printName(); // > "name is inner value"

함수표현식의 선언이 호출보다 아래에 있는 경우 (var 변수에 할당) - TypeError

 /* 오류 */
 function printName(firstname) { // 함수선언문
     console.log(inner); // > "undefined": 선언은 되어 있지만 값이 할당되어있지 않은 경우
     var result = inner(); // ERROR!!
     console.log("name is " + result);

     var inner = function() { // 함수표현식 
         return "inner value";
     }
 }
 printName(); // > TypeError: inner is not a function

 /** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 --- */
 /* 오류 */
 function printName(firstname) { 
     var inner; // [Hoisting] 함수표현식의 변수값 "선언"

     console.log(inner); // > "undefined"
     var result = inner(); // ERROR!!
     console.log("name is " + result);

     inner = function() { 
         return "inner value";
     }
 }
 printName(); // > TypeError: inner is not a function

Q. printName에서 “inner is not defined” 이라고 오류가 나오지 않고, “inner is not a function”이라는 TypeError가 나오는 이유?
A. printName이 실행되는 순간 (Hoisting에 의해) inner는 ‘undefined’으로 지정되기 때문
inner가 undefined라는 것은 즉, 아직은 함수로 인식이 되지 않고 있다는 것을 의미한다.

함수표현식의 선언이 호출보다 아래에 있는 경우 (const/let 변수에 할당) - ReferenceError

 /* 오류 */
 function printName(firstname) { // 함수선언문
     console.log(inner); // ERROR!!
     let result = inner();  
     console.log("name is " + result);

     let inner = function() { // 함수표현식 
         return "inner value";
     }
 }
 printName(); // > ReferenceError: inner is not defined

let/const의 경우, 호이스팅이 일어나지 않기 때문에 위의 예시 그대로 이해하면 된다.
console.log(inner);에서 inner에 대한 선언이 되어있지 않기 때문에 이때는 “inner is not defined” 오류가 발생한다.

함수표현식보다 함수선언문을 더 자주 사용하지만, 어떤 코딩컨벤션에서는 함수표현식을 권장하기도 한다.
- 즉, 어떤 컨벤션을 갖던지 한가지만 정해서 사용하는 게 좋다.

호이스팅 우선순위

같은 이름의 var 변수 선언과 함수 선언에서의 호이스팅

변수 선언이 함수 선언보다 위로 끌어올려진다.

  var myName = "hi";

  function myName() {
      console.log("yuddomack");
  }
  function yourName() {
      console.log("everyone");
  }

  var yourName = "bye";

  console.log(typeof myName);
  console.log(typeof yourName);

  /** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 --- */
  // 1. [Hoisting] 변수값 선언 
  var myName; 
  var yourName; 

  // 2. [Hoisting] 함수선언문
  function myName() {
      console.log("yuddomack");
  }
  function yourName() {
      console.log("everyone");
  }

  // 3. 변수값 할당
  myName = "hi";
  yourName = "bye";

  console.log(typeof myName); // > "string"
  console.log(typeof yourName); // > "string"

값이 할당되어 있지 않은 변수와 값이 할당되어 있는 변수에서의 호이스팅

  var myName = "Heee"; // 값 할당 
  var yourName; // 값 할당 X

  function myName() { // 같은 이름의 함수 선언
      console.log("myName Function");
  }
  function yourName() { // 같은 이름의 함수 선언
      console.log("yourName Function");
  }

  console.log(typeof myName); // > "string"
  console.log(typeof yourName); // > "function"

값이 할당되어 있지 않은 변수의 경우, 함수선언문이 변수를 덮어쓴다.
값이 할당되어 있는 변수의 경우, 변수가 함수선언문을 덮어쓴다.

TIP 호이스팅 사용 시 주의

코드의 가독성과 유지보수를 위해 호이스팅이 일어나지 않도록 한다.
- 호이스팅을 제대로 모르더라도 함수와 변수를 가급적 코드 상단부에서 선언하면, 호이스팅으로 인한 스코프 꼬임 현상은 방지할 수 있다.
- let/const를 사용한다.
var를 쓰면 혼란스럽고 쓸모없는 코드가 생길 수 있다. 그럼 왜 var와 호이스팅을 이해해야 할까?
- ES6를 어디에서든 쓸 수 있으려면 아직 시간이 더 필요하므로 ES5로 트랜스컴파일을 해야한다.
- 따라서 아직은 var가 어떻게 동작하는지 이해하고 있어야 한다.

Reference

https://www.edwith.org/boostcourse-web/lecture/16695/

https://yuddomack.tistory.com/entry/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85Hoisting#recentComments

[JavaScript] 함수선언문과 함수표현식의 차이

Sat, 20 Apr 2019 00:00:00 +0000

Edwith 강의 참고

Goal

자바스크립트의 함수의 개념과 특징에 대해 이해한다.

함수선언문과 함수표현식의 차이를 이해한다.

함수

함수는 여러 개의 인자를 받아서, 그 결과를 출력한다.
파라미터의 개수와 인자의 개수가 일치하지 않아도 오류가 발생하지 않는다.
- 만약, 파라미터 1개가 정의된 함수를 부를 때, 인자의 개수를 0개만 넣어 실행하면 이미 정의된 파라미터(매개변수)는 undefined이라는 값을 갖게 된다.
- 이는 변수는 초기화됐지만, 값이 할당되지 않았기 때문이다.
자바스크립트에서는 함수도 객체이다.
- 따라서 다른 객체와 마찬가지로 넘기거나 할당할 수 있다.
- 함수를 객체 프로퍼티에 할당할 수도 있다.
```
  const o = {}
  o.f = testFunc
  o.f() // test!!
```
- 함수를 객체 배열 요소로 할당할 수도 있다.
```
  const arr = [1, 2, 3]
  arr[1] = testFunc
  arr[1]() // test!!
```

함수 호출 vs 함수 참조

함수 호출
- 함수 식별자 뒤에 괄호를 쓰면 함수 본문(Body)을 실행한다
- 함수를 호출한 표현식은 반환값이 된다.
- testFunc() // test!! (함수 호출)
```
  // 함수의 호출.
  function printName(firstname) {
    var myname = "HEEE";
    return myname + " " +  firstname;
  }
```
함수 참조
- 함수 식별자 뒤에 괄호를 쓰지 않으면 함수는 실행되지 않는다.
- testFunc // function testFunc() // (함수 참조)
- const f = testFunc와 같이 함수를 변수에 할당하면 f()과 같이 다른 이름으로 함수를 호출할 수 있다.

원시값 매개변수 vs 객체 매개변수

함수를 호출하면 함수 매개변수는 변수 자체가 아니라 그 값을 전달받는다.
- 따라서 넘겨받은 원시값 매개변수를 함수 내에서 변경하더라도 밖에서는 변경되지 않는다.
- 하지만 넘겨받은 매개변수가 객체이고, 이 객체 자체를 변경하면 그 객체는 함수 밖에서도 바뀐 점이 반영된다.
원시값과 객체의 차이?
- 원시값은 불변이므로 수정할 수 없다.
- 원시값을 담은 변수는 수정할 수 있지만(다른 값으로 바꿀 수 있지만) 원시값 자체는 바뀌지 않는다.
- 반면 객체는 바뀔 수 있다.

반환값과 undefined

함수는 어떤 타입의 값이라도 반환할 수 있다.
자바스크립트 함수는 반드시 return값이 존재하며, 없을 때는 기본 반환값인 ‘undefined’가 반환된다.
- 자바스크립트에서는 void 타입이 없다.

Ex. 반환값: undefined

function printName(firstname) {
    var myname = "HEEE";
    var result = myname + " " +  firstname;
}

arguments 객체

함수 호출 시에 넘겨진 실제 인자값을 가지는 객체
함수가 실행되면 그 안에는 arguments라는 특별한 지역변수가 자동으로 생성된다.
- arguments의 타입은 객체이다.
자바스크립트 함수는 선언한 파라미터보다 더 많은 인자를 보낼 수도 있다.
- 이때 넘어온 인자를 arguments로 하나씩 접근할 수 있다.
- arguments는 배열의 형태(array-like)를 가지고 있다.

arguments는 배열 타입(array)은 아니다.

따라서 배열의 메서드를 사용할 수 없다.

  function a() {
    console.log(arguments);
  }
  a(1, 2, 3); // { '0':1, '1':2, '2':3 }

자바스크립트의 가변인자를 받아서 처리하는 함수를 만드는 상황에서 arguments 속성을 유용하게 사용할 수 있다.(메서드에 넘겨 받을 인자의 개수를 모를 때)

  function a() {
      if(arguments.length < 3) { // 인자의 개수가 중요한 경우 
          console.log("errer");
          return;
      }
      otherMethod(arguments[1]); // 다른 메서드에 가변인자를 넘겨주는 경우 
  }

arguments 사용 시 주의
- arguments도 남용하면 변경에 약한 코드가 된다.
- arguments를 함부로 수정해서도 안된다. 수정이 된다 하더라도 수정을 해서 해당 값을 바꾸려고 하는 것을 좋지 않다.

함수선언문과 함수표현식의 차이

함수선언문 (Function Declaration)

일반적인 프로그래밍 언어에서의 함수 선언과 비슷한 형식

function 함수명() {
  구현 로직
}

// 함수의 호출.
function printName(firstname) {
  var myname = "HEEE";
  return myname + " " +  firstname;
}

함수표현식 (Function Expression)

변수값에 함수 표현을 담아 놓은 형태
- 유연한 자바스크립트 언어의 특징을 활용한 선언 방식
함수표현식은 익명 함수표현식과 기명 함수표현식으로 나눌 수 있다.
- 일반적으로 함수표현식이라고 부르면 앞에 익명이 생략된 형태라고 볼 수 있다.
- 익명 함수표현식: 함수에 식별자가 주어지지 않는다.
- 기명 함수표현식: 함수의 식별자가 존재한다.
함수표현식의 장점
- 클로져로 사용
- 콜백으로 사용(다른 함수의 인자로 넘길 수 있음)

var test1 = function() { // (익명) 함수표현식
  return '익명 함수표현식';
}

var test2 = function test2() { // 기명 함수표현식 
  return '기명 함수표현식';
}

함수선언문과 함수표현식의 차이

함수선언문은 호이스팅에 영향을 받지만, 함수표현식은 호이스팅에 영향을 받지 않는다.
- 함수선언문은 코드를 구현한 위치와 관계없이 자바스크립트의 특징인 호이스팅에 따라 브라우저가 자바스크립트를 해석할 때 맨 위로 끌어 올려진다.
- 함수표현식은 함수선언문과 달리 선언과 호출 순서에 따라서 정상적으로 함수가 실행되지 않을 수 있다.

함수표현식 Error 예시

/* 정상 */
function printName(firstname) { // 함수선언문
    var inner = function() { // 함수표현식
        return "inner value";
    }

    var result = inner();
    console.log("name is " + result);
}

printName(); // "name is inner value"

/* 오류 */
function printName(firstname) { // 함수선언문
    console.log(inner); // "undefined": 선언은 되어 있지만 값이 할당되어있지 않은 경우
    var result = inner(); // ERROR!!
    console.log("name is " + result);

    var inner = function() { // 함수표현식 
        return "inner value";
    }
}
printName(); // TypeError: inner is not a function

/** --- JS Parser 내부의 호이스팅(Hoisting)의 결과 --- */
/* 오류 */
function printName(firstname) { // 함수선언문
    var inner; // Hoisting - 변수값을 끌어올린다. (선언은 되어 있지만 값이 할당되어있지 않은 경우)
    console.log(inner); // "undefined"
    var result = inner(); // ERROR!!
    console.log("name is " + result);

    inner = function() { // 함수표현식 
        return "inner value";
    }
}
printName(); // TypeError: inner is not a function

Q. “printName이 is not defined” 이라고 오류가 나오지 않고, function이 아니라는 TypeError가 나오는 이유?
A. printName이 실행되는 순간 (Hoisting에 의해) inner는 ‘undefined’으로 지정되기 때문
inner가 undefined라는 것은 즉, 아직은 함수로 인식이 되지 않고 있다는 것을 의미한다.

함수표현식보다 함수선언문을 더 자주 사용하지만, 어떤 코딩컨벤션에서는 함수표현식을 권장하기도 한다.
- 즉, 어떤 컨벤션을 갖던지 한가지만 정해서 사용하는 게 좋다.

Reference

https://www.edwith.org/boostcourse-web/lecture/16695/

https://joshua1988.github.io/web-development/javascript/function-expressions-vs-declarations/

장기효 (캡틴판교) - Vue.js 중급 강좌, 웹앱 제작으로 배워보는 Vue.js, ES6, Vuex

[JavaScript] 자바스크립트의 비교문/분기문/반복문, 문자열

Fri, 19 Apr 2019 00:00:00 +0000

Edwith 강의 참고

Goal

자바스크립트의 비교문/분기문/반복문에 대해 이해한다

자바스크립트의 문자열 처리에 대해 이해한다.

비교문

if, else if, else 문을 통해서 다양한 비교문을 사용할 수 있다.

if(true) console.log(true)
else console.log(false)

// 삼항 연산자
var a = true;
var result = (a) ? "ok" : "not ok";
console.log(result); // ok 

a = "";
var result = (a) ? "ok" : "not ok";
console.log(result); // not ok

분기문

로직을 분기하기 위해서 if 문 이외에도 switch 문을 통해서도 해결할 수 있다.

반복문

for 문이나 while문을 사용해서 반복문을 구현할 수 있다.

function howMany(selectObject) {
  var numberSelected = 0;
  for (var i = 0; i < selectObject.options.length; i++) { // 비효율적 (배열의 길이를 계속 계산)
    if (selectObject.options[i].selected) {
      numberSelected++;
    }
  }
  return numberSelected;
}

배열의 경우 forEach와 같은 메서드도 있고, for-of를 통한 탐색도 자주 사용된다.
- for-in은 객체를 탐색할 때 사용한다.
for 문의 성능 개선
1. 배열의 길이 한 번만 계산
  - for (var i = 0; len = selectObject.options.length; i < len; i++)
2. Reverse Iteration
  - for (var len = selectObject.options.length; i = len; i > len; i--)
  - 시작 포인트를 배열의 길이로 하고, 포인트 값을 감소하면서 반복문을 도는 형태
TIP 반대로 반복문을 동작시키는(reverse iteration) 경우가 실제 브라우저에서 얼마나 성능차이가 있을까?
- 현대의 자바스크립트 엔진은 최적화를 통해 반복문을 최대한 빠르게 처리하는 과정을 거쳐왔기 때문에 실제로 실험을 해보면 그 차이가 미미하다.
- 따라서 for문을 무조건 반대로 구현할 필요는 없다.
- 이런 상황이외에도 자바스크립트의 구현 방법에 따라 (for 가 빠를까 while 빠를까? 등) 성능차이는 그리 크지 않다.
- 따라서 일반적으로는 코드의 가독성에 좀 더 우선 집중하는 게 좋다.

문자열 처리

자바스크립트의 문자와 문자열은 같은 타입으로 모두 문자열이다.

typeof "abc";  // string
typeof "a";    // string
typeof 'a';    // string. single quote도 사용가능.

문자열에 다양한 메서드가 있다.
```
 "ab:cd".split(":"); // ["ab","cd"]
 "ab:cd".replace(":", "$"); // "ab$cd"
 " abcde  ".trim();  // "abcde"
```
- 문자열은 내부적으로 객체로 변환되기 때문에 어떤 객체 내에 있는 메서드를 사용할 수 있는 것이다.
정규표현식으로도 문자열을 처리할 수 있다.

Reference

https://www.edwith.org/boostcourse-web/lecture/16693/

https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#조건문

https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#switch문

https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Loops_and_iteration#for_문

[JavaScript] 자바스크립트의 변수, 연산자, 타입의 종류

Thu, 18 Apr 2019 00:00:00 +0000

Edwith 강의 참고

Goal

자바스크립트의 변수의 종류를 확인한다.

var과 let, const의 차이에 대해 이해한다.

자바스크립트의 연산자의 종류 및 개념을 이해한다.

자바스크립트의 타입의 종류를 확인한다.

자바스크립트에서 type 체크 방법에 대해 이해한다.

자바스크립트에서 null 체크 방법에 대해 이해한다.

자바스크립트의 버전

자바스크립트 버전은 ECMAScript(줄여서 ES, 이크마스크립트)의 버전에 따라서 결정되고, 이를 자바스크립트 실행 엔진이 반영한다.
- 자바스크립트 엔진은 작성한 JS 코드를 한 줄씩 해석하면서 실행을 준비한다.
ES5, ES6(ES2015).. 이런 식으로 버전을 일컫는다.
2018년을 중심으로 ES6를 지원하는 브라우저가 많아서 몇 년간 ES6 문법이 표준으로 쓰이고 있다.
ES6는 ES5문법을 포함하고 있어 하위호환성 문제가 없다.
- 다만 feature별로 지원하지 않는 브라우저가 있을 수 있어 주의해야 한다.
Bable
- 구 버전 브라우저 중에서는 ES6의 기능을 지원하지 않는 브라우저가 있으므로 transpiling이 필요
- ES6의 문법을 각 브라우저의 호환 가능한 ES5로 변환하는 컴파일러
- Babel 온라인 에디터: https://babeljs.io/repl/

변수

변수는 var, let, const로 선언할 수 있다.
어떤 것을 사용하는가에 의해서 scope, 즉 변수의 유효범위가 달라진다.
ES6 이전 버전에서는 var를 사용해서 변수를 선언할 수 있다.
- var로 선언한 변수는 끌어올린다는 뜻의 호이스팅(hoisting) 이라는 매커니즘을 따른다.

var a = 2;
var a = "aaa";
var a = 'aaa';
var a = true;
var a = [];
var a = {};
var a = undefined;

변수의 Scope

{}에 상관없이 스코프가 설정된다.

var sum = 0;
for(var i = 1; i <= 5; i++) {
    sum = sum + i;
}
console.log(sum); // 15
console.log(i); // 6

ES6 새로운 변수 선언 방식 - const, let

블록 단위 {}로 변수의 범위가 제한되었다.

let sum = 0;
for (let i=1; i<=5; i++) {
    sum = sum + i;
}
console.log(sum); // 10
console.log(i); // Uncaught ReferenceError: i is not defined

const: 한번 선언한 값에 대해서 변경할 수 없다.(상수 개념)

/* 예시 */
const a = 10;
a = 20; // Uncaught TypeError: Assignment to constant variable

/* [주의!] 하지만, 객체나 배열의 내부는 변경할 수 있다. */
const a = {};
a.num = 10;
console.log(a); // {num: 10}

const b = [];
b.push(20);
console.log(b); // [20]

let: 한번 선언한 값에 대해서 다시 선언할 수 없다. 변경은 가능
- 메모리에 할당하면 다시 할당하지 못함

간단한 scope 예시

function f() {
    {
      let x;
      {
          // 새로운 블록 안에 새로운 x의 스코프가 생김
          const x = "sneaky";
          x = "foo"; // 위에 이미 const로 x를 선언했으므로 다시 값을 대입하면 Error
      }
      // 이전 블록 범위로 돌아왔기 때문에 'let x'에 해당하는 메모리에 값을 대입
      x = "bar";
      let x = "inner"; // SyntaxError: Identifier 'x' has already been declared
    }
}

연산자

연산자 우선순위를 표현하기 위해서는 ()를 사용하면 된다.
수학 연산자, 논리 연산자, 관계 연산자, 삼항 연산자 등이 있다.

수학 연산자

+, -, *, /, %(나머지) 등이 있다.

논리 연산자

&& 연산자
- 모든 값이 true인지 확인하지만, 첫 번째가 이미 false라면 그 이후의 값은 확인하지 않는다.
- 모든 값이 true인 경우 마지막 값이 할당된다.
|| 연산자
- 첫 번째가 true인 경우 그 이후의 값은 확인하지 않고 첫 번째 값이 할당된다.

// or 연산자 활용
const name = "myname";
const result = name || "default";
console.log(result); // myname 
const result2 = name && "test";
console.log(result2); // test (&&의 경우, 뒤의 값이 할당된다.)

var name = "";
var result = name || "default";
console.log(result); // default 

삼항 연산자

간단한 비교와 값 할당은 삼항연산자를 사용할 수 있다.

const data = 11;
const result = (data > 10) ? "ok" : "fail";
console.log(result); // ok 

비교 연산자

비교는 == 보다는 === 를 사용한다.
- === 의 경우는 Type까지 확인하는 연산자이다.
- == 의 경우 임의적으로 Type을 바꿔서 비교하기 때문에 원하는 결과와 다른 값이 나올 수 있다.

== 로 인한 다양한 오류 상황 예시

0 == false; // true
"" == false; // true 
null == false; // false (null은 객체)
undefined == false; // false 
0 == "0"; // true
null == undefined; // true 

TIP 자바스크립트의 null 체크에서의 ! 사용 시 주의

0, null, undefined, “”, {}, []

var target;

target = 0;
console.log(!target); // true
target = null;
console.log(!target); // true
target = undefined;
console.log(!target); // true
target = "";
console.log(!target); // true
target = {};
console.log(!target); // false
target = [];
console.log(!target); // false 

자바스크립트의 타입

undefined, null, boolean, number, string, object, function, array, Date, RegExp 등

기본형과 참조형의 종류

Primitive
- Number
- String
- Boolean
- null
- undefined
Reference: 기본형 데이터의 집합이라고 할 수 있다.
- Object
  - Array
  - Function
  - RegExp

기본형과 참조형의 차이점

기본형: 값을 그대로 할당
참조형: 값이 저장된 주소값을 할당(참조)

자바스크립트 Type 체크

컴파일 단계가 없는 JavaScript의 Type은 선언할 때가 아니고, 실행 타임 (Dynamic Type)에 결정된다.
- 함수 안에서의 파라미터나 변수는 실행될 때 그 타입이 결정된다.
타입을 체크하는 또렷한 방법은 없다.
- 정확하게는 toString.call() 함수를 이용해서 그 결과를 매칭하곤 하는데, 문자, 숫자와 같은 자바스크립트 기본 타입은 typeof 키워드를 사용해서 체크할 수 있습니다.
- 배열은 타입을 체크하는 isArray함수가 표준으로 생겼다. (IE와 같은 구 브라우저를 사용해야 한다면 지원범위를 살펴보고 사용)

예시

toString.call("test"); // "[object String]"
  
const target = "test";
typeof target; // "string"

[Network] HTTP의 동작 및 HTTP Message 형식

Wed, 17 Apr 2019 00:00:00 +0000

Edwith 강의 참고

Goal

Internet이란

IP 주소와 Port 번호의 개념을 이해한다.

HTTP란

HTTP의 기본 특징 및 동작에 대해 이해한다.

HTTP와 HTTPS의 차이에 대해 이해한다.

HTTP Message

HTTP Request 형식

HTTP Response 형식

URI와 URL의 차이에 대해 이해한다.

인터넷(네트워크 통신)의 이해

인터넷 (Internet)이란

TCP/IP 기반의 네트워크가 전세계적으로 확대되어 하나의 연결된 네트워크들의 네트워크 (네트워크의 결합체)
인터넷 != WWW(World Wide Web)
- 인터넷 기반의 대표 서비스 중 하나가 www라고 할 수 있다.
인터넷 기반의 서비스들

이름	프로토콜	포트	기능
www	HTTP	80	웹 서비스
Email	SMTP/POP3/IMAP	25/110/114	이메일 서비스
FTP	FTP	21	파일 전송 서비스
DNS	TCP/UDP	53	네임 서비스
NEWS	NNTP	119	인터넷 뉴스 서비스

물리적인 하나의 컴퓨터(IP 주소)에는 여러 개의 서버가 동작할 수 있다.
- 각각의 서버들은 Port라는 값으로 구분돼서 동작한다.
TIP IP 주소와 Port 번호의 개념
- IP 주소 또는 도메인 이름
  - 하드웨어 서버(물리적인 컴퓨터)를 찾기 위해 반드시 필요한 정보
  - Ex) 집 주소
- Port 번호
  - 해당 물리적인 컴퓨터 안에 존재하는 소프트웨어 서버를 찾기 위한 정보
  - 하나의 물리적인 컴퓨터에는 여러 개의 소프트웨어 프로그램이 각각의 Socket을 사용하여 데이터 통신을 하고 있기 때문에 각각의 Socket을 구분할 필요가 있다. Port 번호를 통해 각 Socket을 구분할 수 있다.
  - 0보다 큰 숫자로 구성되어 있다.
  - Ex) 집 안의 여러 방 번호

웹의 동작 (HTTP 프로토콜의 이해)

HTTP (Hypertext Transfer Protocol)란

웹 브라우저와 웹 서버 간의 서로 통신하기 위한 규약
- 즉, HTTP(Hypertext Transfer Protocol)란 서버와 클라이언트가 인터넷상에서 데이터를 주고받기 위한 프로토콜(protocol)을 말한다.
- HTTP는 계속 발전하여 HTTP/2까지 버전이 등장한 상태
- 팀 버너스리(Tim Berners-Lee)와 그가 속한 팀은 CERN에서 HTML뿐만 아니라 웹 브라우저 및 웹 브라우저 관련 기술과 HTTP를 발명하였다.
- 어떤 종류의 데이터도 전송할 수 있도록 설계되어있다.
TIP HTTP와 HTTPS의 차이
- HTTP 프로토콜
  - 웹상에서 클라이언트와 서버 간에 요청/응답으로 정보를 주고 받을 수 있는 프로토콜
- HTTPS 프로토콜
  - 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전
  - HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다.
  - 따라서 데이터의 적절한 보호를 보장한다.
  - HTTPS의 기본 TCP/IP포트는 443이다.

HTTP 통신 과정

HTTP는 서버/클라이언트 모델을 따른다.
- 클라이언트 -> 요청 -> 서버 -> 응답 -> 클라이언트
- 특징
  - 비연결 지향(Connectionless)
    - 클라이언트가 request를 서버에 보내고, 서버가 클라이언트에 요청에 맞는 response를 보내면 바로 연결을 끊는다.
  - 무상태(Stateless)
    - 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다.
- 장점
  - 불특정 다수를 대상으로 하는 서비스에는 적합하다.
  - 클라이언트와 서버가 계속 연결된 형태가 아니기 때문에 클라이언트와 서버 간의 최대 연결 수보다 훨씬 많은 요청과 응답을 처리할 수 있다.
- 단점
  - 연결을 끊어버리기 때문에, 클라이언트의 이전 상황을 알 수가 없다.
  - 이러한 특징을 무상태(Stateless)라고 말한다.
  - 이러한 특징 때문에 정보를 유지하기 위해서 Cookie와 같은 기술이 등장하게 되었다.
- 클라이언트가 원하는 서버에 접속
- 클라이언트가 서버에 요청
- 요청에 따른 응답 결과를 다시 클라이언트에 응답
- 응답이 끝나고 나면 서버와 클라이언트의 연결은 끊긴다.

HTTP 메시지 형식

HTTP 요청 메시지 형식

HTTP Request Message = Request Header + 빈 줄 + Request Body

Header
- 첫 번째 줄 (start-line)
  - 요청 메서드 + 요청 URI + HTTP 프로토콜 버전
  - GET /background.png HTTP/1.0
  - POST / HTTP 1.1
- 두 번째 줄 ~ (http headers)
  - Header 정보들 (‘Header Name: Header Value’ 형태)
  - 각 줄은 Line Feed(LF)와 Carriage Return(CR)으로 구분된다.
빈 줄 (empty-line)
- 요청에 대한 모든 메타 정보가 전송되었음을 알린다.
Body
- POST, PUT의 경우에만 존재
- 요청과 관련된 내용 (HTML 폼 콘텐츠 등)
Ex

HTTP 응답 메시지 형식

HTTP Response Message = Response Header + 빈 줄 + Response Body

Header
- 첫 번째 줄 (status-line)
  - HTTP 프로토콜 버전 + 응답 코드 + 응답 메시지
  - HTTP/1.1 404 Not Found.
- 두 번째 줄 ~ (http headers)
  - Header 정보들 (‘Header Name: Header Value’ 형태)
    - 날짜, 웹서버 이름, 웹서버 버전, 콘텐츠 타입, 콘텐츠 길이, 캐시 제어 방식 등
  - 각 줄은 Line Feed(LF)와 Carriage Return(CR)으로 구분된다.
빈 줄 (empty-line)
- 요청에 대한 모든 메타 정보가 전송되었음을 알린다.
Body
- 실제 응답 리소스 데이터
- 201, 204와 같은 상태 코드를 가진 응답에는 보통 body가 존재하지 않는다.
Ex

HTTP 기본 속성 개념

요청 메서드
- 서버에게 요청의 종류를 알려주기 위해 사용
- 최초의 웹 서버는 GET 방식만 지원
- 각 메서드의 사용 목적
  - GET: 정보 요청 (SELECT)
  - POST: 정보 밀어넣기 (INSERT)
  - PUT: 정보 업데이트 (UPDATE)
  - DELETE: 정보 삭제 (DELETE)
  - HEAD: (HTTP) 헤더 정보만 요청하는 메서드. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인
  - OPTIONS: 웹 서버가 지원하는 메서드의 종류를 요청
  - TRACE: 클라이언트의 요청을 그대로 반환하는 메서드. Ex) echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용
요청 URI
- 요청하는 자원의 위치를 명시
HTTP 프로토콜 버전
- 웹 브라우저가 사용하는 프로토콜 버전
응답 상태 코드
- 요청의 성공 여부 (200, 404 혹은 302)
응답 메시지
- 상태 코드에 대한 이해를 돕기 위해 짧고 간결하게 상태 코드에 대한 설명을 글로 나타낸 것

URL (Uniform Resource Locator)란

URL이란
- 인터넷 상의 자원의 위치
- 특정 웹 서버의 특정 파일에 접근하기 위한 경로 혹은 주소
URL의 표현
- 접근 프로토콜 :// IP 주소 또는 도메인 이름 (:포트번호) / 자원의 경로 / 자원의 이름
- Ex) http://www.example.co.kr/test/index.html
- Ex) http://localhost:8080
TIP URI와 URL의 차이
- URI (Uniform Resource Identifier)
  - 요청하는 자원의 식별자 (규약)
  - 자원을 고유하게 식별하고 위치를 지정할 수 있다.
  - URI의 하위 개념으로 URL이 포함된다. 즉, URI > URL
- URL (Uniform Resource Locator)
  - 특정 웹 서버의 특정 자원에 대한 구체적인 위치 (규약의 형태)
  - 자원의 정확한 위치와 접근하기 위한 방법을 알려준다.
- Ex) URL 이면서 URI인 경우
  - https://gmlwjd9405.github.io/tags.html
  - 자원의 고유한 식별자이면서 구체적인 위치를 명시한 형태
- Ex) URL이 아니면서 URI인 경우
  - https://gmlwjd9405.github.io/posts/132
  - https://gmlwjd9405.github.io/list?page=2
    - URL: https://gmlwjd9405.github.io/list
    - URI: URL + ?page=2
  - 자원에 접근할 수 있는 위치는 https://gmlwjd9405.github.io/list이며, 이를 URL이라고 할 수 있다.
  - 하지만 원하는 자원을 얻기 위해서는 추가적인 식별자인 page=2가 필요하고 이를 포함한 내용까지가 URI라고 할 수 있다.

Reference

https://mygumi.tistory.com/139

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

https://joshua1988.github.io/web-development/web-protocols/

[DB] ORM이란

Fri, 01 Feb 2019 00:00:00 +0000

Goal

영속성(Persistence)이란

ORM(Object Relational Mapping)이란

ORM의 장단점

The Object-Relational Impedance Mismatch

Association(연관성)

One-To-One Relationship

One-To-Many Relationship

영속성(Persistence)

데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성을 말한다.
영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 된다.
Object Persistence(영구적인 객체)
- 메모리 상의 데이터를 파일 시스템, 관계형 테이터베이스 혹은 객체 데이터베이스 등을 활용하여 영구적으로 저장하여 영속성 부여한다.
- 데이터를 데이터베이스에 저장하는 3가지 방법
  - 1) JDBC (java에서 사용)
  - 2) Spring JDBC (Ex. JdbcTemplate)
  - 3) Persistence Framework (Ex. Hibernate, Mybatis 등)
Persistence Layer
- 프로그램의 아키텍처에서, 데이터에 영속성을 부여해주는 계층을 말한다.
- JDBC를 이용하여 직접 구현할 수 있지만 Persistence framework를 이용한 개발이 많이 이루어진다.
Persistence Framework
- JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터베이스와 연동되는 시스템을 빠르게 개발할 수 있으며 안정적인 구동을 보장한다.
- Persistence Framework는 SQL Mapper와 ORM으로 나눌 수 있다.
  - Ex) JPA, Hibernate, Mybatis 등

ORM이란

Object Relational Mapping, 객체-관계 매핑

객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 것을 말한다.
- 객체 지향 프로그래밍은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용한다.
- 객체 모델과 관계형 모델 간에 불일치가 존재한다.
- ORM을 통해 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하여 불일치를 해결한다.
데이터베이스 데이터 <—매핑—> Object 필드
- 객체를 통해 간접적으로 데이터베이스 데이터를 다룬다.
Persistant API라고도 할 수 있다.
- Ex) JPA, Hibernate 등

ORM의 장단점

장점
- 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 도와준다.
  - ORM을 이용하면 SQL Query가 아닌 직관적인 코드(메서드)로 데이터를 조작할 수 있어 개발자가 객체 모델로 프로그래밍하는 데 집중할 수 있도록 도와준다.
  - 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어든다.
  - 각종 객체에 대한 코드를 별도로 작성하기 때문에 코드의 가독성을 올려준다.
  - SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적인 접근으로 인해 생산성이 증가한다.
- 재사용 및 유지보수의 편리성이 증가한다.
  - ORM은 독립적으로 작성되어있고, 해당 객체들을 재활용 할 수 있다.
  - 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리하다.
  - 매핑정보가 명확하여, ERD를 보는 것에 대한 의존도를 낮출 수 있다.
- DBMS에 대한 종속성이 줄어든다.
  - 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하기 때문에 RDBMS의 데이터 구조와 Java의 객체지향 모델 사이의 간격을 좁힐 수 있다.
  - 대부분 ORM 솔루션은 DB에 종속적이지 않다.
  - 종속적이지 않다는것은 구현 방법 뿐만아니라 많은 솔루션에서 자료형 타입까지 유효하다.
  - 프로그래머는 Object에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요된다.
  - 또한 자바에서 가공할경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능하다.
단점
- 완벽한 ORM 으로만 서비스를 구현하기가 어렵다.
  - 사용하기는 편하지만 설계는 매우 신중하게 해야한다.
  - 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있다.
  - 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있다.
  - 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있다.
  - DBMS의 고유 기능을 이용하기 어렵다. (하지만 이건 단점으로만 볼 수 없다 : 특정 DBMS의 고유기능을 이용하면 이식성이 저하된다.)
- 프로시저가 많은 시스템에선 ORM의 객체 지향적인 장점을 활용하기 어렵다.
  - 이미 프로시저가 많은 시스템에선 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생할 수 있다.

The Object-Relational Impedance Mismatch

Granularity(세분성)
- 경우에 따라 데이터베이스에 있는 해당 테이블 수보다 더 많은 클래스를 가진 객체 모델을 가질 수 있다.
- 예를 들어, “사용자 세부 사항”에 대해 생각해보자.
  - 코드 재사용과 유지보수를 위해 “Person”과 “Address”라는 두 개의 클래스로 나눌 수 있다.
  - 그러나 데이터베이스에는 person이라는 하나의 테이블에 “사용자 세부 사항”을 저장할 수 있다.
  - 이렇게 Object 2개와 Table 1개로 두 개의 갯수가 다를 수 있다.
- 1) Coarse Granularity(굵은/거친): PersonDetails Class
- 2) Fine Granularity(가는/세밀한): Persion Class, Address Class
Inheritance(상속)
- RDBMS는 객체지향 프로그래밍 언어의 자연적 패러다임인 상속과 유사한 것을 정의하지 않는다.
- 즉, 상속의 개념이 없다.
Identity(일치)
- RDBMS는 ‘sameness’라는 하나의 개념을 정확히 정의하는데, 바로 ‘기본키(primary key)’이다.
- 그러나 자바에서는 객체 식별(a==b)과 객체 동일성(a.equales(b))을 모두 정의한다.
- RDBMS에서는 PK가 같으면 서로 동일한 record로 정의하지만, Java에서는 주솟값이 같거나 내용이 같은 경우를 구분하여 정의한다.
Associations(연관성)
- 객체지향 언어는 객체 참조(reference)를 사용하는 연관성을 나타내는 반면, RDBMS는 연관성을 ‘외래키(foreign key)’로 나타낸다.
- 아래 참고
Navigation(탐색/순회)
- Java 및 RDBMS에서 객체에 액세스하는 방법은 근본적으로 다르다.
- Java에서는 하나의 연결에서 다른 연결로 이동하면서 탐색/순회한다. (그래프 형태)
  - 예를 들어, aUser.getBillingDetails().getAccountNumber()
  - 이는 RDBMS에서 데이터를 검색하는 효율적인 방법이 아니다.
- RDBMS에서는 일반적으로 SQL 쿼리 수를 최소화하고 JOIN을 통해 여러 엔터티를 로드하고 원하는 대상 엔터티를 선택(select)한다.

Association(연관성)

Java에서의 객체 참조(Object References)

방향성이 있다. (Directional)

  public class Employee { 
      private int id; 
      private String first_name; 
      …
      private Department department; // Employee -> Department
      …
  }

Java에서 양방향 관계가 필요한 경우 연관을 두 번 정의해야 한다.
- 즉, 서로 Reference를 가지고 있어야 한다.

RDBMS의 외래키(Foreign Key)
- FK와 테이블 Join은 관계형 데이터베이스 연결을 자연스럽게 만든다.
- 방향성이 없다. (Direction-Less)
```
  INSERT INTO 
  EMPLOYEE(id, first_name, … ,department_id) // FK
  VALUES …
```

One-To-One Relationship

예를 들어, 각 학생은 고유한 주소를 가지고 있다고 하자.
RDBMS (방향성이 없다.)
- 각 Student의 record는 서로 다른 Address record를 가리키고 이것은 일대일 매핑을 보여준다.

Java Object (방향성이 있다.)

public class Student {
 private long studentId;
 private String studentName;
 private Address studentAddress; // Student -> Address
 …
}
public class Address {
 private long addressId;
 private String street;
 private String city;
 private String state;
 private String zipcode;
 …
}

One-To-Many Relationship
- 예를 들어, 각 학생은 여러 개의 핸드폰을 가질 수 있다고 하자.
- RDBMS (방향성이 없다.)
  - 각 Student의 record는 여러 개의 Phone record를 가리킬 수 있다. (일대다 매핑)
  - 이 관계를 하나의 다른 Table(Relational Model)로 만들 수 있다.
  - One-To-Many를 구성하는 방법: 1) Join Table, 2) Join Column
- Java Object (방향성이 있다.)
```
public class Student {
 private long studentId;
 private String studentName;
 private Set<Phone> studentPhoneNumbers; // Student -> Some Phones
 …
}
public class Phone {
 private long phoneId;
 private String phoneType;
 private String phoneNumber;
 …
}
```

References

ORM의 장단점

[Network] HTTP 헤더의 종류 및 항목

Mon, 28 Jan 2019 00:00:00 +0000

Goal

HTTP 헤더 내 일반 헤더 (General Header) 항목을 이해한다.

HTTP 헤더 내 엔터티/개체 헤더 (Entity Header) 항목

HTTP 헤더 내 요청 헤더 (Request Header) 항목

HTTP 헤더 내 응답 헤더 (Response Header) 항목

HTTP 헤더 내 캐시/쿠키와 관련된 항목을 이해한다.

HTTP 공통 헤더

HTTP 헤더 내 일반 헤더 (General Header) 항목

요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의(기본적인) 헤더 항목

주요 항목들

Date
- HTTP 메시지를 생성한 일시 (RFC 1123에서 규정)
- Date: Sat, 2 Oct 2018 02:00:12 GMT
Connection
- 클라이언트와 서버 간 연결에 대한 옵션 설정(다소 모호한 복잡성 있음)
- Ex) Connection: close
  - 현재 HTTP 메시지 직후에 TCP 접속을 끊는다는 것을 알린다.
- Ex) Connection: Keep-Alive
  - 현재 TCP 커넥션을 유지한다.
Cache-Control
- (쿠키/캐시 관련)
Pragma
Trailer

HTTP 엔티티 관련 헤더

HTTP 헤더 내 엔터티/개체 헤더 (Entity Header) 항목

요청 및 응답 메시지 모두에서 사용 가능한 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명 헤더 항목
- HTTP 메시지 내 포함된 선택적인 개체에 대한 구체적인 미디어 타입 등의 설명
- HTTP 메시지는 이미지, 비디오, 오디오, HTML 문서, 전자메일 등의 개체들을 운반할 수 있다.

주요 항목들

Content-Type
- 해당 개체에 포함되는 미디어 타입 정보
- 컨텐츠의 타입(MIME 미디어 타입) 및 문자 인코딩 방식(EUC-KR,UTF-8 등)을 지정한다.
- 타입 및 서브타입(type/subtype)으로 구성된다.
  - 타입(type): 10개 정도 표준으로 지정됨(application, audio, font, image, multipart 등)
  - 서브타입(subtype): 각 타입별로 수십에서 수백개 정도
- Ex) Content-Type: text/html; charset-latin-1
  - 해당 개체가 html 텍스트 문서이고, iso-latin-1 문자 인코딩 방식으로 표현되는 것을 의미한다.
- (공통 헤더)
Content-Language
- 해당 개체와 가장 잘 어울리는 사용자 언어(자연언어)
- (공통 헤더)
Content-Encoding
- 해당 개체 데이터의 압축 방식
- Ex) Content-Encoding: gzip, deflate
- 만일 압축이 시행되었다면 Content-Encoding 및 Content-Length 2개 항목을 토대로 압축 해제가 가능하다.
- (공통 헤더)
Content-Length
- 전달되는 해당 개체의 바이트 길이 또는 크기(10진수)
- 응답 메시지 Body의 길이를 지정하거나 특정 지정된 개체의 길이를 지정한다.
- (공통 헤더)
Content-Location
- 해당 개체의 실제 위치를 알려준다.
- (공통 헤더)
Content-Disposition
- 응답 Body를 브라우저가 어떻게 표시해야할지 알려준다.
- inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드한다.
  - Ex) Content-Disposition: inline
  - Ex) Content-Disposition: attachment; filename='filename.csv'
- 다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다.
- 파일용 서버인 경우 이 태그를 자주 사용한다.
- (응답 헤더)
Content-Security-Policy
- 다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 명시한다.
- XSS 공격에 대한 방어 가능 (허용한 외부 소스만 지정 가능)
- Ex) Content-Security-Policy: default-src https:
  - https를 통해서만 파일을 가져온다.
- Ex) Content-Security-Policy: default-src 'self'
  - 자신의 도메인의 파일들만 가져온다.
- Ex) Content-Security-Policy: default-src 'none'
  - 파일을 가져올 수 없다.
- (응답 헤더)
Location
- 리소스가 리다이렉트(redirect)된 때에 이동된 주소, 또는 새로 생성된 리소스 주소를 명시한다.
- 300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려준다.
  - 새로 생성된 리소스의 경우
    - HTTP 상태 코드 201 Created가 반환된다.
  - 300번대 응답의 경우
    - HTTP/1.1 302 Found Location: /
    - 이런 응답이 왔다면 브라우저는 / 주소로 redirect한다.
- (응답 헤더)
Last-Modified
- 리소스를 마지막으로 갱신한 일시
- (응답 헤더)
Transfer-Encoding
- chuncked
- 동적으로 생성되어 Body의 길이를 모르는 경우에 조금씩 전송이 가능하다.
- 각 chunk 마다 그 시작에 16진수 길이를 삽입하여 chunk 길이를 알려준다.
- (응답 헤더)

HTTP 요청 헤더

HTTP 헤더 내 요청 헤더 (Request Header) 항목

요청 헤더는 HTTP 요청 메시지 내에서만 나타나며 가장 방대하다.

주요 항목들

Host
- 요청하는 호스트에 대한 호스트명 및 포트번호 (필수)
  - HTTP/1.1 이후부터 Host 필드는 필수 항목이다. (웹브라우저는 이를 반드시 포함해야 함)
- Host 필드에 도메인명 및 호스트명 모두를 포함한 전체 URI(FQDN) 지정이 필요하다.
- 이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트를 구축할 수 있다.
User-Agent
- 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보
From
- 클라이언트 사용자 메일 주소
  - 주로 검색엔진 웹 로봇의 연락처 메일 주소를 나타낸다.
  - 때로는, 이 연락처 메일 주소를 User-Agent 항목에 두는 경우도 있다.
Cookie
- 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
- (쿠키/캐시 관련)
Referer
- 바로 직전에 머물었던 웹 링크 주소
If-Modified-Since
- 제시한 일시 이후로만 변경된 리소스를 취득 요청
Authorization
- 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더
- “토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자”를 전송
Origin
- 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타낸다.
- 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
- 응답 헤더의 Access-Control-Allow-Origin와 관련
다음 4개는 주로 HTTP 메세지 Body의 속성 또는 내용 협상용 항목들
- Accept
  - 클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알린다.
    - 텍스트(text/html,text/plain,…),이미지(image/jpeg,…) 등
  - Ex) Accept: */*
    - 어떤 미디어 타입도 가능하다.
  - Ex) Accept: image/*
    - 모든 이미지 유형이 가능하다.
- Accept-Charset
  - 클라이언트 자신이 원하는 문자 집합
- Accept-Encoding
  - 클라이언트 자신이 원하는 문자 인코딩 방식
- Accept-Language
  - 클라이언트 자신이 원하는 가능한 언어
- 각각이 HTTP Entity Header 항목 중에 Content-Type, Content-Type charset-xxx, Content-Encoding, Content-Language과 일대일로 대응된다.

예시

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0

POST /myform.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Content-Length: 128

HTTP 응답 헤더

HTTP 헤더 내 응답 헤더 (Response Header) 항목

특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때, 이에 응답한다.

주요 항목들

Server
- 서버 소프트웨어 정보
Accept-Range
Set-Cookie
- 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)
- (쿠키/캐시 관련)
Expires
- 리소스가 지정된 일시까지 캐시로써 유효함을 나타낸다. 즉, 응답 컨텐츠가 언제 만료되는지를 나타낸다.
- Ex) Expires: Thu, 26 Jul 2018 07:28:00 GMT
- Cache-Control과 별개로 응답에 Expires라는 헤더를 줄 수 있다.
  - 단, Cache-Control의 max-age가 있는 경우 이 헤더는 무시
- (쿠키/캐시 관련)
Age
- 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 초 단위로 알려준다.
- (쿠키/캐시 관련)
ETag
- HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
- (쿠키/캐시 관련)
Proxy-authenticate
Allow
- 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타낸다.
- 때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목으로 사용된다.
  - OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의
- Ex) Allow: GET,HEAD
  - 405 Method Not Allowed 에러와 함께
  - 웹 서버에서 제공 가능한 HTTP 메서드는 GET, HEAD 뿐임을 알린다.
Access-Control-Allow-Origin
- 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
  - 서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
- Ex) Access-Control-Allow-Origin: www.zerocho.com
  - 프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
- Ex) Access-Control-Allow-Origin: *
  - 만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
- 유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.
- Request와 Allow에서 Method 단수 복수 주의

예시

200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Mon, 18 Jul 2016 16:06:00 GMT
Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"
Keep-Alive: timeout=5, max=997
Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT
Server: Apache
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
X-Backend-Server: developer2.webapp.scl3.mozilla.com
X-Cache-Info: not cacheable; meta data too large
X-kuma-revision: 1085259
x-frame-options: DENY

참고 CORS(Cross-Origin Resource Sharing)란?

배경
- 처음 전송되는 리소스의 도메인과 다른 도메인으로부터 리소스가 요청될 경우 해당 리소스는 cross-origin HTTP 요청에 의해 요청된다.
- 보안 상의 이유로, 브라우저들은 스크립트 내에서 초기화되는 cross-origin HTTP 요청을 제한한다.
  - 예를 들면, XMLHttpRequest는 same-origin 정책을 따르기에 XMLHttpRequest을 사용하는 웹 애플리케이션은 자신과 동일한 도메인으로 HTTP 요청을 보내는 것만 가능했다.
  - 웹 애플리케이션을 개선시키기 위해, 개발자들은 브라우저 벤더사들에게 XMLHttpRequest가 cross-domain 요청을 할 수 있도록 요청했고 이에 따라 CORS가 생겼다.
개념
- 웹 서버에게 보안 cross-domain 데이터 전송을 활성화하는 cross-domain 접근 제어권을 부여한다.
과정
- CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다.
- 이때 Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고,
- Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다.
- Allow 항목들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다.
- Request랑 Allow가 일치하면 CORS 요청이 이루어진다.

HTTP 캐시/쿠키 관련 헤더

Caching 관련

Cache-Control
- Ex) Cache-Control: no-store
  - 아무것도 캐싱하지 않는다.
- Ex) Cache-Control: no-cache
  - 모든 캐시를 쓰기 전에 서버에 해당 캐시를 사용해도 되는지 확인한다.
- Ex) Cache-Control: must-revalidate
  - 만료된 캐시만 서버에 확인을 받도록 한다.
- Ex) Cache-Control: public
  - 공유 캐시(또는 중개 서버)에 저장해도 된다는 것을 의미한다.
- Ex) Cache-Control: private
  - 브라우저같은 특정 사용자 환경에만 저장한다.
- Ex) Cache-Control: max-age
  - 캐시 유효시간을 명시한다.
- 주로 응답 헤더로 사용하지만, “클라이언트 - 중개 서버 - 서버”의 구조에서 중개 서버의 캐시를 가져오지 않도록 하려면 클라이언트에서 요청 헤더에 이 헤더를 추가한다.
- (공통 헤더)
Expires
- 리소스가 지정된 일시까지 캐시로써 유효함을 나타낸다. 즉, 응답 컨텐츠가 언제 만료되는지를 나타낸다.
- Ex) Expires: Thu, 26 Jul 2018 07:28:00 GMT
- Cache-Control과 별개로 응답에 Expires라는 헤더를 줄 수 있다.
  - 단, Cache-Control의 max-age가 있는 경우 이 헤더는 무시
- (응답 헤더)
Age
- 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 초 단위로 알려준다.
- Ex) max-age= 3600을 설정한 경우, 1분 후 Age: 60이 캐시 응답 헤더에 포함된다.
- (응답 헤더)
ETag
- HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
- 같은 주소의 자원이더라도 컨텐츠가 달라졌다면 ETag가 다르다.
- 같은 주소로 GET 메서드 수행 시 응답 Body의 내용이 동일하면 같은 ETag를 갖지만, 내용이 바뀌었다면 ETag 헤더 값이 변경된다.
- 이 헤더 값이 변경되었다면 캐시를 지우고 새로 변경된 컨텐츠를 받는다.
- (응답 헤더)
If-None-Match
- 서버에 ETag가 달라졌는지 검사를 요청한다.
- ETag가 다를 경우에만 컨텐츠를 새로 받는다.
- 만약 ETag가 같다면 서버는 304 Not Modified를 응답해서 캐시를 그대로 사용한다.
- (요청 헤더)

Cookies 관련

Cookie
- 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
- Ex) Cookie: attribute1=value1; attribute2=value2;
- 서버는 이 쿠키 헤더를 파싱해서 사용한다.
- CSRF 공격 같은 것을 막기 위해서 반드시 서버는 쿠키가 제대로 된 상황에서 온 것인지 확인하는 로직이 필요하다.
- (요청 헤더)
Set-Cookie
- 서버측에서 클라이언트에게 세션 쿠키 정보를 설정할 때 사용하는 항목 (RFC 2965에서 규정)
- Ex) Set-Cookie: 속성이름(attribute)=속성값(value); 옵션들 형태로 다수 정보들이 설정됨
- 옵션들
  - Expires
    - 쿠키 만료 날짜 설정
  - Max-Age
    - 쿠키 수명 설정. Expires는 무시
  - Secure
    - https에서만 쿠키가 전송된다.
  - HttpOnly
    - 자바스크립트에서 쿠키에 접근할 수 없다.
    - XSS 요청을 막으려면 활성화해두는 것이 좋다.
  - Domain
    - 도메인을 적어주면 도메인이 일치하는 요청에서만 쿠키가 전송된다.
    - 가끔 도메인이 다른 쿠키들이 있는데, 이런 쿠키들은 써드 파티 쿠키로 클라이언트를 추적하고 있는 쿠키이다.
  - Path
    - 해당 path와 일치하는 요청에서만 쿠키가 전송된다.
- Ex) Set-Cookie: zerocho=babo; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
  - 쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에 HttpOnly 옵션을 켜두고, 쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 마련해두는 것이 좋다.
- (응답 헤더)

참고 캐시, 쿠키, 세션의 차이

캐시 (Cache)
- 개념
  - CPU와 주기억장치 사이에 물리적으로 존재하는 버퍼 형태의 고속의 기억장치를 말한다. (통상, 컴퓨터 메모리 버퍼를 지칭)
- 사용 목적
  - CPU와 주기억장치 사이의 속도의 차이를 완화 (메모리 읽기 속도 개선용)
쿠키 (Cookie)
- 개념
  - 인터넷 웹 상에서 상태정보를 클라이언트측(인터넷 웹브라우저)에 저장하여, 서버측에서 필요할 때마다 지속성있게 활용하고자 할 때 사용한다. (클라이언트 로컬에 저장되는 키와 값이 들어있는 파일)
- 사용 목적
  - HTTP의 비연결(Connectionless)과 무상태(Stateless)을 보완
  - 웹 브라우저에 서버측에 있는 상태값들을 저장할 수 있게하도록 하여 사용자에 대한 지속적인 상태감시 및 상태참조를 한다.
- 쿠키 저장
  - 웹 서버는, HTTP 헤더 내 Set-Cookie:란에 셋팅할 쿠키 관련 정보를 실려 보낸다.
  - 웹 브라우저는, 쿠키를 도메인 서버 이름으로 정렬된 쿠키 디렉토리에 저장한다.
세션(Session)
- 개념
  - 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술이다.
  - 즉, 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태이다.

References

mozilla - HTTP 이해하기

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

http://www.ktword.co.kr/abbr_view.php?nav=&m_temp1=5905&id=902

http://www.ktword.co.kr/abbr_view.php?nav=&m_temp1=469&id=492

https://www.zerocho.com/category/HTTP/post/5b594dd3c06fa2001b89feb9

cors - https://zamezzz.tistory.com/137

cors - https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS

[Spring] Spring MVC and Spring Boot Structure

Sat, 05 Jan 2019 00:00:00 +0000

Goal

Spring MVC Structure를 이해한다.

Spring Boot Structure를 이해한다.

참고용! '내가' 사용하는 프로젝트 구조이므로, 개발자마다 설정 방법에 따라 구조가 달라질 수 있다.

Spring MVC Structure

ㄴsrc/main/java

: 자바 소스 파일

class(Servlet)
- controller package
- service package
- dao package
- model package

ㄴsrc/main/resources

: 자바 소스 파일에서 사용하는 리소스 파일(mapper, sql, logging 등 설정 파일)

logback.xml

ㄴweb (또는 webapp)

: Web에서 사용하는 리소스 파일(static files, templates, xml, properties 등)

static or ~~resources~~ DIR
- css, images, fonts, js..
WEB-INF
- props or database DIR
  - jdbc.properties
- views
  - includes DIR
    - header / footer / layout
  - jsp or html
- web.xml
- XXXconfig.xml
  - applicationContext.xml
  - dispatcher-servlet.xml
  - serviceContext.xml
  - daoContext.xml
  - securityContext.xml

ㄴpom.xml

: Maven 프로젝트 설정 파일

프로젝트 기본 정보
빌드 설정
프로젝트 관계 설정
빌드 환경
Property 관리

참고

/WEB-INF 디렉토리 이하는 보안상의 문제로 웹 브라우저를 통한 접근을 금지하고 있다.
- 하지만 포워딩을 통한 접근은 웹 브라우저를 통하지 않기 때문에 가능하다.
- 컴파일된 클래스, 스프링 환경 설정 파일(DB 연결 정보), jsp 등 외부에서의 수정 방지
정적 자원들은 /static 디렉터리 사용을 권장한다.
dispatcher-servlet.xml
- <mvc:resources mapping="/static/**" location="/static/" />
- web/static/
- /는 “web/” location을 의미한다.
applicationContext.xml
- <context:property-placeholder location="classpath:props/jdbc.properties"/>
- web/WEB-INF/props/jdbc.properties
- classpath:는 “web/WEB-INF/” location을 의미한다.

Spring Boot

ㄴsrc/main/java

: 자바 소스 파일

class(Servlet)
- web package (controller)
- service package
- repository package (dao)
- domain package (model)
- dto package
- config package

ㄴsrc/main/resources

: 배포할 리소스 파일(static files, templates, xml, properties 등)

static
- css, images, fonts, js..
templates
- includes DIR
  - header / footer / layout
- dynamic HTML
application-{profile}.properties or application.yml
import.sql
logback.xml

참고

Spring Boot에서는 JSP 보다는 템플릿 엔진의 사용을 권장한다.
- 템플릿 엔진의 개념과 종류 및 필요성 참고
- JSP 사용을 위해서는 추가 설정이 필요하다.
Spring Boot는 기본적으로 src/main/resources/ 디렉터리를 classpath로 가지고 있다.
Spring Boot에서는 classpath 상에서 /static, /resources, /public, /META-INF/resources/ 경로를 기본으로 탐색한다.
- https://docs.spring.io 참고
- /WEB-INF/resources의 경우, jar 파일로 배포할 경우에는 인식하지 않기 때문에 사용하지 않도록 주의한다.
- 정적 자원들은 /static 디렉터리 사용을 권장한다.
Spring Boot에서는 기존의 전통적인 웹 어플리케이션 방식에서 필수로 관리되어야 하는 Tomcat 설정 및 web.xml 파일 등은 스프링부트의 내부 모듈에 의해서 구동시 자동으로 설정된다.
(default로 web/ 디렉터리가 없음)

References

https://gist.github.com/ihoneymon/a343e2f4a0299988206e

http://lazyrodi.github.io/2017/09/03/2017-09-03-spring-structure/

[Logging] SLF4J를 이용한 Logging

Fri, 04 Jan 2019 00:00:00 +0000

Goal

Logging이란

SLF4J(Simple Logging Facade for Java)란

1) SLF4J API

2) SLF4J Binding

3) SLF4J Bridging Modules

SLF4J 특징

Logging이란

프로그램 개발 중이나 완료 후 발생할 수 있는 오류에 대해 디버깅하거나 운영 중인 프로그램 상태를 모니터링 하기 위해 필요한 정보(로그)를 기록하는 것

애플리케이션 실행에 대한 추적을 기록하기 위해 어딘가에 메시지 (콘솔, 파일, 데이터베이스 등)를 작성하는 것
Logging을 어디에 이용할까
- 디버깅
- 사용자 상호 작용 기록 (발생하는 이벤트 기록)
Java의 주요 Logging Framework
- native java.util.logging: 별로 사용하지 않는다.
- Log4J: 몇 년 전까지 사실상 표준으로 사용했다.
- Logback: Log4J 개발자가 만든 Log4J의 후속 버전, 현재 많은 프로젝트에서 사용되고 있다.
- SLF4J(Simple Logging Facade for Java): Log4J 또는 Logback과 같은 백엔드 Logger Framework의 facade pattern(아래 참고)
- tinylog: 사용하기 쉽게 최적화된 Java용 최소형(75KB Jar) 프레임워크

VS Debuggger

장점
- Logging은 응용 프로그램 실행에 대한 정확한 컨텍스트(이벤트 순서)를 제공한다.
  - 전체적인 app의 흐름이나 타이밍 error도 확인할 수 있다.
  - error 종류: 논리적 에러, 타이밍 에러(multi-thread) 등
- 일단 코드에 삽입되면 logging output이 만들어질 때 사용자 개입이 필요 없다.
- 로그 출력은 나중에 살펴볼 수 있도록 영구 매체에 저장할 수 있다.
  - disk에 기록을 남겨 유용한 로깅 정보를 추적할 수 있다.
- Logging Framework는 Debuggger보다 간단하고 배우기 쉽고 사용하기 쉽다.
단점
- 출력문이 들어가기 때문에 응용 프로그램 속도를 늦출 수 있다.
- 너무 장황할 수 있다. (오버헤드)
  - 메시지 level을 나누는 기능
- 고급 사용은 구성을 확실히 알아야 한다.

VS Plain Output(System.out.println())

장점
- 높은 유연성
- 우선순위 level 이상의 출력 메시지를 선택할 수 있다.
  - —trace, debug, info, warn, error—> high
- 모든 모듈 또는 특정 모듈 또는 클래스에 대해 메시지를 출력할 수 있다.
- 로그 메시지의 형식을 제어할 수 있다.
  - 매개 변수화된 로그 메시지 지원
- 출력 위치를 지정할 수 있다.

SLF4J(Simple Logging Facade for Java)란

Log4J 또는 Logback과 같은 백엔드 Logging Framework의 facade pattern

다양한 Logging Framework에 대한 추상화
- SLF4J는 추상 로깅 프레임워크이기 때문에 단독으로는 사용하지 않는다.
SLF4J api를 사용하면 구현체의 종류에 상관없이 일관된 로깅 코드를 작성할 수 있다.
배포할 때 원하는 Logging Framework를 선택할 수 있다.
- Ex) logback/log4j/jdk14 - SLF4J - app
- 개발할 때, SLF4J API를 사용하여 로깅 코드를 작성한다.
- 배포할 때, 바인딩된 Logging Framework가 실제 로깅 코드를 수행한다.
교환 가능
- Logging Framework 간에 쉬운 전환이 가능하다.
SLF4J는 세 가지 모듈을 제공한다. (API / Binding / Bridging)
1. SLF4J API 활성화
  - slf4j-api-1.7.25.jar (2017년 기준)
  - slf4j-api-1.8.0-beta2.jar (2019년 기준)
2. SLF4J 바인딩(.jar)
  - SLF4J 인터페이스를 로깅 구현체와 연결하는 어댑터 역할을 하는 라이브러리
  - 사용하길 원하는 Logging Framework에 대한 SLF4J 바인딩을 추가해야 한다.
    (반드시 한개만 사용)
3. SLF4J Bridging Modules
  - 다른 로깅 API로의 Logger 호출을 SLF4J 인터페이스로 연결(redirect)하여 SLF4J API가 대신 처리할 수 있도록 하는 일종의 어댑터 역할을 하는 라이브러리
  - 다른 로깅 API -> Bridge(redirect) -> SLF4J API

참고 facade pattern

여러 개의 클래스가 하나의 역할을 수행할 때, 대표적인 인터페이스만을 다루는 클래스를 두어 원하는 기능을 처리할수 있게 도와주는 패턴이다.
- 클라이언트는 Facade에 요청을 전송하여 Subsystem과 통신하며, Facade는 해당 요청을 적절한 Subsystem 객체로 전달한다.
  - Subsystem 객체가 실제 작업을 수행하지만 Facade는 인터페이스를 Subsystem 인터페이스로 변환하기 위해 자체 작업을 수행해야 할 수도 있다.
  - 즉, 공통된 Interface를 적절하게 변환해서 연결한다.
- Facade를 사용하는 클라이언트는 Subsystem 객체에 직접 액세스할 필요가 없다.
  - 즉, 클라이언트는 Subsystem을 알 필요 없이 Common Interface에만 접근한다.

1) SLF4J API - “Hello World” using SLF4J

1. class path에 slf4j-api-1.7.25.jar 추가 (pom.xml)

<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.25</version>
</dependency>

2. HelloWorld 클래스를 컴파일하고 실행

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class HelloWorld {   
    public static void main(String[] args) {      
        Logger logger = LoggerFactory.getLogger(HelloWorld.class);  
        logger.info("Hello World");   
    }
}

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". 
SLF4J: Defaulting to no-operation (NOP) logger implementation 
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

이 경고는 class path에서 slf4j 구현체를 찾을 수 없기 때문에 출력된다.
- 즉, class path에 사용하길 원하는 Logging Framework에 대한 slf4j 바인딩(.jar)을 추가해야 한다.
- 이때, 둘 이상의 slf4j 바인딩(반드시 하나만)을 두면 안된다.
Logging Framework를 전환하려면 class path에서 slf4j 바인딩을 변경한다.
- Ex) java.util.logging —> log4j로 전환하려면
- slf4j-jdk14-1.7.25.jar —> slf4j-log4j12-1.7.25.jar로 변경

2) SLF4J Binding

SLF4J 인터페이스를 로깅 구현체(Logging Framework)와 연결하는 어댑터 역할을 하는 라이브러리
SLF4J binding with a Logging Framework
- 각각의 SLF4J binding(.jar)은 compile time에 오직 하나의 Logging Framework를 사용하도록 바인딩한다.
- class path에서 바인딩된 구현체가 발견되지 않으면 slf4j는 기본적으로 no-operation으로 설정된다. (즉, 출력되는 것이 없음)
- 사용하길 원하는 Logging Framework에 대한 SLF4J 바인딩을 추가해야 한다.

SLF4J binding 종류

사용하길 원하는 Logging Framework에 대한 SLF4J 바인딩을 추가해야 한다. (반드시 한개만 사용)

SLF4J binding(.jar))	Description
slf4j-log4j12-{version}.jar	널리 사용되는 로깅 프레임워크인 log4j 버전 1.2에 대한 바인딩. 또한 log4j.jar을 클래스 경로에 배치해야 한다.
slf4j-jdk14-{version}.jar	java.util.logging(JDK1.4 로깅)에 대한 바인딩.
slf4j-nop-{version}.jar	NOP에 대한 바인딩. 모든 로깅을 자동으로 삭제합니다.
slf4j-simple-{version}.jar	모든 이벤트를 System.err에 출력하는 단순 구현 바인딩. INFO 이상의 메시지만 출력되므로 작은 응용 프로그램에서 유용하다.
slf4j-jcl-{version}.jar	JCL(Jakarta Commons Logging)에 대한 바인딩. 모든 SLF4J 로깅을 JCL에 위임한다.
logback-classic-{version}.jar	(logback-core-{version}.jar 필요) native implement Logback의 클래스는 SLF4J의 인터페이스를 직접 구현한 것으로, SLF4J 프로젝트 외부에 SLF4J 바인딩이 있다. 따라서 Logback과 함께 SLF4J를 사용하면 메모리 및 오버헤드가 발생하지 않는다. Logback의 `ch.qos.logback.classic.Logger` 클래스는 SLF4J의 `org.slf4j.Logger` 인터페이스를 직접 구현한 것이다.

예시: SLF4J binding with Logback

기본 Logging Framework로 logback-classic을 사용하려면

<!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-classic -->
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.2.3</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
        </exclusion>
    </exclusions>
    <scope>compile</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-core -->
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <version>1.2.3</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.25</version>
</dependency>

pom.xml에 ch.qos.logback:logback-classic" dependency 추가
- 이 dependency 하나만 추가해도 된다.
- logback-classic가 의존하는 logback-core-1.2.3.jar뿐만 아니라 slf4j-api-1.7.25.jar를 자동으로 가져온다.
- 하지만 해당 artifact의 올바른 버전을 사용하는데 필요하기 때문에 모두 명시적으로 선언하는 것이 좋다.
애플리케이션 레이어에서 SLF4J를 사용해서 Logging 코드를 작성하면 실제 로그를 출력하는 행위는 Logback이 하게 된다.

3) SLF4J Bridging Modules

(SLF4J 이외의) 다른 로깅 API로의 Logger 호출을 SLF4J 인터페이스로 연결(redirect)하여 SLF4J API가 대신 처리할 수 있도록 하는 일종의 어댑터 역할을 하는 라이브러리

Consolidate logging via SLF4J

프로젝트는 다양한 components로 구성된다.
- components 중 일부는 SLF4J 이외의 로깅 API에 의존한다.
- Ex) spring-context는 JCL(Jarkarta Commons Logging) API를 사용
이러한 상황을 처리하기 위해 SLF4J에는 여러 Bridging Module이 제공된다.

Bridging legacy logging APIs

여러 다른 로깅 API를 사용하는 components에 대해 single channel을 통해 Logging을 통합하는 것이 바람직하다.
이를 위해 SLF4J에서 log4j API, JCL(Jakarta Commons Logging) API 및 JUL(Java Util Logging) API에 대한 호출을 대신 SLF4J API에 대한 것처럼 리디렉션하는 여러 Bridging Modules을 제공한다.

SLF4J가 제공하는 Bridge의 종류

겉으로는 다른 로깅 API를 사용하는 것 같지만 내부에서는 SLF4J API를 호출하도록 일종의 어댑터 역할을 해주는 라이브러리
- 다른 로깅 API -> Bridge -> SLF4J API

SLF4J binding(.jar))	Description
jcl-over-slf4j.jar	JCL API에 의존하는 클래스들을 손상시키지 않고 JCL로 들어오는 호출을 JCL-over-SLF4J를 이용해서 SLF4J API를 호출한다. 즉, 이 모듈을 사용하면 JCL을 사용하는 기존 소프트웨어와의 호환성을 손상시키지 않으면서 프로젝트를 SLF4J로 단편적으로 마이그레이션할 수 있다.
log4j-over-slf4j.jar	이 모듈을 사용하면 log4j 호출을 SLF4J API로 리디렉션할 수 있다.
jul-to-slf4j.jar	이 모듈을 사용하면 java.util.logging 호출을 SLF4J API로 리디렉션할 수 있다.

사용 시 주의할 점
- jcl-over-slf4j.jar
  - JCL API 사용 X —> 의존성에서 commons-logging.jar 제거
  - SLF4J Binding인 slf4j-jcl-{version}.jar와 같이 쓸 수 없다. (무한루프)
- log4j-over-slf4j.jar
  - Log4J API 사용 X —> 의존성에서 log4j.jar 제거
  - SLF4J Binding인 slf4j-log4j12-{version}.jar와 같이 쓸 수 없다. (무한루프)
- jul-to-slf4j.jar
  - java.util.logging은 교체 불가능 (LogRecord 객체를 사용해서 위임)
  - SLF4J Binding인 slf4j-jdk14-{version}.jar와 같이 쓸 수 없다. (무한루프)

참고 JCL(Jakarta Commons Logging)

Log4j, LogKit, JDK1.4과 같은 다른 Logging Framework에 대한 추상화 계층을 제공하는 인터페이스
로깅 라이브러리가 아니라 로깅 추상화 라이브러리
- 로깅 라이브러리 선택권은 애플리케이션 개발자의 것이다.
- 따라서 프레임워크는 주로 로깅 추상화 라이브러리를 사용하는 것이 좋다.
단점
- 실제 Logging Framework을 선택하는 시점이 runtime이라 클래스 로더 문제
  - 클래스 로더에 의존적인 방법으로 구현체(Logging Framework)를 찾는다.
- 런타임 시 오버헤드

예시: Logging with SLF4J and Logback

필요한 라이브러리

... 
    위의 SLF4J binding with Logback 내용과 동일 
    logback-classic
    logback-core
    slf4j-api
...
<!-- https://mvnrepository.com/artifact/org.slf4j/log4j-over-slf4j -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>1.7.25</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.slf4j/jcl-over-slf4j -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>1.7.25</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.slf4j/jul-to-slf4j -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jul-to-slf4j</artifactId>
    <version>1.7.25</version>
</dependency>

SLF4J API (인터페이스)
- 로깅에 대한 추상 레이어를 제공
- 사용자가 이 interface를 통해 로깅 코드를 작성한다.
- slf4j-api
SLF4J Binding(.jar)
- SLF4J 인터페이스를 로깅 구현체로 연결하는 어댑터 역할을 하는 라이브러리
- SLF4J에 구현체(Logging Framework)를 바인딩하기 위해 사용한다.
- 여러 바인딩 중 하나만 사용할 것
- [Logback] logback-classic / [Log4J] slf4j-log4j12
Logging Framework
- 실제 로깅 코드를 실행할 Logging Framework를 정한다.
- [Logback] logback-core / [Log4J] log4j-core
SLF4J Bridging Module
- 다른 로깅 API -> Bridge(redirect) -> SLF4J API
- 다른 로깅 API로의 Logger 호출을 SLF4J 인터페이스로 연결(redirect)하여 SLF4J API가 대신 처리할 수 있도록 하는 일종의 어댑터 역할을 하는 라이브러리
- log4j-over-slf4j, jcl-over-slf4j, jul-to-slf4j

Logging Framework를 변경하고 싶으면 2, 3번을 교체

SLF4J 특징

배포시 Logging Framework 선택 가능
- compile time에 오직 하나의 Logging Framework를 사용하도록 바인딩
빠른 속도로 작동
- 클래스가 JVM에 의해 로드되는 방식으로 인해 프레임워크 바인딩은 초기에 자동으로 확인된다.
널리 사용되는 Logging Framework를 위한 바인딩 제공
- log4j, java.util.logging, 단순 로깅 및 NOP를 지원
- logback 프로젝트는 기본적으로 SLF4J를 지원
Bridging legacy logging API
- log4j API, JCL(Jakarta Commons Logging) API 및 java.util.logging API에 대한 호출을 대신 SLF4J API에 대한 것처럼 리디렉션하는 여러 Bridging Modules을 제공
Migrate your source code
- SLF4J-Migrator utility를 사용하면 SLF4J를 사용하는 소스를 마이그레이션할 수 있다.
매개 변수화된 로그 메시지 지원

References

https://www.slf4j.org/manual.html

https://stackify.com/compare-java-logging-frameworks/

스프링 부트와 로깅 slideshare

http://whiteship.me/?p=12162

https://sonegy.wordpress.com/2014/05/23/how-to-slf4j/

[Spring] Spring Security

Thu, 03 Jan 2019 00:00:00 +0000

Goal

Spring Security란

Spring Security 사용법

1) 필요한 Library

2) Spring Security 활성화

3) Spring Security 설정

(참고) Expression-Based Access Control

(참고) Custom Login/Logout Form

Spring Security Architecture (전체 과정)

Spring Security란

스프링 기반 애플리케이션의 보안을 위한 사실상의 표준
- Spring Security는 전적으로 Servlet Filter를 기반으로 한다.
- Filter는 (Servlet과 브라우저 사이에서 주고 받는) 요청과 응답을 가로 채고, 해당 요청/응답 전후에서 필요한 처리를 할 수 있다.
사용자 정의가 가능한 인증 및 접근제어/권한 프레임워크
- authientication(인증): id/pw, 공인인증서 등
- authorization(권한): admin, user, guest 등
간략한 과정

Authorization(권한): 권한이 없는 User가 접근할 경우, 자동으로 Login Page를 띄어준다.
Authentication(인증): 사용자가 입력한 id/pw가 일치하는지 Authentication Providers(DB)를 통해 확인한다.
id/pw가 일치하지 않으면 1, 2번을 반복한다.
인증과 권한이 통과가 되면 Secured Area에 접근을 허용한다.

Spring Security 사용법

1. 필요한 Library

<properties>
        <org.springframework-version>5.1.3.RELEASE</org.springframework-version>
        <org.springsecurity-version>4.2.3.RELEASE</org.springsecurity-version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-core</artifactId>
        <version>${org.springsecurity-version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-web</artifactId>
        <version>${org.springsecurity-version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-config</artifactId>
        <version>${org.springsecurity-version}</version>
    </dependency>
</dependencies>

사용하는 버전에 주의한다. (여기서는 Spring Security 4를 기준으로 작성)

2. Spring Security 활성화

Spring Security는 DelegatingFilterProxy를 사용한다.
- DelegatingFilterProxy는 모든 요청을 가로채는 Filter이다.
- 이 Filter를 web.xml에 추가한다.

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<filter-name> : 이 이름으로 등록된다.
<filter-class> : Filter로 사용할 클래스
<filter-mapping> : 위에서 설정한 Filter 이름과 url을 mapping한다. (“/*”: 모든 request)
이 Filter를 이용하면 Spring이 요청을 가로채서 해당 사용자의 인증, 권한을 알아서 확인해준다.
- 사용자가 입력한 정보와 DB에 저장되어 있는 정보를 비교한 후 알아서 인증, 권한을 확인한다.
- 단, App마다 달라지는 부분은 우리(개발자)가 알아서 처리한다.

3. Spring Security 설정

web.xml 설정

<!-- web.xml -->
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/applicationContext.xml
        /WEB-INF/securityContext.xml 
    </param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

web.xml의 contextConfigLocation에 securityContext.xml을 추가한다.
- 그래야 나중에 ContextLoaderListener에 의해 등록된 설정 파일을 읽을 수 있다.

securityContext.xml 설정

# 1. beans에 추가할 설정

<!-- securityContext.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:security="http://www.springframework.org/schema/security"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/security
       http://www.springframework.org/schema/security/spring-security.xsd">
       
       ...
</beans>

beans에 추가할 설정
- xmlns:security="http://www.springframework.org/schema/security"
  - 내가 설정한 약어: security
- xsi:schemaLocation="http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd"

# 2. Authentication(인증) 설정

<!-- Authentication(인증) 설정 -->

<!--방법 1. User Authentication with In-Memory definition-->
<security:authentication-manager>
    <security:authentication-provider>
        <security:user-service>
            <security:user name="admin" password="1234" authorities="ROLE_ADMIN"/>
            <security:user name="testUser" password="test" authorities="ROLE_USER"/>
        </security:user-service>
    </security:authentication-provider>
</security:authentication-manager>

<!--방법 2. Other Authentication Provider (Using Database)-->
<security:authentication-manager>
    <security:authentication-provider>
    <security:jdbc-user-service
        data-source-ref="dataSource"
        users-by-username-query="select username, password, enabled from users where username=?"
        authorities-by-username-query="select username, authority from authorities where username=?"/>
    </security:authentication-provider>
</security:authentication-manager>

<authentication-manager>
- 요청의 인증을 처리한다.
- <authentication-provider>가 제공하는 메커니즘을 사용하여 사용자를 인증한다.
인증 처리를 할 사용자 정보를 가져오는 방법 2가지
- 1) 메모리
- 2) DB
- 모두 있어도 상관없다.

<security:user-service>
- test를 위해 메모리 상에 일시적으로 하드 코드된 사용자를 정의한다.
  - 이름은 “admin”, 비밀번호는 “1234”인 사용자에게 “ROLE_ADMIN” 권한 부여
  - 이름은 “admtestUserin”, 비밀번호는 “test”인 사용자에게 “ROLE_USER” 권한 부여
<security:jdbc-user-service>
- DB에 사용자 계정 정보를 저장한다.
  - table은 개발자가 설계한다.
  - 여기서는 계정 정보 테이블과 권한 정보 테이블을 만들었다.
  - 이 정보들은 사용자가 회원가입할 때 저장해야하는 정보들이다.
- data-source-ref="dataSource"
  - DB 접근을 위한 명시
- 데이터베이스 정보를 추출하기 위해 수행할 구체적인 쿼리를 정의한다.
  - 아래의 쿼리는 Default로 설정되어 있다. (명시하지 않아도 됨)
    - Spring Security가 인증, 권한을 확인하기 위한 사용자의 정보들을 가져오기 위해서 Spring에게 해당 쿼리문을 수행하라고 명시하는 것이다.
  - 1) users-by-username-query="select username, password, enabled from users where username=?"
    - 사용자가 입력한 username 정보를 바탕으로 인증을 위한 username, password, enabled 정보를 가져온다.
  - 2) authorities-by-username-query="select username, authority from authorities where username=?"
    - 사용자가 입력한 username 정보를 바탕으로 접근 제어를 위한 authority(권한 정보)을 가져온다.
- 이후에는 사용자가 입력한 정보와 DB에 저장되어 있는 정보를 비교하여 Spring Security가 알아서 인증, 권한을 확인한다

# 3. Authorization(권한)

<!-- Authorization(권한) 설정 -->
<security:http auto-config="true" use-expressions="true">
    <security:intercept-url pattern="/secured/**" access="hasRole('ROLE_USER')" />
    <security:intercept-url pattern="/admin/**" access="hasRole('ROLE_ADMIN')" />
    <security:intercept-url pattern="/login" access="permitAll()" />
    <security:intercept-url pattern="/" access="permitAll()" />
    <security:intercept-url pattern="/resources/**" access="permitAll()" />
    <security:intercept-url pattern="/**" access="denyAll()" />
    <security:form-login login-page="/login" />
</security:http>

auto-config="true"
- form 기반 로그인, 기본 인증 및 로그 아웃 메커니즘을 자동으로 활성화한다.
use-expressions="true"
- Spring EL Expressions 사용을 활성화한다. (아래 참고)
<security:intercept-url>
- 보안이 필요한 요청 URL에 대한 패턴을 정의한다.
- access 속성(use-expressions)
  - 해당 패턴과 일치하는 요청된 URL을 볼 수 있는 권한이 있는 사용자의 역할을 정의한다.
  - 권한은 특정 사용자에게 할당된 역할 목록을 쉼표로 분리하여 사용할 수 있다.
<security:form-login>
- default settings을 오버라이딩한다.
- login-page="/login"
  - Defalt 페이지인 Spring Login Form이 아닌 사용자가 정의한 Custom Login Form을 사용한다. (아래 참고)

(참고) Expression-Based Access Control

Authorization(접근 제어) 메커니즘으로서 Spring EL Expressions를 사용한다.

Expression	Description
hasRole([role])	현재 로그인한 주체(principal)가 권한을 가지고 있으면 true 반환
hasAnyRole([role1,role2])	현재 로그인한 주체가 제공된 권한 중 하나라도 가지고 있으면 true 반환 (쉼표로 여러 개의 권한 목록 지정 가능)
principal	현재 로그인한 사용자를 나타내는 객체에 직접 액세스할 수 있다.
authentication	SecurityContext에서 얻은 현재 Authentication 객체에 직접 액세스할 수 있다.
permitAll	모든 사용자 접근 가능 (Always evaluates to true)
denyAll	모든 사용자 접근 불가능 (Always evaluates to false)
isAnonymous()	현재 로그인한 사용자가 익명 사용자(anonymous user)인 경우 true 반환
isRememberMe()	현재 로그인한 사용자가 기억하고 있는 사용자(remember-me user)인 경우 true 반환
isAuthenticated()	현재 로그인한 사용자가 익명이 아닌 경우 true 반환 (인증만 되어 있으면 접근 허용)
isFullyAuthenticated()	현재 로그인한 사용자가 익명 또는 기억하고 있는 사용자가 아닌 경우 true 반환

(참고) Custom Login/Logout Form

default settings을 오버라이딩

<security:form-login login-page="/login" />

내가 정한 URL을 처리할 Login Controller(@GetMapping)을 만든다.

Custom Loing Page(login.jsp)를 만든다.

1. securityContext.xml 설정

<security:form-login>
- default settings을 오버라이딩한다.
- Defalt 페이지인 Spring Login Page가 아닌 사용자가 정의한 Custom Login Page를 사용한다.

<security:form-login login-page="/login" />

security:form-login attribute (Spring Security 4)
- login-page="/login"는 Spring Security을 지시한다.
  - 인증 절차를 처리할 URL(/login)을 정한다.
  - 개발자가 임의로 결정할 수 있다.
  - 접근 제어에 따라 사용자의 인증 절차가 필요한 경우 브라우저를 해당 URL(“/login”)으로 redirect한다.
    - return redirect:/login; [GET]
  - 해당 요청을 처리할 LoginController는 로그인 페이지를 렌더링하는 login.jsp를 반환한다.
- authentication-failure-url="/login?error"
  - 특별히 지정하지 않아도 Default로 설정되어 있다.
    - 관례상 error =1을 넣기도 한다.
  - 사용자가 잘못된 사용자 이름과 암호로 로그인하려고 하면 동일한 로그인 페이지로 가되, 인증 실패를 알리기 위해 URL 뒤에 error라는 request parameter를 붙여 성공과 구분한다.
    - 즉, 인증 시도가 실패하면 브라우저를 “/login?error”로 redirect한다.
    - return redirect:/login?error; [GET]
  - 마찬가지로 해당 요청을 처리할 LoginController는 실패 메시지를 Model에 담아 login.jsp를 반환한다.
security:logout attribute (Spring Security 4)
- logout-success-url="/login?logout"
  - 특별히 지정하지 않아도 Default로 설정되어 있다.
  - 사용자가 성공적으로 로그아웃하면 브라우저를 “/login?logout”로 redirect한다.
    - return redirect:/login?logout; [GET]
  - 마찬가지로 해당 요청을 처리할 LoginController는 로그아웃 확인 메시지를 Model에 담아 login.jsp를 반환한다.

security:form-login attribute (Spring Security 4)

Attribute	Default value	Note
login-page	/login	implement
username-parameter	username
password-parameter	password
login-processing-url	/login , POST	the URL used to process the login request by spring
authentication-failure-url	/login?error	implement

security:logout attribute (Spring Security 4)

Attribute	Default value	Note
logout-url	/logout, POST	Log out processing module by spring
logout-success-url	/login?logout	implement

2. Controller

@Controller
public class LoginController {
    // 사용자가 입력한 정보로부터 POST 요청은 Spring Security를 거친 후 해당 메서드로 들어온다.
    @GetMapping("/login") 
    public String login(@RequestParam(value="error", required=false) String error, 
                        @RequestParam(value="logout", required=false) String logout, 
                        Model model) {
        if(error != null) {
            model.addAttribute("errorMsg", "Invalid username and password");
        }
        if(logout != null) {
            model.addAttribute("logoutMsg", "You have been logged out successfully");
        }
        return "login"; // login.jsp(Custom Login Page)
    }    
}

POST 요청 —> Spring Security —redirect:(GET 요청)—> 내가 작성한 Controller
- POST 요청은 Spring Security에 의해 처리
- Spring Security가 “redirect:” 한 GET 요청은 내가 작성한 Controller에서 처리
인증 성공 시, redirect:/
- HomeController - index.jsp(Main Page) 반환
인증 실패 시, redirect:/login?error
- LoginController - 오류 메시지를 Model에 담아 login.jsp(Custom Login Page) 반환
로그아웃 성공 시, redirect:/login?logout
- LoginController - 로그아웃 확인 메시지를 Model에 담아 login.jsp(Custom Login Page) 반환

3. Custom Loing Page

home.jsp

<!-- 로그인한 사용자가 있으면 LOGOUT이 보인다. -->
<c:if test="${pageContext.request.userPrincipal.name != null}">
    <a href="javascript:document.getElementById('logout').submit()">LOGOUT</a>
</c:if>

<!-- logout processing module of spring security 4 -->
<form id="logout" action="<c:url value="/logout" />" method="post">
    <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}" />
</form>

<h3>Custom Login with Username and Password</h3>
<!-- For logout  -->
<c:if test="${not empty logoutMsg}">
    <div style="color: #0000ff;" > 
        <h3> ${logoutMsg} </h3>
    </div>
</c:if>

<!-- login processing module of spring security 4 -->
<form action="<c:url value="/login"/>" method="post">
<!-- For failed user authentication  -->
  <c:if test="${not empty errorMsg}">
    <div style="color: #ff0000;"> 
        <h3> ${errorMsg} </h3>
    </div>
  </c:if>

  <table>
    <tr><td>User:</td><td><input type='text' name='username' value=''></td></tr>
    <tr><td>Password:</td><td><input type='password' name='password' /></td></tr>
    <tr><td colspan='2'><input name="submit" type="submit" value="LOGIN" /></td></tr>
    <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
  </table>
</form>

login/logout processing module of spring security 4
- action="<c:url value="/logout" />"
- action="<c:url value="/login" />"
spring security에 지정되어 있는 이름이기 때문에 위의 value는 변경하면 안된다.
- 즉, 개발자가 임의로 결정할 수 없다.
- 버전마다 value가 다를 수 있다.
참고) CSRF(사이트 간 요청 위조, Cross-Site Request Forgery) attack
- 개념
  - 웹 어플리케이션 취약점 중 하나
  - 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 하여 특정 웹 페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법을 말한다.
- 방어 방법
  - <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
  - 민감한 정보를 아둘 때 세션에 Token(임의의 난수)를 발급하여, 해당 난수가 없는 상황에서 해당 동작들이 이루어지면 요청을 거부한다.

Spring Security Architecture (전체 과정)

Authorization
- securityContext.xml에 권한 설정 명시
- 권한이 없는 User가 접근할 경우,
- Spring이 내부적으로 Defalt 페이지인 Spring Login Page로 redirect한다.
- 참고) 사용자가 설정한 Login Page로 redirect하는 경우, 설정 파일(securityContext.xml)의 권한 설정에 아래 내용 추가
  - <security:form-login login-page="/login" />
Authentication
- 사용자가 입력한 id/pw가 일치하는지 Authentication Providers(DB)를 통해 확인한다.
id/pw가 일치하지 않으면 1, 2번을 반복한다.
인증과 권한이 통과가 되면 Secured Area에 접근을 허용한다.
- Login한 사용자가 인증, 권한에 대해 모두 성공하면 원래의 URL(Secured Page)로 redirect한다.

사용자 동작에 따른 전체 과정 설명

사용자 흐름에 따른 전체 과정 요약

사용자가 로그인 정보를 입력하고 Submit하면 /login URL로 POST 요청이 날아간다.
이후에는 Spring Security에 의해 Login/Logout Process를 거친다.
- Spring Security가 인증 결과에 따라 적절하게 redirect: 를 반환한다.
  - 인증 성공 시, redirect:/
  - 인증 실패 시, redirect:/login?error
  - 로그아웃 성공 시, redirect:/login?logout
Controller에서 해당 redirect GET 요청을 받아 처리한다.
- 인증 성공 시, HomeController에서 return index.jsp(Main Page)
- 인증 실패 시, LoginController에서 오류 메시지를 Model에 담아 return login.jsp(Custom Login Page)
- 로그아웃 성공 시, LoginController에서 로그아웃 확인 메시지를 Model에 담아 return login.jsp

참고) POST 요청 —> Spring Security —redirect:(GET 요청)—> 내가 작성한 Controller
- POST 요청은 Spring Security에 의해 처리
- Spring Security가 “redirect:” 한 GET 요청은 내가 작성한 Controller에서 처리

로그인 인증 성공/실패

home.jsp에서 Secured Page(Ex. Admin Page) 이동 클릭 [GET]
접근 제어에 따라 사용자 인증 절차 필요 (Ex. ROLE_ADMIN 사용자만 가능)
- login-page="/login"에 의해 Spring Security가 브라우저를 “/login”로 redirect
- 참고) 이때, login-page의 URL은 개발자가 임의로 정할 수 있다.
- return redirect:/login; [GET]
개발자가 작성한 LoginController login method [GetMapping]
- return login.jsp (Custom Login Page)
login.jsp에서 사용자 정보 입력 후 LOGIN을 Submit [POST]
- <form action="<c:url value="/login"/>" method="post">
- 참고) 이때, value 값은 개발자가 임의로 정할 수 없다. (spring security에 지정되어 있는 이름)
Spring Security login method [PostMapping] 실행
- 인증 절차 성공:
  - redirect:/ [GET] (원래의 URL(Secured Page)로 redirect)
  - -> HomeController [GetMapping]에서 return index.jsp
  - 6번으로 넘어가지 않는다.
- 인증 절차 실패:
  - request parameter에 error 추가
  - return redirect:/login?error; [GET]
LoginController login method [GetMapping] 실행
- error request parameter 유무 체크
- Model에 errorMsg 저장
- return login.jsp
login.jsp에서 errorMsg 표시

로그아웃 인증 성공

home.jsp에서 LOGOUT을 Submit [POST]
- <form id="logout" action="<c:url value="/logout" />" method="post">
- 참고) 이때, value 값은 개발자가 임의로 정할 수 없다. (spring security에 지정되어 있는 이름)
Spring Security logout method [PostMapping] 실행
- 로그아웃 성공:
  - request parameter에 logout 추가
  - return redirect:/login?lougut; [GET]
LoginController login method [GetMapping] 실행
- logout request parameter 유무 체크
- model에 logoutSuccessMsg 저장
- return login.jsp
login.jsp에서 logoutSuccessMsg 표시

References

https://docs.spring.io/spring-security/site/docs/current/guides/html5/helloworld-xml.html

https://docs.spring.io/spring-security/site/docs/current/guides/html5/form-javaconfig.html

https://www.baeldung.com/spring-security-login

https://github.com/spring-projects/spring-security/blob/

schema 참고

CSRF attack

[SpringMVC] Spring MVC WebForm

Wed, 02 Jan 2019 00:00:00 +0000

Goal

Request Paremeter의 종류

Data Binding

Data Validation

Data Buffering

Error Message

Request Parameter의 종류

Request Parameter는 HTTP Request Message 안에 담겨서 보내진다.

Request Parameter는 2가지 방식으로 전달된다.

1. GET 방식 : Query String

url 뒤에 query string 형식으로 붙어서 보내진다.
Ex) 조회와 같이 DB를 변경하지 않는 작업에 이 방식을 사용한다.

2. POST 방식 : HTTP Entity Body

HTTP Request Message의 Body에 담겨서 보내진다.
Ex) 암호화, 회원가입(password) 등 주로 DB를 변경하는 작업에 이 방식을 사용한다.

Data Binding

request parameters가 form bean(=command object)에 바인딩되는 것을 말한다.

예시

1. Naive Solution (@RequestParam 어노테이션)

@RequestParam 어노테이션 이용
- method 인자에 request parameter을 binding 해준다.
- 반드시 query string의 key 이름이 동일해야 값을 가져올 수 있다.
- method 인자에 form bean을 선언하지 않는다.

@RequestMapping("/docreate")
public String doCreate(@RequestParam("name") String name,
                    @RequestParam("email") String email,
                    Model model) {

   // we manually populate the Offer object with 
   // the data coming from the user
   Offer offer = new Offer();

   offer.setName(name);
   offer.setEmail(email);
   ...
}

method 인자가 3개 이상이면 2번째 방법을 이용한다.

2. Spring Data Binding (자동 Binding)

method 인자에 form bean을 선언한다.
- Spring이 자동으로 request paraters를 객체에 binding 해준다.

@RequestMapping(value="/docreate", method=RequestMethod.POST)
public String doCreate(Offer offer) {
// offer object will be automatically populated 
// with request parameters
}

Data Binding 과정

form bean 객체(Offer 객체)를 생성한다.
request parameter으로부터 form bean에 내용이 자동으로 binding된다.
- 이때, form bean(POJO)에 setter method가 구현되어 있어야 binding이 가능하다.
- 또한 controller의 method 인자에 form bean을 선언되어 있어야 한다.
controller에서 form bean을 자동으로 model에 넣어준다. (form bean은 model attribute이다.)
model을 view에 넘겨준다.
- controller에서 form bean을 model에 넣어 view에 전달한다.
view는 form bean 내용에 접근할 수 있고 이 내용을 rendering 할 수 있다.
- 즉, controller로부터 전달받은 model에 있는 form bean(Offer 객체, model attribute)를 사용하여 request parameter에 접근할 수 있다.

<html> 
<head> 
	<title>Thanks</title> 
</head> 
<body> 
    Hi, ${offer.name}.<br/>
    You have successfully registered.
</body> 
</html>

Data Validation

사용자가 실수로 잘못된 정보를 입력했을 때 잘못된 양식임을 알려주기 위해 사용한다.

1. Hibernate Validator

사용자의 오류를 감지하기 위해 form bean에 캡슐화된 form data의 유효성을 검사해야 한다.
Bean Validation API(JSR-303)는 JavaBean 유효성 검사를 위한 API를 정의하는 명세서이다.
- 이 명세의 구현체가 Hibernate Validator(라이브러리)이다.
- 검증 제약 조건을 bean properties에 어노테이션을 달아 설정할 수 있다.
- Ex) @NotNull, @Pattern, @Size, @Email 등
pom.xml에 추가

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>5.2.4.Final</version>
</dependency>

예시

public class Offer {
    private int id;

    @Size(min=5, max=100)
    @Pattern(regexp="^[A-Z]{1}[a-z]+$") // 정규표현(Regular Expression)
    private String name;

    @NotEmpty
    @Email
    private String email;
}

2. Message Interpolation

메시지 보간법(삽입 어구)은 위배된 Bean 유효성 검증 제약 조건에 대한 오류 메시지를 생성하는 것이다.

메시지 속성을 통해 각 속성의 message descriptor를 정의할 수 있다.
예시

public class Offer {

   private int id;

   @Size(min=3, max=100, message="Name must be between 3 and 100 characters")
   private String name;

   @Email(message="please provide a valid email address")
   @NotEmpty(message="the email address cannot be empty")
   private String email;

   @Size(min=5, max=100, message="Text must be between 5 and 100 characters")
   private String text;
 }

문제점
- message resources(불변)가 code 안에 들어가 있는 형태이므로 별도의 파일로 관리하는 것이 바람직하다.
- 사용자의 location(지역)에 맞는 언어로 바꿔줘야 한다.

3. Validating Object

@Valid 어노테이션
- @Valid 어노테이션을 통해 Hibernate가 자동으로 유효성 검사를 한다.
- controller method의 인자 중 검증할 객체 인자 앞에 해당 어노테이션을 단다.
- @Valid 어노테이션은 객체의 유효성을 먼저 확인한 다음 모델에 객체를 추가한다.
BindingResult Object
- 유효성 검사 과정의 결과를 나타낸다.
- 필요한 경우에 controller method의 인자에 추가한다.
- form bean과 같이 model에 들어가서 View에 넘겨준다.
- 이를 통해 View는 error message를 출력할 수 있다.
즉, @Valid에 의해 Spring이 자동으로 유효성을 검사하고, 그 결과인 BindingResult 객체를 자동으로 Model에 넣어준다.
- form bean과 BindingResult가 포함된 Model을 View에서 사용할 수 있다.
예시

@RequestMapping(...)
public String doCreate(@Valid Offer offer, BindingResult result) { 
    if(result.hasErrors()) {
	List<ObjectError> errors = result.getAllErrors();

       for(ObjectError error:errors) {
    		System.out.println(error.getDefaultMessage());
       }
       return "createoffer";
    }
    ... 
}

Data Buffering

사용자가 잘못된 정보를 입력했을 때 처음부터 다시 입력할 필요가 없도록 입력한 정보를 view에 그대로 남아있게 해주는 것이다.

예시

1. Spring Form Tag Library

사용자의 입력 내용을 web form에 바인딩해야 한다.
- Spring은 data binding-aware tags 세트를 제공한다.
- 즉, 알아서 사용자가 입력했던 내용을 매칭해서 그려준다.
‘spring form tag library’의 태그를 사용하려면 JSP 페이지의 맨 위에 다음 지시문을 추가해야 한다.
- <%@ taglib prefix="sf" uri="http://www.springframework.org/tags/form"%>
- prefix=”sf”: 내가 원하는 약어 설정

Spring form tag lib	HTML
`<sf:form>`	<form>
`<sf:input>`	<input type=”text”>
`<sf:password>`	<input type=”password”>
`<sf:checkbox>`	<input type=”checkbox”>

2. Revised JSP and Error Message

‘spring form tag library’ 태그 사용 지시문 선언
‘spring form tag’ 사용
‘spring form tag’ 사용
- <sf:errors> 태그는 유효성 검사 후 BindingResult 객체로부터 받은 error message를 HTML에 랜더링한다.
Model에 들어 있는 model attribute의 이름
- 빈 객체로 넘어온 offer이라는 이름의 model attribute(Offer 객체)에 사용자가 입력한 데이터를 넣기 위한 설정
name=”name” -> path=”name”으로 사용
- Offer 객체의 어떤 속성과 binding 할지를 명시

전체 과정

[Spring] Spring UTF8 한글 설정하기

Tue, 01 Jan 2019 00:00:00 +0000

오류 내용

spring 프로젝트에서 한글이 깨짐

한글이 깨지는 이유
- 보통 브라우저 —> 서버 —> DBMS 로 같은 내용의 한글이 서비스 처리를 하는 단계에서 매번 다른 문자코드를 사용하여 재표현되기 때문이다.
한글을 올바르게 표현하는 방법
- GET와 POST 방식이 다르다.
- GET
  - 3 이용
  - 데이터가 GET방식에서는 요청정보 Header의 URI에 포함되어 전달된다.
  - 서블릿의 영역 밖에 존재한다.
  - URI에 대해 인코딩 처리 작업
- POST
  - 1 + 2 이용
  - 데이터가 POST방식에서는 요청정보 Body에 포함되어 전달된다.
  - 서블릿에서 어느 정도 컨트롤이 가능하다.

해결 방법

1. [POST 방식] 스프링 웹 프로젝트 web.xml에 utf-8 설정

<filter> 
    <filter-name>encodingFilter</filter-name> 
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> 
    <init-param> 
       <param-name>encoding</param-name> 
       <param-value>UTF-8</param-value> 
    </init-param> 
    <init-param> 
       <param-name>forceEncoding</param-name> 
       <param-value>true</param-value> 
    </init-param> 
 </filter> 
 <filter-mapping> 
    <filter-name>encodingFilter</filter-name> 
    <url-pattern>/*</url-pattern> 
 </filter-mapping> 

Spring Web Project - POST 방식에서의 한글 깨짐 해결 방법
역할
- 브라우저 —> 요청정보 Body 데이터 —UTF8 인코딩—> Java 단에서의 데이터 처리
- CharacterEncodingFilter
  - HTTP상에서 주고 받는 데이터의 헤더값을 UTF-8로 인코딩
- Servlet에서의 request.setCharacterEncoding("utf-8");
  - POST로 인코딩 데이터를 받는 Servlet에서의 request.setCharacterEncoding("utf-8"); 처리와 동일한 기능을 수행한다.
  - 즉, 이 Filter를 설정하면 POST 요청을 보내는(Submit) 모든 Controller(Servlet) 마다 request.setCharacterEncoding("utf-8"); 내용을 추가하지 않아도 된다.
- 또한 DB에서 불러올 한글 데이터들의 한글 깨짐 현상을 해결한다.
사용
- 해당 filter를 매핑할 때 모든 URL에 대해 인코딩될 수 있도록 /*와 같이 url-pattern을 설정한다.
- 주의!) Spring Security 설정이 있는 경우,
  한글 필터 설정이 springSecurityFilterChain 앞에 위치해야 한다.

2. [POST 방식] .jsp 파일에 utf-8 설정

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" language="java" %>

Spring Web Project - POST 방식에서의 한글 깨짐 해결 방법
역할
- 응답정보 Body 데이터(JSP 내의 Java 코드 + HTML) —UTF8 인코딩—> 브라우저
  - JSP의 인코딩 방식이 무엇인지 알 수 있게 선언하는 것
  - jsp 파일에서의 한글 깨짐이 해결된다.
- Servlet에서의 response.setContentType("text/html;charset=UTF-8");
  - Servlet에서의 response.setContentType("text/html;charset=UTF-8"); 처리와 유사한 기능을 수행한다.
  - Servlet/JSP 단에서의 설정 방벙의 차이점은
    아래의 참고2) dispatcher-servlet.xml에서의 설정과 차이점을 참고하자.
참고1) 왜 UTF-8 이 두 번 선언이 되어 있을까
- contentType: 서버에서 생성될 HTML의 charset에 대한 정보
- pageEncoding: JSP 내의 Java 코드에 대한 charset에 대한 정보
참고2) dispatcher-servlet.xml에서의 설정과 차이점

<!-- dispatcher-servlet.xml에서의 설정 (Servlet/JSP 단에서의 설정) 예시 -->
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
	<property name="prefix" value="/WEB-INF/views/"/>
	<property name="suffix" value=".jsp"/>
  <property name="contentType" value="text/html; charset=UTF-8"/>
</bean>

Servlet/JSP 단에서의 설정

dispatcher-servlet.xml에서의 설정은 Servlet 단에서의 설정을 의미한다.

.jsp 파일 상의 page 설정은 JSP 단에서의 설정을 의미한다.

Servlet/JSP 단에서의 설정 방법의 차이

JSP 디폴트 contentType: ISO-8859-1

아무리 Servlet에서 response.setContentType 결정해서 보내더라도 .jsp page 자체의 contentType은 jsp spec에서 결정되므로 직접 기술해주지 않으면 ISO-8859-1로 설정된다.

Servlet 단에서의 설정은 JSP가 아닌 텍스트 리턴 시에만 이용된다.

따라서, 직접 .jsp page에 기술하는 것이 좋다.

POST 방식에서의 한글 처리 추가 설명 (Servlet에서 한글처리)

@WebServlet("/loginServlet")
public class LoginServlet extends HttpServlet {
    // ... 생략
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        /* 요청정보 Body에 있는 문자열들을 인자값으로 지정한 문자코드로 인코딩한다. */
        request.setCharacterEncoding("UTF-8");
        
        //getParameter는 중복되지 않고 유일하게 하나만 넘어올 떄 사용된다.
        String username = request.getParameter("username");
        String password = request.getParameter("password");

        /* 응답정보 문자열들을 인자값으로 지정한 문자코드로 인코딩한다.  */
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();

        String htmlResponse = "<html>";
        htmlResponse += "<head><title>Query 문자열 한글 테스트</title></head>";
        htmlResponse += "<h2> your name is " + username + "<br/>";
        htmlResponse += "<h2> your password is " + password + "<br/>";

        out.println(htmlResponse);
    }
}

request.setCharacterEncoding() 메서드 역할
- 브라우저 —> 요청정보 Body 데이터 —UTF8 인코딩—> Java 단에서의 데이터 처리
  - 1번 [POST 방식] 스프링 웹 프로젝트 web.xml에 utf-8 설정 과정에 해당한다.
- 한글 처리를 해주는 메서드는 HttpServletRequest의 상위 객체인 ServletRequest에서 제공하는 setCharacterEncoding() 메서드이다.
- setCharacterEncoding(“UTF-8”) 메서드는 클라이언트가 전달한 요청정보 Body에 있는 데이터(문자열)들을 메서드 인자값으로 지정한 문자코드(UTF-8)로 인코딩해준다.
request.setCharacterEncoding() 메서드 사용
- Java 단에서 데이터를 받아오기 전((getParameter() 메서드)에 인코딩을 처리한다.
- 즉, getParameter() 메서드 위에서 사용해야 한다.
```
request.setCharacterEncoding("UTF-8");
request.getParameter("param")
```
response.setContentType() 메서드 역할
- 응답정보 Body 데이터(Text 데이터) —UTF8 인코딩—> 브라우저
  - 2번 [POST 방식] .jsp 파일에 utf-8 설정 과정에 해당한다.
- response.setContentType(“text/html;charset=UTF-8”) 메서드는 클라이언트에 전달할 응답정보 Body에 있는 데이터(문자열)들을 메서드 인자값으로 지정한 문자코드(UTF-8)로 인코딩해준다.

response.setContentType() 메서드 사용

html을 출력하는 메서드 위에서 사용해야 한다.

response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
String htmlResponse = "<html><head><title>한글 테스트</title></head></html>";
out.println(htmlResponse);

3. [GET 방식] Tomcat 서버의 환경 설정 파일 server.xml에 utf-8 설정

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443" URIEncoding="UTF-8" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" />

Web Project - GET 방식에서의 한글 깨짐 해결 방법
- GET 방식으로 전달된 질의 문자열들은 URI에 포함되어 전달되기 때문에 URI에 대해 인코딩 처리 작업을 해야한다.
- 서버마다 기본적으로 URI 인코딩 문자코드가 정해져 있으며 톰캣8 버전에서는 UTF-8 문자코드가 기본값으로 적용된다.
Servers(아파치 톰캣)의 해당 프로젝트 config 폴더 > server.xml 파일 > URIEncoding="UTF-8" property를 추가한다.
- 서버에서 직접 URI를 UTF-8로 인코딩하는 과정

4. .html 파일에 utf-8 설정

<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
	<title>Home</title>
</head>

head 태그 영역을 위와 같이 설정한다.
- 최신 IDE(통합 개발 환경)를 사용한다면 기본적인 인코딩 방식은 UTF-8로 설정이 되어있다.
- 하지만 Windows 운영체제는 기본 인코딩 값으로 여전히 euc-kr방식을 사용하기 때문에, 해당 페이지의 인코딩 방식(utf-8)이 무엇인지 브라우저가 알 수 있게 선언해야 한다.
사용
- HTML5의 경우
  - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">를 head 태그 안에 삽입
- XHTML의 경우
  - <meta charset="utf-8">를 head 태그 안에 삽입

References

https://github.com/seungjin-shin/Treeze/issues/1

http://jijs.tistory.com/entry/Spring-Framework-에서-UTF8-한글-설정

https://blog.hanumoka.net/2018/04/18/spring-20180418-spring-set-korean/

http://egloos.zum.com/springmvc/v/513986

https://ofcourse.kr/html-course/%EC%9D%B8%EC%BD%94%EB%94%A9

인코딩 중복

POST/GET에 따라 다른 한글 깨짐 처리 방법

Servlet/JSP에서의 response.setContentType

Heee's Development Blog

[JUnit] JUnit5 사용법 - Parameterized Tests

Maven Dependencies

Parameterized Tests

1. Simple Value

2. Null and Empty Values

3. Enum

4. Method

관련된 Post

References

[JUnit] JUnit5 사용법 - 기본

Maven Dependencies

1. 기본 Annotation

@BeforeAll and @BeforeEach

@DisplayName and @Disabled

@AfterEach and @AfterAll

2. Assertions and Assumptions

Assertions

Assumptions

3. Exception Testing

4. Test Suites

5. Dynamic Tests

6. ETC

관련된 Post

References

[IntelliJ] intellij에서 JPA Entitiy 기반의 ERD 그리기

Persistence Tab 설정

JPA Entity 기반의 ERD 확인하기

기본적인 ER Diagram 확인

조금 더 상세한 ERD 확인

[JPA] 값 타입(2) - 컬렉션 타입

Goal

JPA의 최상위 데이터 타입 분류 (2가지)

1. 엔티티 타입

2. 값 타입

구체적인 데이터 타입 분류 (3가지)

3. 값 타입 컬렉션(collection value type)

구현 예시

예제

컬렉션 값 타입 저장

컬렉션 값 타입 조회

컬렉션 값 타입 수정

값 타입 컬렉션의 제약사항

값 타입 컬렉션 대안

대안에 대한 예시 코드

정리

관련된 Post

Reference

[JPA] 값 타입(1) - 기본값 타입, 임베디드 타입

Goal

JPA의 최상위 데이터 타입 분류 (2가지)

1. 엔티티 타입

2. 값 타입

구체적인 데이터 타입 분류 (3가지)

1. 기본값 타입

종류

특징

참고

2. 임베디드 타입 (embedded type, 복합 값 타입)

예시

특징 및 장점

기본 사용법

임베디드 타입과 테이블 매핑

임베디드 타입과 연관관계

값 타입과 불변 객체

값 타입 공유 참조의 부작용

값 타입 복사

객체 타입의 한계

불변 객체 (Immutable Object)

값 타입의 비교

관련된 Post

Reference

[JPA] 양방향 연관관계란

양방향 연관관계와 연관관계의 주인

양방향 연관관계

예제

연관관계 주인과 mappedBy

객체와 테이블간에 연관관계를 맺는 차이

객체 연관관계 = 2개

테이블 연관관계 = 1개