❑ JPA 엔티티(Entity) 매핑

➤ 엔티티 매핑

JPA의 매핑 애너테이션을 이용하면 데이터베이스의 테이블과 엔티티 클래스를 매핑할 수 있다.

▶️ @Entity

• 엔티티 클래스와 테이블을 자동으로 매핑해준다.
• 이 애너테이션을 붙이면 JPA 관리 대상 엔티티가 된다.
• name attribute를 설정하지 않으면 기본적으로 클래스명과 같은 테이블 명을 매핑한다.
• 테이블 명과 엔티티 클래스 명이 다를 경우 name attribute를 설정해주어야 한다.

▶️ @Table

• 데이터베이스의 테이블 이름을 설정할 때 사용한다.
• name 애트리뷰트를 설정하지 않으면 기본값으로 클래스 이름을 테이블 이름으로 사용한다.
• @Table 은 옵션이고 추가하지 않을 경우 클래스 이름을 테이블 이름으로 사용한다.

⚠️ 주의 사항

• @Table ➡️ 옵션
• @Entity, @Id ➡️ 필수
• 파라미터가 없는 기본 생성자는 필수로 추가해주자

➤ 기본키 매핑

데이터베이스 테이블에 기본키 설정은 필수이다.

JPA에서 기본키 매핑은 @Id 를 필드에 추가해주면 되는데 JPA에서 어떤 방식으로 기본키를 생성할 것인지에 대한 다양한 전략을 지원해준다.

✅ 기본키 직접 할당

애플리케이션 코드 상에서 기본키를 직접 할당해주는 방식이다.

✅ 기본키 자동 생성

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long memberId;

• IDENTITY
  • 기본키 생성을 데이터베이스에 위임한다.
  • 데이터베이스에서 기본키를 생성해주는 대표적인 방식은 MySQL의 AUTO_INCREMENT 기능으로 자동 증가 숫자를 기본키로 사용하는 방식이 있다.
• SEQUENCE
  • 데이터베이스에서 제공하는 시퀀스를 사용해서 기본키를 생성하는 전략이다.
• TABLE
  • 별도의 키 생성 테이블을 사용하는 전략이다.
• AUTO
  • JPA가 데이터 베이스 Dialect에 따라서 적절한 전략을 자동으로 선택한다.

TABLE 전략은 키 생성 전용 테이블을 별도로 만들어야 되고, 키를 조회하고 업데이트할 때 쿼리를 전송해야하기 때문에 성능면에서 떨어진다.

https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html#identifiers-generators-table

▶️ 참고) Dialect란?

Dialect는 JDBC 타입과 SQL 타입 간에 연결하는 역할을 한다.

Dialect를 사용하면 Hibernate 가 특정 관계형 데이터베이스에 최적화된 SQL을 생성할 수 있다.

Hibernate Dialect 클래스를 기반으로 특정 데이터베이스에 대한 쿼리를 만든다.

hibernate dialect 는 프레임워크에 어떻게 hibernate 쿼리를 SQL 쿼리로 바꿀 지에 대한 정보를 제공해준다.

• 적절한 SQL 쿼리를 생성한다.
• 애플리케이션이 두 개 이상의 데이터베이스와 연결되어 있을 경우 특정 데이터베이스와 상호작용할 수 있다.
• 구성 파일에 지정되지 않은 경우에도 데이터베이스 소프트웨어를 기반으로 hibernate 구성 파일 속성에 대한 기본값을 설정한다.

https://www.geeksforgeeks.org/hibernate-sql-dialects/

➤ 필드(멤버 변수)와 칼럼간의 매핑

▶️ @Column

• 필드와 데이터베이스의 칼럼을 매핑해주는 애너테이션이다.
• 이 애너테이션이 없고 필드만 정의되어 있다면 JPA는 기본적으로 이 필드가 테이블의 칼럼과 매핑되는 필드라고 간주하고 @Column 애너테이션에 사용되는 attribute 값은 모두 디폴트로 적용된다.

Attribute

• nullable
  • default : true
  • 칼럼에 null을 허용할지 여부를 설정

• updatable
  • 등록한 이후 칼럼 데이터를 수정할 수 있는지 여부를 지정한다.
  • default : true
• unique
  • 하나의 칼럼에 unique 제약 조건을 설정한다. (중복 허용 x)
  • default : false
• length
  • 칼럼에 저장할 수 있는 문자 길이를 지정한다.
  • default : 255
• name
  • default : 필드 명
  • 필드와 매핑되는 칼럼의 이름이 필드명과 다를 경우 지정해 줄 수 있다.

▶️ @Temporal

• java.util.Date, java.util.Calendar 타입을 매핑하기 위해서 이 애너테이션을 추가해야 한다.
• LocalDate, LocalDateTime 타입일 경우는 생략가능하다.

▶️ @Transient

• 이 애너테이션을 필드에 추가하면 테이블 칼럼과 매핑하지 않는다.
• 데이터베이스에 저장하지 않고 조회할 때도 매핑되지 않는다.
• 주로 임시 데이터를 메모리에서 사용하기위한 용도로 사용된다.

▶️ @Enumerated

• enum 타입과 칼럼을 매핑할 때 사용한다.
• Attribute
  • EnumType.ORDINAL : enum의 순서를 나타내는 숫자를 테이블에 저장한다.
  • EnumType.STRING : enum의 이름을 테이블에 저장한다.

⚠️ 주의

EnumType.ORDINAL 로 지정할 경우

기존에 정의되어 있는 enum 사이에 새로운 enum을 추가한다면 그때부터 테이블에 이미 저장되어 있는 enum 순서 번호와 enum 에 정의되어 있는 순서가 일치하지 않게 되는 문제가 발생한다.

@Column doc

https://docs.oracle.com/javaee/7/api/

❑ 엔티티 간의 연관관계 매핑

➤ 연관관계 매핑이란?

엔티티 클래스 간의 관계를 만들어 주는 것이다.

엔티티 간의 참조할 수 있는 객체수에 따라서

일대다(1:N), 다대일(N:1), 다대다(N:N), 일대일(1:1) 관계로 나눌 수 있다.

➤ 단방향 연관 관계

한 쪽 클래스만 다른 쪽 클래스의 참조 정보를 가지고 있는 관계

➤ 양방향 연관 관계

양 쪽 클래스 모두 서로의 객체를 참조 정보를 가지고 있는 관계

JPA는 단방향, 양방향 연관 관계 모두 지원하지만 Spring Data JDBC는 단방향 연관 관계만 지원한다.

➤ 일대다(1:N) 단방향 연관 관계

일(1)에 해당하는 클래스가 다(N)에 해당하는 객체를 List 등을 사용해서 참조할 수 있다.

일대다 단방향 매핑은 잘 사용하지 않는다.

➤ 다대일(N:1) 연관 관계

다(N)에 해당하는 클래스가 일(1)에 해당하는 객체를 참조할 수 있는 관계를 의미한다.

▶️ @ManyToOne

• 이 애너테이션으로 다대일 관계를 명시한다.
• @JoinColumn(name = “MEMBER_ID”)
  • 매핑하는 테이블의 외래키(부모 테이블의 기본키)에 해당하는 칼럼명을 적어준다.

➤ 일대다(1:N) 연관 관계

다대일 연관관계를 설정한 이후에 자식 테이블에도 일대다 관계를 만들어줘서 양방향 관계를 만들어 준다.

▶️ @OneToMany

• 이 애너테이션을 부모테이블에 추가하여 일대다 관계를 만들어준다.

Attribute

• mappedBy
  • 값은 관계를 소유하고 있는 필드(N(다)에 해당하는 필드)를 지정한다.
  • mappedBy는 참조할 대상이 있어야 한다.
  • 일대다 단방향 매핑의 경우에는 필요하지 않다.

➤ 다대다(N:N) 연관 관계

다대다는 관계는 중간에 테이블을 하나 추가해서 두 개의 일대다 관계로 만들어주는 것이 일반적이다.

➤ 엔티티 간의 연관 관계 매핑 권장 방법

• 일대다 매핑은 사용하지 않는다.
• 제일 먼저 다대일 단방향 매핑부터 적용한다.
• 다대일 단방향 매핑을 통해 객체 그래프 탐색으로 조회할 수 없는 정보가 있을 경우, 양방향 매핑을 적용한다.

➤ Cascading

부모테이블에서 자식테이블로 데이터의 상태 변화를 전파(?)할 때 사용한다.

JPA javax.persistence.CacadeType 에 정의되어 있다.

부모 테이블의 @OneToMany 애너테이션에 Attribute로 추가한다.

@OneToOne(mappedBy = "member", cascade = {CascadeType.PERSIST, CascadeType.REMOVE})
private Stamp stamp;

Attribute

• ALL
• PERSIST
• MERGE
• REMOVE
• REFRESH
• DETACH

읽어주셔서 감사합니다.

오개념에 대한 지적은 늘 환영입니다. 😄

❑ JPA(Java Persistence API)란?

➤ JPA(Java Persistence API)란?

• ORM(Object-Relation Mapping) 기술의 표준 사양(또는 명세, Specification)
• Java의 인터페이스로 사양이 정의되어 있고 JPA라는 표준 사양을 구현한 구현체는 따로 있다.

➤ Hibernate ORM

• JPA 표준 사양을 구현한 구현체 : Hibernate ORM, EcliipseLink, DataNucleus
• Hibernate ORM은 JPA에서 정의해둔 인터페이스를 구현한 구현체 중 하나이다.
• JPA에서 지원하는 기능 이외에도 자체적으로 사용하도록 지원하는 API 도 있다.

※ Jakarta Persistence

Java Persistence API 의 약자이지만 현재는 Jakarta Persistence 라고도 불린다.

2019년에 나온 JPA 3.0 버전 부터 Jakarta Persistence 라는 이름으로 바뀌었다.

Jakarta Persistence 라고 바뀌면서 패키지와 속성도 javax.persistence 에서 jakarta.persistence 로 이름이 바뀌었다.

엔터프라이즈 Java 애플리케이션에서 관계형 데이터 관리를 설명하는 Jakarta EE 애플리케이션 프로그래밍 인터페이스 사양(specification)이다.

➤ 데이터 액세스 계층에서의 JPA 위치

데이터 액세스 계층에서 JPA는 상단에 위치한다.

데이터 저장, 조회 등의 작업은 JPA를 거쳐 JPA의 구현체인 Hibernate ORM을 통해서 이뤄진다.

Hibernate ORM은 내부적으로 JDBC API를 이용해서 데이터베이스에 접근한다.

➤ JPA(Java Persistence API)에서 P(Persistence)의 의미

Persistence는 영속성, 지속성이라는 뜻이다.

그렇다면 무엇을 지속시키는 것일까?

엔티티 객체 정보를 지속시킨다는 의미이다.

▶️ 영속성 컨텍스트(Persistence Context)

ORM(Object-relational-mapping)은 객체(Object)와 데이터베이스 테이블의 매핑을 통해 엔티티 클래스 객체 안에 포함된 정보를 테이블에 저장하는 기술이다.

JPA에서는 테이블과 매핑되는 엔티티 객체 정보를 영속성 컨텍스트(Persistence Context)라는 곳에 보관해서 애플리케이션 내에서 오래 지속되도록 한다.

엔티티 정보는 데이터베이스 테이블에 데이터를 저장, 수정, 조회, 삭제하는데 사용된다.

JPA API 중 엔티티 정보를 영속성 컨텍스트에 저장(persist)하는 API를 사용하면 영속성 컨텍스트의 1차 캐시에 엔티티 정보가 저장된다.

JPA 영속성 컨텍스트

• EntityManager 클래스에 의해서 관리된다. -> EntityManagerFactory 객체를 Spring으로부터 DI 받을 수 있다.
• EntityManagerFactory의 createEntityManager() 메서드를 이용해서 EntityManager 객체를 얻을 수 있다. -> JPA API 메서드 사용 가능
• persist() 메서드: 영속성 컨텍스트에 객체의 정보들이 저장된다.
• 저장되었는지 확인하려면 find(조회할 엔티티 클래스의 타입, 조회할 엔티티 클래스의 식별자 값) 메서드 사용

➤ JPA API로 영속성 컨텍스트 이해하기

▶️ JPA API를 사용하기 위한 사전 준비

✅ build.gradle 설정

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	compileOnly 'org.projectlombok:lombok'
	runtimeOnly 'com.h2database:h2'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

Spring Data JPA 기술을 포함한 JPA API를 사용할 수 있다.

✅ application.yml에 아래 코드 추가

jpa:
	hibernate:
		ddl-auto: create  # (1) 스키마 자동 생성
	show-sql: true      # (2) SQL 쿼리 출력

※ yml에서 추가한 코드가 제대로 적용되지 않을 때는 공백 레벨을 잘 확인해보자.

Spring Data JDBC에서는 schema.sql 파일에 테이블 생성을 위한 스키마를 직접 작성해주어야 하지만 JPA는 (1)의 코드 하나를 추가함으로써 JPA가 자동으로 데이터베이스에 테이블을 생성해 준다.

▶️ @GeneratedValue

식별자를 생성해주는 전략을 지정할 때 사용

이 애너테이션을 엔티티의 멤버 변수에 추가하면 데이터베이스 테이블에서 기본키가 되는 식별자를 자동으로 설정해준다.

▶️ 영속성 컨텍스트에 저장하기

persist() 를 호출 -> 1차 캐시에 객체가 저장되고, 객체가 쓰기 지연 SQL 저장소에 INSERT 쿼리 형태로 등록이 된다.

영속성 컨텍스트에 객체를 저장하지만 실제 테이블에 정보를 저장하지는 않는다.

JPA가 내부적으로 테이블을 자동으로 생성하고, 테이블의 기본키를 할당해준다.

▶️ 데이터베이스 테이블에도 데이터 저장하기

EntityManager의 getTrancsation() 메서드를 이용하여 Transaction 객체를 얻는다.

(JPA에서는 Transaction 객체를 기준으로 DB 테이블에 데이터를 저장한다.)

Transaction을 시작하기 위해서 begin() 메서드 사용

➡️ persist() 로 객체를 영속성 컨텍스트에 저장

➡️ commit() 메서드 호출하여 영속성 컨텍스트에 저장되어 있는 객체를 DB 테이블에 저장한다.

✔️ persist() : 영속성 컨텍스트의 1차 캐시에 엔티티 클래스의 객체가 저장 + ‘쓰기 지연 저장소’에 INSERT 쿼리가 등록

✔️ commit() : ‘쓰기 지연 SQL 저장소’에 등록된 모든 INSERT 쿼리가 실행 + 실행된 INSERT 쿼리는 쓰기 지연 SQL 저장소에서 제거됨

✔️ find() : 1차 캐시에서 해당 객체가 있는지 조회하고, 없으면 테이블에 SELECT 쿼리를 전송해서 조회

➤ 영속성 컨텍스트와 테이블에 엔티티 업데이트

find() 메서드로 1차 캐시에 저장된 객체를 불러와서 객체에 setter로 데이터를 변경

commit() 메서드로 SQL 저장소에 등록된 UPDATE 쿼리가 실행된다.

✅ setter 메서드로 값을 변경만 해도 commit() 시점에 UPDATE 쿼리가 실행되는 이유?

영속성 컨텍스트에 엔티티가 저장될 경우 저장되는 시점의 상태를 그대로 가지고 있는 스냅샷을 생성한다.

그 후 엔티티의 값을 setter 메서드로 변경한 후, commit()을 하면 변경된 엔티티와 이전에 이미 떠 놓은 스냅샷을 비교한 후 변경된 값이 있으면 쓰기 지연 SQL 저장소에 UPDATE 쿼리를 등록하고 UPDATE 쿼리를 실행

➤ 영속성 컨텍스트와 테이블의 엔티티 삭제

EntityManager의 remove() 메서드를 통해 1차 캐시에 있는 엔티티를 제거하도록 요청

Transaction의 commit() 을 실행하면 영속성 컨텍스트에 1차 캐시에 있는 엔티티를 제거하고, 쓰기 지연 SQL 저장소에 등록된 DELETE 쿼리가 실행된다.

▶️ EntityManager의 flush() API

transaction의 commit() 메서드를 호출하면 JPA 내부적으로 flush() 메서드가 호출되어 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.

※ 추가로 학습해야할 자료들

JPA와 Hibernate 에서 Entity Lifecycle Model

https://thorben-janssen.com/entity-lifecycle-model/

읽어주셔서 감사합니다.

오개념에 대한 지적은 언제나 환영입니다. 😄

❑ Spring Data JDBC를 통한 데이터 액세스 계층 구현 (서비스, 레포지토리 구현)

➤ Repository Interface

Spring Data JDBC, Spring Data JPA에서 데이터 액세스 계층에서 데이터베이스와 상호작용하는 역할을 하는 인터페이스를 repository라고 한다.

기본적으로 CrudRepository를 상속하는 repository 인터페이스 작성한다.

ex) public interface MemberRepository extends CrudRepository<Member, long> { }

CrudRepository 인터페이스를 통해 데이터를 데이터베이스 테이블에 저장, 조회, 수정, 삭제가 가능하다.

➤ 쿼리 메서드(Query Method)

Spring Data JDBC에서 쿼리 메서드(Query Method)를 지원한다.

✅ ‘find + By + SQL 쿼리문에서 WHERE 절의 칼럼명 + (WHERE 절 칼럼의 조건이 되는 데이터)’

형식으로 쿼리 메서드(Query Method)를 정의하면 조건에 맞는 데이터를 테이블에서 조회한다.

ex) findByName(String name);

리턴값으로 SQL 질의를 통한 결과 데이터를 받아서 엔티티 클래스의 객체로 지정해준다.

그리고 Spring Data JDBC 에서 Optional을 지원하기 때문에 리턴값을 Optional로 래핑해준다.

래핑해주는 이유는?

Optional을 사용해서 리턴값을 래핑하면 Service 클래스에서 이 Optional을 이용해서 코드를 더 효율적이고 간결하게 구성할 수 있다.

WHERE 절의 조건 칼럼을 여러 개 지정하고 싶다면 ‘And’를 사용하면 된다.

ex) findByPhoneAndName(String phone, String name);

쿼리 메서드에 작성한 칼럼명은 내부적으로 테이블의 칼럼명으로 바뀌지만

Spring JDBC 입장에서는 엔티티 클래스를 바라보고 작업한다.

반드시 엔티티 클래스의 멤버 변수명을 적어주어야 한다.

테이블의 칼럼명으로 적는다. ❌

(단어를 일치시키면 가장 좋지만 Java에서는 CamelCase 표기법을 사용하고 테이블 칼럼명은 언더스코어(_) 표기법을 사용하기 때문에 2 단어 이상 작성시 이름이 다를 수 있다.)

➤ @Query 메서드

쿼리 메서드명에 작성하지 않고 직접 쿼리문을 작성해서 질의를 할 경우 사용

Attribute로 쿼리문을 작성한다.

동적 쿼리 파라미터(named parameter)

콜론(:) 뒤에는 findBy~()의 괄호안에 동적 쿼리 파라미터(named parameter)를 작성해준다.

ex) @Query(“SELCET * FROM ORDER WHERE ORDER_ID = :orderId”);

단순한 쿼리의 경우 쿼리 메서드를 이용하는 것이 간결한 코드 유지와 생산성 면에서 바람직하다.

➤ Repository 인터페이스 Service 에서 사용하기

Service에서 DI를 주입해서 Repository 생성

Repository는 인터페이스인데 구현 클래스를 작성하지 않았지만 사용 가능하다.

Repository 인터페이스 구현 클래스는 Spring Data JDBC에서 내부적으로 Java 리플렉션 기술과 Proxy 기술을 이용해서 repository 인터페이스의 구현 클래스 객체를 생성해준다.

비즈니스 로직에서 어떤 검증이 필요한 로직은 검증하는 로직을 추출해서 메서드를 작성 후 호출한다. ➡️ 코드의 간결성, 가독성 향상

ex) 회원 정보 리소스를 데이터베이스에 Insert할 경우 이미 Insert된 리소스인지 여부를 검증하는 로직 분리 (findVerifiedMember)

✅ Optional.ofNullable(...)

파라미터로 전달받은 엔티티 클래스 객체는 클라이언트 쪽에서 선택적으로 수정할 수 있기 때문에 멤버 변수에 null 이 있을 수도 있다.

이처럼 멤버 변수 값이 null 일 경우

Optional.of()가 아닌 Optional.ofNullable()을 이용해서 null 값을 허용할 수 있다.

null 이더라도 NullPointerException이 발생하지 않고 원하는 다음 메서드를 호출할 수 있다.

ifPresent() 메서드를 이용해서 null 값이 아니라면 코드가 실행 되도록 작성한다. (람다식으로 작성)

이 때 값이 null 이라면 실행되지 않는다.

ex) Optional.ofNullable(coffee.getName).ifPresent(name -> findCoffee.setName(name));

✅ delete 를 사용하여 회원 정보 삭제 ?

실무에서는 회원 정보 자체를 테이블에서 삭제하기 보다 MEMBER_STATUS 같은 칼럼을 두어 상태 값만 변경한다.

회원의 회원 가입 상태를 ‘가입’ , ‘휴면’ , ‘탈퇴’ 등의 상태 정보로 나누어 관리하는 것이 바람직하다.

✅ orElseThrow()

Optional의 메서드인 orElseThrow()를 이용하면 해당 객체가 null 이 아닐경우에는 해당 객체를 리턴하고 null 이라면 괄호 안의 예외를 던진다.

✅ 참고) @Builder

Lombok에서 지원

Builder를 사용하고자 하는 클래스 위에 @Builder 애너테이션을 추가한다.

객체를 생성할 때 빌더를 함수를 통해 호출하고 셋팅하고자 하는 필드값을 하나씩 지정해주고 마지막에 build()로 닫아서 작동시킨다.

생성자 파라미터가 많을 경우 builder를 사용하면 가독성이 좋아진다.

자기 자신을 리턴하기 때문에 체인형식으로 생성해줄 수 있다.

최종적으로 build()를 해야 만들어진다.

Member.builder()
	.name("김아무개")
   	.city("서울")
   	.email("kim123@gmail.com")
   	.phone("010-1111-2222")
   	.build();

https://projectlombok.org/features/Builder

읽어주셔서 감사합니다. ^^ 좋은하루 보내세요.

오개념에 대한 지적은 늘 환영입니다.

❑ JDBC 기반 데이터 액세스 계층

➤ JDBC란?

JDBC(Java Database Connectivity)

Java 기반 애플리케이션의 코드 레벨에서 사용하는 데이터를

데이터베이스에 저장, 업데이트 하거나

데이터베이스에 저장된 데이터를 Java 코드 레벨에서 사용할 수 있게

해주는 Java에서 제공하는 표준 API이다.

JDK 1.1 버전부터 제공됐다. 엄청 오래됐다..!

데이터베이스 액세스를 위해 Java에서 제공하는 API라고 보면 된다.

다양한 벤더(Oracle, MS SQL, MySQL 등)의 데이터베이스와 연동할 수 있다.

etc..

• Java 기반의 애플리케이션에서 사용하는 데이터 액세스 기술의 기본이 되는 저수준(low level) API 이다.
• Spring에서는 JDBC API를 직접 사용하기 보다는 Spring Data JDBC, Spring Data JPA 같은 기술이 편리해서 더 많이 사용한다. (Spring Data JDBC나 Spring Data JPA가 더 편리해서 현업에서는 JDBC를 많이 쓰지 않지만 예전 기술로 만든 애플리케이션을 그대로 사용할 경우 Spring JDBC를 사용할 수도 있다.)
• Spring Data JDBC나 Spring Data JPA 같은 기술도 내부적으로 JDBC를 이용하기 때문에 JDBC의 흐름정도는 알면 데이터 액세스 기술을 구현하는데 도움이 된다.

➤ JDBC의 동작 흐름

▶️ JDBC 드라이버(JDBC Driver)

JDBC 드라이버는 Database와의 통신을 담당하는 인터페이스이다.

Oracle, MS SQL, MySQL 등에서 해당 벤더에 맞는 JDBC 드라이버를 구현해서 제공을 한다.

JDBC 드라이버 구현체를 이용해서 특정 벤더의 Database에 액세스 할 수 있다.

➤ JDBC API 사용 흐름

1. JDBC 드라이버 로딩

사용하고자 하는 JDBC 드라이버를 로딩한다.

JDBC 드라이버는 DriverManager라는 클래스를 통해서 로딩된다.

2. Connection 객체 생성

JDBC 드라이버가 정상적으로 로딩되면 DriverManager를 통해 데이터베이스와 연결되는 세션(Session)인 Connection 객체를 생성한다.

3. Statement 객체 생성

Statement 객체는 작성된 SQL 쿼리문을 실행하기 위한 객체이다.

객체 생성 후에 정적인 SQL 쿼리 문자열을 입력으로 가진다.

4. Query 실행

생성된 Statement 객체를 이용하여 입력한 SQL 쿼리를 실행한다.

5. ResultSet 객체로부터 데이터 조회

실행된 SQL 쿼리문에 대한 결과 데이터 Set으로 부터 데이터를 조회한다.

6. ResultSet 객체 Close, Statement 객체 Close, Connection 객체 Close

JDBC API 를 통해 사용된 객체들은 사용이 끝나면 실행한 역순으로 차례대로 Close 해준다.

➤ Connection Pool 이란?

데이터베이스와의 연결을 위한 Connection 객체를 생성하는 작업은 비용이 많이 드는 작업이다.

왜 그런지는 아래 MySQL에서 제공하는 페이지를 들어가서 보면 알 수 있다.

https://dev.mysql.com/doc/refman/8.0/en/insert-optimization.html

효율을 위해서 Connection Pool에서 Connection을 미리 만들어서 보관한다.

그리고 애플리케이션이 필요할 때마다 이 Connection 객체를 제공하는 역할을 한다. (Connection 관리자)

애플리케이션 로딩 시점에 Connection 객체를 미리 생성해두고

애플리케이션에서 데이터베이스에 연결이 필요할 때마다

Connection 객체를 생성하지 않고(비용이 많이 듬)

미리 만들어둔 Connection 객체를 사용한다.

-> 애플리케이션의 성능 향상

Spring Boot 2.0 이전 버전에서는 Apache 재단의 오픈 소스인 Apache Commons DBCP(Database Connection Pool, DBCP)를 주로 사용했다.

2.0 이후 부터는 성능면에서 더 나은 HikariCP를 기본 DBCP로 채택했다.

※ 추가학습) HikariCP 란?

• Brett Wooldridge가 2012년에 개발한 JDBC Connection Pool이다.
• 가볍고 빠르고 안정적이다. (히카리는 일본어로 빛 광이다.)
• Spring Boot 2.0부터 default DBCP로 채택되었다.

https://github.com/brettwooldridge/HikariCP

※ 추가학습) JDBC 장단점

- 장점

• 깨끗하고 심플한 SQL 처리가 가능하다
• 용량이 큰 데이터에서 우수한 성능을 보인다
• 구현하기 쉽다
• 작은 애플리케이션에서 아주 좋은 성능을 보인다

- 단점

• 대형 프로그래밍에서 많은 비용, 시간이 든다
• OOP의 구현이 지원되지 않는다
• JDBC를 이용한 MVC 패턴 구현이 어렵다
• JDBC에서 사용되는 쿼리문은 database에 한정된다
• 예외 처리를 위한 try, catch, finally 블록에 모든 것을 작성해야 한다.
• 개발자가 connection을 닫지 못하면 JDBC가 자동으로 connection을 닫지 않아 문제가 발생할 수 있다.
• 많은 곳에 SQL 쿼리문을 작성해야하고 일단 프로그램이 작성되면 테이블 구조를 수정할 수 없다.
• JDBC는 데이터베이스에 특정 오류코드를 생산하고 개발자는 데이터베이스의 오류 코드에 대해 전혀 알지 못 할수 있다.
• JDBC를 사용하면 Java 객체를 DB 객체로 변환하거나 그 반대로 변환하므로 변환 및 역변환에 많은 시간이 소요되어 프로세스가 느려질 수 있다.

출처 : 

https://techxyte.com/tutorials/hibernate/pros-and-cons-of-jdbc.php

❑ Spring Data JDBC 란?

➤ Data Access 

Spring 에서 데이터베이스에 액세스하는 다양한 기술을 사용할 수 있다.

대표적인 데이터 액세스 기술: mybatis, Spring JDBC, Spring Data JDBC, JPA, Spring Data JPA 

Spring에서 사용하는 데이터베이스 액세스 기술은 크게 두 가지로 나눌 수 있다.

➤ SQL 중심 기술

• mybatis와 Spring JDBC가 대표적
• 애플리케이션에서 데이터베이스에 접근하기 위해 SQL 쿼리문을 애플리케이션 내부에 Java 코드로 직접적으로 작성하는 것
• 과거부터 현재까지 많이 사용하고 있지만 Java 진영에서는 SQL 중심보다 객체(Object) 중심의 기술로 지속적으로 이전하고 있는 추세이다.

mybatis 에서 사용하는 SQL Mapper 예시

<select id="findMember" resultType="Member">

  SELECT * FROM MEMBER WHERE member_id = #{memberId}

</select>

Spring JDBC의 JdbcTemplate 사용 예

Member member = this.jdbcTemplate.queryForObject(

"select * from member where member_id=?", 1, Member.class);

➤ 객체(Object) 중심 기술

• 모든 데이터를 객체(Object) 관점으로 바라보는 기술이다.
• SQL 쿼리문을 직접적으로 작성하기 보다 Java 객체를 이용해 애플리케이션 내부에서 Java 객체를 SQL 쿼리문으로 자동 변환해준다.
• ORM(Object-Relational Mapping) 이라고 한다.
• Java 에서 대표적 ORM 기술 : JPA(Java Persistence API), Spring Data JDBC

➤ Spring Data JDBC란?

• 심플하다.
• Spring Data JDBC는 ORM 기술을 사용하지만 JPA의 기술적 복잡도를 낮춘 기술이다.

▶️ Spring Data JDBC vs JPA vs Spring Data JPA

Spring Data JDBC 

• 2018년에 처음 릴리즈 됐다.
• 아직까지는 JPA보다 상대적으로 적게 사용된다.
• 애플리케이션의 규모가 상대적으로 크지 않고, 복잡하지 않을 경우 Spring Data JDBC가 뛰어난 생산성을 보여준다.

JPA

• 실무에서 가장 많이 사용하고 있는 기술이다.

Spring Data JPA

• Spring Data JPA는 Spring에서 JPA 기술을 편리하게 사용하기 위한 기술이다.
• JPA에 대한 선행 지식이 필요하다.

❑ Spring Data JDBC 실습

➤ 의존 라이브러리 추가

implementation 'org.springframework.boot:spring-boot-starter-data-jdbc'

runtimeOnly 'com.h2database:h2'

Spring Data JDBC를 사용하기 위한 의존 라이브러리 코드 추가

데이터베이스에서 인메모리(In-memory) DB인 H2를 사용하기 위한 의존 라이브러리 설정 추가

▶️ 인메모리(In-memory) DB란?

메모리 안에 데이터를 저장하는 데이터베이스이다.

메모리는 휘발성이라 컴퓨터 전원을 껐다가 켜면 메모리에 저장되어 있는 데이터는 모두 지워진다.

인메모리 DB는 애플리케이션이 실행되는 동안에만 데이터를 저장하고 있다.

테스트에 필요한 데이터 외에는 테이블에 없는 것이 테스트의 정확도 면에서 유리하기 때문에 인메모리 DB를 사용한다.

로컬 개발 환경에서는 테스트가 끝나면 테이블을 비우는 것이 좋다.

▶️ application.yml파일에 H2 Browser 활성화 설정 추가

Spring Boot Initializr을 통해 샘플 프로젝트 생성 -> src/main/resources 에 application.properties 또는 appication.yml 파일을 통해 Spring 에서 사용하는 다양한 설정 정보들을 입력

application.yml로 확장자 변경 후 아래 코드 입력

spring:

  h2:

    console:

      enabled: true

<애플리케이션 실행 시 콘솔 창>

HikariPool-1 - Starting...

HikariPool-1 - Start completed.

H2 console available at '/h2-console'. Database available at 'jdbc:h2:mem:97f0b3b1-369a-498d-9abe-633d5d10acaa'

<웹 브라우저>

localhost:8080/h2-console

주소창에 입력후 엔터

H2 Browser 초기 화면 나옴

JDBC URL 에 jdbc:h2:mem:97f0b3b1-369a-498d-9abe-633d5d10acaa 입력

-> Connect

▶️ H2 DB 디폴트 설정의 문제점

애플리케이션 재시작 할때마다 애플리케이션 로그에 출력되는 JDBC URL이 매번 랜덤하게 바뀌기 때문에 매번 변경된 JDBC URL을 다시 입력해야 한다.

이 문제는 application.yml 파일에 H2에 대한 설정을 추가해서 해결한다.

jdbc:h2:mem:test 로 설정

spring:

  h2:

    console:

      enabled: true

      path: /h2     # (1) Context path 변경

  datasource:

    url: jdbc:h2:mem:test     # (2) JDBC URL 변경

주소창에

localhost:8080/h2 로 접속

▶️ PostMan 으로 Post

Post 하고 body 에 JSON 형식으로 message 값 전달

➡️ 오류 발생! ➡️ Message 테이블이 생성되지 않았음

읽어주셔서 감사합니다. 좋은 하루 되세요 😄

❑ 비즈니스 로직 예외 던지기(throw) 및 예외 처리

➤ 체크 예외(Checked Exception)와 언체크 예외(Unchecked Exception)

애플리케이션에서 발생하는 예외는 크게 Checked Exception과 Unchecked Exception으로 구분된다.

▶️ Checked Exception

• 발생한 예외를 잡아서(catch) 체크한 후 해당 예외를 복구하거나 회피하거나 하는 등의 구체적인 처리를 해야하는 예외이다.
• 대표적인 예 : ClassNotFoundException

▶️ Unchecked Exception

• 예외를 잡아서(catch) 해당 예외에 대한 어떤 처리를 할 필요가 없는 예외이다.
• 명시적으로 잡아서 어떤 처리를 할 필요는 없다.
• 대표적인 예 : NullPointerException, ArrayIndexOutOfBoundsException

코드를 잘못 작성해서 생기는 이런 오류들은 모두 RuntimeException을 상속한 예외들이다.

Java나 Spring에서 수많은 RuntimeException을 지원하지만 RuntimeException을 이용해서

직접 예외(Exception)을 만들어야 하는 경우도 있다.

➤ 의도적으로 예외를 던질 수 (throw) 있는 상황

• 백엔드 서버와 외부 시스템과의 연동에서 발생하는 예외 처리
• 시스템 내부에서 조회하려는 리소스(자원)가 없는 경우

의도적으로 예외를 던져서 클라이언트 쪽에 발생한 에러 정보를 알려줄 수 있다.

➤ 의도적인 예외 throw / catch

java에서 throw 키워드는 예외를 메서드 바깥으로 던져준다.

던져진 예외는 메서드 바깥 즉, 메서드를 호출한 지점으로 던져지게 된다.

그렇다면 서비스 계층에서 예외를 던지면 어디로 던져질까?

서비스 계층의 메서드는 API 계층인 Controller의 Handler Method가 이용한다.

-> 서비스 계층에서 던져진 예외는 Controller의 Handler Method 쪽에서 잡아서 처리할 수 있다.

따라서 Controller에서 발생하는 예외 처리를 위한 Exception Advice 클래스에 서비스 계층에서 던진 예외도 작성해서 처리하면 된다.

✅ 서비스 계층에서 의도적으로 던질 수 있는 예외는 1가지만 존재하진 않는다.

예를 들어 아래의 경우 모두 예외 상황이 생길 수 있다.

• 회원 정보가 존재하지 않을 경우
• 회원 등록 시 이미 존재하는 회원일 경우
• 로그인 패스워드 검증에서 일치하지 않는 경우

이럴 때 handle에러이름Exception()과 같이 메서드 이름을 짓는 것은 적절하지 않다.

그리고 추상적인 RuntimeException 을 그대로 전달 받는 것도 바람직 하진 않다.

서비스 계층에서 RuntimeException 을 그대로 throw하고, Exception Advice에서 RuntimeException을 그대로 catch 하는 것은 예외의 의도가 명확하지 않고 구체적으로 어떤 예외가 발생했는지에 대한 정보를 얻는 것이 어렵다.

❑ 사용자 정의 예외(Custom Exception) 사용

ExceptionCode 를 enum으로 미리 직접 작성해둔다.

BusinessLogicException 클래스를 생성하여 RuntimeException을 상속한다.

super() 상위 클래스 생성자로 RuntimeException에 구체적인 예외 정보 (Exception Code)를 던진다.

Exception Advice 클래스에서

메서드 명이 서비스 계층의 비즈니스 로직 처리에서 발생하는 예외를 처리하는 것을 목적으로 한다.

-> handleBusinessLogicException

RuntimeException을 파라미터로 전달 받던 것을 BusinessLogicException을 전달 받는 것으로 변경한다.

@ResponseStatus(HttpStatus.NOT_FOUND) 제거

ResponseStatus는 고정된 HttpStatus를 지정하므로 다양한 Status를 동적으로 처리할 수 없다.

-> 대신 ResponseEntity를 사용해서 커스텀한 예외 코드(상태)를 전달한다.

▶️ @RestControllerAdvice 에서 ResponseStatus vs ResponseEntity

@ResponseStatus : 

한가지 유형으로 고정된 예외를 처리할 경우 HttpStatus를 지정해서 사용

@ResponseEntity :

BusinessLogicException 처럼 다양한 유형의 Custom Exception을 처리하고자 할 경우

▶️ of() 정적 팩토리 메서드

new를 직접 사용하지 않고 클래스의 인스턴스를 생성한다.

장점 : 이름을 통해 객체의 의미를 알 수 있다.

읽어주셔서 감사합니다^^ 좋은하루 되세요 🤗

백엔드 측 애플리케이션은 기본적으로 클라이언트 유형과 무관하게

공통의 정보를 제공하도록 디자인이 되어야 한다.

하지만 특정 클라이언트 유형에 맞는 정보를 추가적으로 제공하기 위한 확장을 고려해야 하는 경우도 빈번하다.

애플리케이션을 설계할 때 기능을 다 넣어서 만들어 버리면 범위가 너무 넓어져서 구현하기 힘들다.

요구사항에 맞춰서 애플리케이션의 기능을 특정 범위까지만 제한하는 것을

“애플리케이션 경계를 설정한다” 고 한다.

❑ Spring MVC Architecture

➤ Spring MVC란?

스프링 모듈 중에 웹 계층*을 담당하는 몇가지 모듈이 있다.

Sevlet API를 기반으로 클라이언트의 요청을 처리하는 모듈도 있다.

이 모듈이 spring-webmvc 이다.

✔️ web layer(웹 계층)?

• Spring MVC layer architecture의 최상위 계층 이다.
• 클라이언트의 요청을 받고 응답을 전달하는 계층이다.
• 다른 계층에서 발생한 예외를 처리한다.
• 인증을 관리하여 권한이 없는 사용자의 인가를 거부하는 역할도 한다.

Spring MVC 레퍼런스

https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html

▶️ Servlet 이란?

클라이언트의 요청을 처리하도록 규약에 맞추어서 Java 코드로 작성하는 클래스 파일이다.

아파치 톰캣(Apache Tomcat)은 이런 서블릿들이 웹 애플리케이션으로 실행이 되도록 해주는 Servlet Container 중 하나이다.

특징

• 클라이언트의 요청에 대해 동적으로 작동하는 웹 애플리케이션 컴포넌트
• html을 사용하여 요청에 응답한다.
• Java Thread를 이용하여 동작한다.
• MVC패턴에서 Controller로 이용된다.
• HTTP 프로토콜 서비스를 지원하는 javax.servlet.http.HttpServlet 클래스를 상속받는다.
• HTML 변경 시 Servlet을 재컴파일해야 하는 단점이 있다.

❑ MVC의 의미

구현하려는 Spring MVC는 계층형 아키텍처에서 API 계층에 해당한다.

➤ Model(M)

MVC에서 M에 해당한다.

클라이언트에게서 받은 요청을 기반으로 처리한 결과인 데이터를 Model이라고 한다.

클라이언트에게 응답으로 Model 데이터를 돌려준다.

➤ View(V)

MVC에서 V에 해당한다.

Model 데이터를 이용해서 클라이언트 애플리케이션의 화면에 보여지는 리소스(Resource)를 제공한다.

Spring MVC에는 다양한 View기술이 포함되어 있다.

• HTML 페이지의 출력
• PDF, Excel 등의 문서 형태로 출력
• XML, JSON 등 특정 형식의 format으로 변환

※ JSON(JavaScript Object Notation)이란?

데이터를 통신하는 포맷 형식 중의 하나이다.

웹 애플리케이션에서 가장 많이 사용한다.

Spring MVC에서 클라이언트 애플리케이션과 서버 애플리케이션이 주고 받을 때 JSON 형식을 사용한다.

과거에는 XML 형식이 가장 많이 사용되었지만 JSON이 상대적으로 가볍고 복잡하지 않아서 대세이다.

기본 포맷 : {“속성”:”값”}

※ 참고) JSON to Java Converter

https://json2csharp.com/code-converters/json-to-pojo

➤ Controller

MVC에서 C에 해당된다.

Controller는 클라이언트 측의 요청을 직접적으로 전달 받는 엔드포인트(Endpoint)이다.

Model과 View의 중간에서 상호 작용을 해주는 역할을 한다.

Model 데이터를 View로 전달하는 역할을 한다.

➤ Model, View, Controller 간의 처리 흐름

Client가 요청 데이터 전송

➡️ Controller가 요청 데이터 수신 ➡️ 비즈니스 로직 처리 ➡️ Model 데이터 생성

➡️ Controller에게 Model 데이터 전달 ➡️ Controller가 View에게 Model 데이터 전달

➡️ View가 응답 데이터 생성

※ Gson 클래스 찾을 수 없는 오류

Gradle 방식

스프링 프로젝트 내에 build.gradle로 들어가서

“dependencies” 에  implementation 'com.google.code.gson:gson:2.9.0' 추가 ➡️ gradle reload

Maven방식

<dependency>

	<groupId>com.google.code.gson</groupId>

 	<artifactId>gson</artifactId>

 	<version>2.9.0</version>

</dependency>

사용하려는 위치에서 import com.google.gson.Gson;

➤ Spring MVC 동작 방식과 구성 요소

※ DispatcherServlet의 역할

많은 일을 처리하는 것 같지만 실제로는 요청에 대한 처리는 다른 구성 요소들에게 위임(Delegate)하고 있다.

애플리케이션의 가장 앞단에 배치되어 다른 구성 요소들과 상호작용 하면서 클라이언트의 요청을 처리하는 패턴을 ‘Front Controller Pattern’이라고 한다.

※ Handler메서드

@GetMapping

@PutMapping

@DeleteMapping

@PatchMapping

@PostMapping

❑ Controller

➤ 패키지 구조 생성

Spring Boot 기반의 애플리케이션에서 주로 사용되는 자바 패키지 구조에는

기능 기반 패키지 구조(package-by-feature)와 계층 기반 패키지 구조(package-by-layer)가 있다.

▶️ 기능 기반 패키지 구조(package-by-feature)

애플리케이션의 패키지를 구현해야 하는 기능을 기준으로 패키지를 구성하는 것이다.

패키지 안에는 하나의 기능을 완성하기 위한 계층별(API 계층, Service 계층, DataAccess 계층) 클래스들이 모여있다.

상대적으로 테스트와 refactoring이 용이하여 많이 사용한다.

▶️ 계층 기반 패키지 구조(package-by-layer)

패키지를 하나의 계층으로 보고 클래스들을 계층별로 묶는 구조이다.

ex) controller, dto, model, repository, service,...

➤ 실습 예제

예제를 따라하면서 정리해보았다.

Mock 데이터를 응답으로 넘기는 형태로 작성하였다.

프론트에 요청과 응답이 정상적으로 통신되는지만 확인하기 위해

실제 안에서 동작하는 로직은 구현하지 않았다.

실습 내용 : 커피 주문 애플리케이션 Controller 설계하기

▶️ 기능 요구 사항

커피 주문 앱에 넣을 수 있는 기능을 모두 넣으면 구현하기 어렵고 복잡해진다.

따라서 동작에 필요한  기능을 넣어서 먼저 애플리케이션 경계를 설정해야 한다.

• 주인이 커피 정보를 관리하는 기능
  • 커피 정보 등록 기능
  • 등록한 커피 정보 수정 기능
  • 등록한 커피 정보 삭제 기능
  • 등록한 커피 정보 조회 기능

• 고객이 커피 정보를 조회하는 기능
  • 커피 정보 조회 기능
• 고객이 커피를 주문하는 기능
  • 커피 주문 등록 기능
  • 커피 주문 취소 기능
  • 커피 주문 조회 기능
• 고객이 주문한 커피를 주인이 조회하는 기능
  • 커피 주문 조회 기능
  • 고객에게 전달 완료한 커피에 대한 주문 완료 처리 기능

커피 주문 애플리케이션에 필요한 리소스: Member, Coffee, Order

리소스에 해당하는 Controller 클래스를 작성

▶️ 엔트리포인트(Entrypoint) 클래스

Spring Boot 기반의 애플리케이션이 정상적으로 실행되려면 main() 메서드가 포함된

애플리케이션의 엔트리포인트를 작성해야 한다.

(Spring Initializr을 통해 생성한 프로젝트는 엔트리포인트 클래스가 이미 작성되어 있다.)

▶️ @SpringBootApplication

• String Boot의 자동 구성을 활성화한다. (@EnableAutoConfiguration)
• 애플리케이션 패키지 내에서 @Component 가 붙은 클래스를 검색한 후(scan), Spring Bean으로 등록하는 기능을 활성화 (@ComponentScan)
• @Configuration 이 붙은 클래스를 자동으로 찾아서 Spring Bean을 등록하는 기능을 활성화 (@SpringBootConfiguration)

▶️ SpringApplication.run(~.class, arrgs);

• Spring 애플리케이션을 부트스트랩하고 실행하는 역할

➤ Controller 만들기

▶️ @RestController

• 클래스에 추가하면 해당 클래스가 REST API의 리소스를 처리하기 위한 API 엔드포인트로 동작함을 의미한다.
• @RestController가 추가된 클래스는 애플리케이션 로딩 시, Spring Bean으로 등록된다.

▶️ @RequestMapping

• 클라이언트 요청과 클라이언트 요청을 처리하는 Handler Method를 매핑해주는 역할을 한다.
• 클래스 레벨에 추가하여 클래스 전체에 사용되는 공통 URL(Base URL)을 설정해준다.
• Attribute
  • value : URL을 넣어준다.
  • produces : 응답 데이터를 어떤 미디어 타입으로 전송할지 설정한다.

※ 추가학습) URI 작성 기본 규칙

• 마지막이 ‘/‘로 끝나지 않아야 한다.
• 동사보다는 명사를 사용한다.
• 단수형 보다는 복수형 명사를 사용한다.
• 기본 소문자를 사용한다.
• 언더스코어(_) 대신에 하이폰(-)을 사용한다.
• 파일 확장자는 URI에 포함하지 않는다.

➤ Handler Method 작성하기

▶️ @PathVariable

괄호 안에 입력한 문자열 값은 밑의 @~Mapping 의 attribute의 중괄호 안의 문자열과 동일해야 한다.

다르면 “MissingPathVariableException” 발생

▶️ @PostMapping

클라이언트가 HTTP 메서드 POST를 이용해서 보낸 request body를 서버에 생성할 때 사용, 메서드 위에 작성

• 원하는 HTTP 메서드에 맞추어서 GetMapping, DeleteMapping, PatchMapping 등 다양하게 지원된다. 반드시 요청하는 HTTP Method 타입과 동일하게 맞춰주어야 정상적으로 매핑된다.
• 괄호() 안에 몇 가지 Attribute를 넣어줄 수 있다.
• attribute에 HTTP URI의 일부를 지정해 줄 수 있다.

▶️ @RequestParam

클라이언트 쪽에서 전송하는 요청 데이터를 쿼리 파라미터(Query Parameter 또는 Query String), 폼 데이터(form-data), x-www-form-urlencoded 형식으로 전송하면 이를 서버 쪽에서 전달 받을 때 사용하는 애너테이션

• 쿼리 파라미터 : 요청 URL에서 물음표(?)를 기준으로 붙는 key/value 쌍의 데이터를 말한다.
• 괄호()안에 전달받을 key값 작성
• 애너테이션이 붙는 변수는 전달받은 value

➤ ResponseEntity

클라이언트의 응답으로 전송하는 JSON 형식의 문자열을 직접 타이핑해서 작성하면 문제가 생기기 쉽고  수정이 번거롭다.

ResponseEntity 객체로 리턴값을 변경하면 JSON을 수작업으로 작성할 필요가 없다.

ResponseEntity를 사용하면 JSON 형식에 타이핑할 필요없이 응답 정보를 map에 담아서 보내면 된다.

ResponseEntity 객체를 생성하면서 생성자 매개변수로 응답 데이터(map)와 HTTP 응답 상태를 함께 전달한다.

리턴 값으로 Map 객체 그대로 리턴해도 클라이언트에서 JSON 형식으로 정상적으로 응답 데이터를 받을 수 있지만 ResponseEntity 객체로 응답 데이터 래핑함으로써 더 세련된 방식으로 응답 데이터를 생성할 수 있다.

• HttpEntity의 확장 클래스이다.
• ResponseEntity에 Custom header를 포함하려면 HttpHeaders에 원하는 헤더를 추가하고 ResponseEntity의 생성자 매개변수로 객체를 전달하면 된다.
• BodyBuilder 클래스를 이용하면 각각의 항목들(body, header, HttpStatus)을 메서드 체인 방식으로 전달할 수 있다.

HTTP 상태 코드

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

프로젝트 코드 깃허브 링크

https://github.com/WiseJade/SpringBoot-practice/tree/main/section2-week3

읽어주셔서 감사합니다. 스프링 공부 어려운 데 화이팅하세요!

오개념에 대한 지적은 환영입니다.

❑ 타입별 Advice

➤ Advice 순서

어드바이스는 기본적으로 순서를 보장하지 않는다.

순서를 지정하라면 @Aspect 적용 단위로 org.springframework.core.annotation.@Order 애너테이션을 적용하면 됨

• 어드바이스 단위가 아닌 클래스 단위로 적용할 수 있다.
• 하나의 aspect에 여러 어드바이스가 존재하면 순서를 보장받을 수 없다.

aspect를 별도의 클래스로 분리해야 한다.

➤ Advice 종류

▶️ Before

• join point 실행 이전에 실행한다.
• Before Advice 구현한 메서드는 일반적으로 리턴 타입이 void 이다.
• 메서드에서 예외를 발생시킬 경우 대상 객체의 메서드가 호출되지 않는다.
• 작업 흐름을 변경할 수 없다.

▶️ After returning

• join point가 정상 완료된 후 실행한다.
• returning 속성에 사용된 이름은 advice 메서드의 매개변수 이름과 일치해야 함

▶️ After throwing

• 메서드가 예외를 던지는 경우에 실행한다.
• 메서드 실행이 예외를 던져서 종료될 때 실행한다.
• throwing 속성에 사용된 이름은 advice 메서드의 매개변수 이름과 일치해야 함

▶️ After (finally)

• join point의 동작(정상 또는 예외)과는 상관없이 실행한다.
• 메서드 실행 후 공통 기능을 실행한다.
• try~finally의 finally를 생각하면 된다.
• 일반적으로 리소스를 해제하는데 사용한다.

▶️ Around ⭐️

• 메서드 호출 전후에 수행하며 가장 강력한 advice이다.
• 메서드 실행 전후, 예외 발생 시점에 공통 기능을 실행한다.
  • 조인 포인트 실행 여부 선택 - joinPoint.proceed()
  • 전달 값 변환 - joinPoint.proceed(args[])
  • 반환 값 변환
  • 예외 변환
• try~catch~finally 가 들어가는 구문 처리가 가능하다.
• 어드바이스의 첫 번째 매개변수는 ProceedingJoinPoint를 사용해야 한다.
• proceed()를 통해 대상을 여러번 실행할 수 있다.

@Around만 있어도 모든 기능 수행이 가능하다!

하지만 target등 고려해야할 사항이 있을 때 정상적으로 작동되지 않는 경우도 있다.

@Before, @After 어드바이스는 기능은 적지만 원하는대로 작동되고 코드도 단순하다.

좋은 설계는 @Around만 사용해서 모두 해결하는 것보다는 제약을 가지더라도 실수를 미연에 방지하는 것이다.

제약을 두면 문제 자체가 발생하지 않고 역할이 명확해진다.

❑ Pointcut 표현식

➤ 포인트컷과 표현식&지시자

▶️ 포인트컷

관심 조인 포인트를 결정

어드바이스가 실행되는 시기를 제어

AspectJ는 포인트컷을 편리하게 표현하기 위한 표현식을 제공

ex) @Pointcut(“execution(* hello.aop.order..*(..))”)

▶️ 포인트컷 지시자(Pointcut Designator, PCD)

포인트컷 지시자 종류

➤ Pointcut 표현식 결합

&&, ||, ! 를 사용하여 결합할 수 있다.

이름으로 포인트컷 표현식을 참조할 수도 있다.

▶️ 일반적인 pointcut 표현식들

// 모든 공개 매서드 실행
execution(public * *(..))

// set 다음 이름으로 시작하는 모든 메서드 실행
execution(* set*(..))

// AccountService 인터페이스에 의해 정의된 모든 메서드의 실행
execution(* com.xyz.service.AccountService.*(..))

// service 패키지에 정의된 메서드 실행
execution(* com.xyz.servic.*.*(..))

// service 패키지 또는 해당 하위 패키지 중 하나에 정의된 메서드 실행
execution(* com.xyz.service..*.*(..))



// Spring AOP에서만 메서드 실행하는 표현식들

// service 패키지 내의 모든 조인 포인트
within(com.xyz.service.*)

// service 패키지 또는 하위 패키지 중 하나 내의 모든 조인 포인트
within(com.xyz.service..*)

// AcountService 프록시가 인터페이스를 구현하는 모든 조인 포인트
this(com.xyz.service.AccountService)

// AcountService 대상 객체가 인터페이스를 구현하는 모든 조인 포인트
target(com.xyz.service.AccountService)

// 단일 매개변수를 사용하고 런타임에 전달된 인수가 Serializable 과 같은 모든 조인포인트
args(java.io.Serializable)

// 대상 객체가 @Transactional 애너테이션이 있는 조인 포인트
@target(org.springframework.transaction.annotation.Transactional)

// 실행 메서드에 @Transactional 애너테이션이 있는 조인 포인트
@annotation(org.springframework.transaction.annotation.Transactional)

// 단일 매개 변수를 사용하고 전달된 인수의 런타임 유형이 @Classified 애너테이션을 갖는 조인 포인트
@args(com.xyz.security.Classified)

// tradeService 라는 이름을 가진 스프링 빈의 모든 조인 포인트
bean(tradeService)

// 와일드 표현식 *Service 라는 이름을 가진 스프링 빈의 모든 조인 포인트
bean(*Service)

❑ JoinPoint

➤ AOP 적용 위치

• AOP는 메서드 실행 위치 뿐만 아니라 다양한 위치에 적용할 수 있다.
• 적용 가능 지점 : 생성자, 필드 값 접근, static 메서드 접근, 메서드 실행
• AOP 를 수행하는 메서드는 이 JoinPoint 인스턴스를 인자로 받게 된다.
• JointPoint 인스턴스에서 조인 포인트의 정보를 얻어내야 한다.

➤ JoinPoint

• AOP를 적용할 수 있는 지점을 의미하는 추상적 개념
• 프로그램 실행 중 지점을 나타낸다.
• AspectJ를 사용해서 컴파일 시점과 클래스 로딩 시점에 적용하는 AOP는 바이트코드를 실제 조작하기 때문에 해당 기능을 모든 지점에 적용할 수 있다.
• 프록시 방식을 사용하는 Spring AOP는 메서드 실행 지점에만 AOP를 적용할 수 있다.
• 프록시는 메서드 오버라이딩 개념으로 동작한다.
• 생성자나 static 메서드, 필드값 접근에는 프록시 개념이 적용될 수 없다. (프록시는 스프링 AOP에서 사용하기 때문)
• 프록시를 사용하는 스프링 AOP의 조인 포인트는 메서드 실행으로 제한된다.
• 프록시 방식을 사용하는 스프링 AOP는 스프링 컨테이너가 관리하는 스프링 빈에만 AOP를 적용할 수 있다.
• JoinPoint 메서드는 advice의 종류에 따라 사용방법이 다르지만 기본적으로 advice 메서드에 매개변수로 선언만 하면 된다.

➤ JoinPoint Interface의 주요 기능

• JoinPoint.getArgs() : JoinPoint에 전달된 인자를 배열로 반환한다.
• JoinPoint.getThis() : AOP 프록시 객체를 반환한다.
• JoinPoint.getTarget() : AOP가 적용된 대상 객체를 반환한다. (클라이언트가 호출한 비즈니스 메서드를 포함하는 비즈니스 객체를 반환)
• JoinPoint.getSignature() : advice되는 메서드에 대한 설명을 반환한다.
• JoinPoint.toString() : advice되는 방법에 대한 유용한 설명을 인쇄한다.

➤ ProceedingJoinPoint Interface의 주요 기능

▶️ ProceedingJoinPoint Interface

얜 또 뭐야...

https://www.javadoc.io/doc/org.aspectj/aspectjrt/1.7.2/org/aspectj/lang/ProceedingJoinPoint.html

JoinPoint 인터페이스를 extends하는 인터페이스 이다

• proceed() : 다음 어드바이스나 타겟을 호출한다.

❑ 애너테이션(Annotation)을 이용한 AOP

➤ Spring에서의 AOP

AOP는 스프링 IoC를 보완하여 매우 강력한 미들웨어 솔루션을 제공한다.

▶️ Spring AOP 지원

• @AspectJ 애너테이션 스타일
• 스키마 기반 접근

▶️ @AspectJ 지원

• @AspectJ는 애너테이션이 있는 일반 자바 클래스로 aspect를 선언하는 스타일을 말한다.
• AspectJ 5 릴리스의 일부로 AspectJ 프로젝트에 의해 도입되었다.
• 스프링은 pointcut 구문 분석 및 일치를 위해 AspectJ가 제공하는 라이브러리를 사용하여 AspectJ 5와 동일한 애너테이션을 해석한다.
• AOP 런타임은 여전히 순수한 스프링 AOP이며, AspectJ 컴파일러 위버(weaver)에 의존하지 않는다.

▶️ @AspectJ 지원 활성화

• Spring 설정에서 @AspectJ 에 기반한 Spring AOP 설정과 이러한 aspect에 의해 advice되는 자동 프록시 빈에 대한 Spring 지원을 활성화 해야한다.
• @AspectJ 지원은 XML 또는 Java 스타일 설정으로 활성화할 수 있다.
• Java 설정으로 @AspectJ 지원 활성화 방법

@Configuration
@EnableAspectJAutoProxy
public class AppConfig {

}

• XML 설정으로 @AspectJ 지원 활성화 방법

<aop:aspectj-autoproxy/>

➤ Aspect 선언

@AspectJ 지원이 활성화

-> @AspectJ aspect(@Aspect 애너테이션이 있음)이 있는 클래스로 애플리케이션 컨텍스트에 정의된 모든 빈이 Spring에서 자동으로 감지

-> Spring AOP를 구성하는데 사용된다.

import org.aspectj.lang.annotation.Aspect;

@Aspect
public class AspectExample {

}

➤ Pointcut 선언

• pointcut 선언은 이름과 매개변수를 포함하는 Signature와 메서드 실행을 정확히 결정하는 pointcut 표현식의 두 부분으로 구성된다.
• pointcut 표현식은 @Pointcut 애너테이션 사용

읽어주셔서 감사합니다. 좋은하루 되세요 😉

오개념 지적은 환영입니다

➤ 기본 개념

• Spring은 Spring Container를 통해 객체를 관리한다
• 스프링 컨테이너에서 관리하는 객체를 bean(빈)이라고 한다
• @Configuration : 클래스 위에 작성하여 해당 클래스가 IoC 컨테이너에 bean definition 소스로 사용될 수 있음을 알려줌
• @Bean : 메서드 위에 작성하여 해당 메서드가 스프링 컨테이너에 자동 등록되도록 함

@Configuration과 @Bean 공식 문서

https://docs.spring.io/spring-framework/docs/3.0.0.M4/reference/html/ch03s11.html

❑ Bean Definition

bean definition = 레시피

bean definition은 configuration metadata 정보를 포함하고 있는 인터페이스이다.

configuration metadata

• 빈을 어떻게 생성할 것인가
• 빈의 생명주기에 대한 설명
• 빈의 종속성

Bean Definition 참고 자료

https://www.tutorialspoint.com/spring/spring_bean_definition.htm

BeanDefinition 필드 및 메서드

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/config/BeanDefinition.html

❑ Bean Scope

Spring Framework는 6개의 scope를 지원함

그 중에 4개는 ApplicationContext를 사용하는 경우에만 사용할 수 있음

bean은 여러 scope 중 하나를 설정할 수 있음

사용자 정의 scope를 설정할 수도 있음

➤ 스프링 없는 컨테이너만 사용한 객체 생성방법

같은 클래스의 여러 인스턴스를 만들면 서로 다른 주소값을 가진다.

수많은 객체를 생성하게 되면 이 방식은 메모리 낭비가 생기고 효율성이 떨어지게 됨

-> 해결 방법으로 싱글톤 패턴을 사용할 수 있음

❑ Singleton Scope

싱글톤 패턴 : 클래스의 인스턴스를 단 1개만 생성하도록 하는 디자인 패턴

스프링 컨테이너의 시작과 함께 인스턴스가 생성되어 스프링 컨테이너가 종료될 때까지 유지됨

싱글톤 빈의 하나의 공유 인스턴스만 관리함

생성자를 private로만 만들어서 외부에서 임의의 new로 인스턴스를 만드는 것을 방지함

스프링 컨테이너 종료시 소멸 메서드도 자동으로 실행됨

➤ 싱글톤?

싱글톤은 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것을 의미함

단일 인스턴스는 싱글톤 빈의 캐시에 저장됨

이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 개체를 반환함

싱글톤 스코프의 스프링 빈은 여러번 호출해도 모두 같은 인스턴스의 참조 주소값을 가짐

▶️ 싱글톤 디자인 패턴은 어떤 때 사용할까?

예를 들어 CodeStates라는 회사 클래스와 크루, 수강생 클래스가 있다.

크루와 수강생은 여러 명일 수 있으므로 인스턴스를 여러 개 생성하면 되지만

CodeStates는 어떤 크루나 수강생 객체에서 참조해도 동일한 회사이므로 하나의 인스턴스만 생성해도 된다.

싱글톤 패턴 적용 코드

public class CodeStates {
	// static 영역에 단일 객체 생성
    private static final CodeStates instance = new CodeStates();
	// getInstance 메서드로만 인스턴스 호출
    public static CodeStates getInstance() {
        return instance;
    }
    // 생성자를 private 으로 선언하여 외부에서 new 키워드로 인스턴스 생성하는 것을 방지
    private  CodeStates() {
    }
    public void getInfo() {
        System.out.println("CodeStates 입니다.");
    }
}

▶️ 코드 특징

• static 영역에 객체 인스턴스를 미리 1개 생성함
• 객체 인스턴스가 필요한 경우 getInstance() 메서드를 통해서만 조회
• 항상 같은 인스턴스가 호출됨
• 외부에서 생성자를 new로 새로 만드는 것을 방지하기 위해 private으로 생성자를 생성함

스프링 컨테이너의 기본값은 싱글톤이기 때문에 위 코드처럼 직접 static 인스턴스를 만들지 않아도 됨

➤ 싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드 자체는 많음
• 의존 관계상 클라이언트가 구체 클래스에 의존함
• 지정해서 가져오기 때문에 테스트하기 어려움
• private 생성자를 사용하여 자식 클래스를 만들기 때문에 유연성이 떨어짐
• 속성 공유
• Application 초기 구동 시 인스턴스 생성

➤ 싱글톤 패턴 문제 해결

싱글톤 패턴의 문제는 스프링 컨테이너로 해결할 수 있다.

스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.

싱글톤 객체로 생성하고 관리하는 기능을 싱글톤 레지스트리라고 함

스프링 컨테이너의 위 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하고 객체를 싱글톤으로 유지할 수 있음

싱글톤 컨테이너로 관리하려는 객체의 클래스에 @Configuration(클래스 위에 작성)와 @Bean(메서드 위에 작성)을 작성해준다.

@Bean을 통해 스프링 컨테이너에 등록됨

➤ 싱글톤 방식 주의점

여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 몇가지 조심할 부분이 있다.

상태를 유지하게(stateful) 설계하면 안된다. 무상태(stateless)로 설계해야 한다.

• 특정 클라이언트가 값을 변경할 수 있으면 안됨
• 특정 클라이언트에서 의존적인 필드가 존재하면 안됨
• 클라이언트가 수정할 수 있으면 안됨, 읽기만 가능해야함
• 스프링 빈의 공유 값을 설정하면 장애가 발생할 수 밖에 없음 -> 공유되지 않는 지역변수, 매개변수 사용

싱글톤 이외의 다른 Scope Reference

https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/beans.html#beans-factory-scopes

읽어주셔서 감사합니다. 좋은하루 되세요.🥰

오개념에 대한 지적은 언제나 환영입니다~

❑ Spring Container

스프링 프레임워크의 핵심 컴포넌트

스프링 컨테이너는 내부에 존재하는 애플리케이션 빈의 생명주기(생성, 관리, 제거 등)를 관리한다.

▶️ 스프링 컨테이너가 무엇일까?

ApplicationContext를 스프링 컨테이너라고 한다.

인터페이스로 구현되어있다. (다형성 적용)

스프링 컨테이너는 XML, 애너테이션 기반의 자바 설정 클래스로 만들 수 있다.

예전에는 xml을 통해 모두 설정해줬지만 복잡한 설정들을 Spring Boot를 사용하면서 거의 사용하지 않게되었다.

빈의 인스턴스화, 구성, 전체 생명주기, 제거까지 처리한다.

컨테이너는 개발자가 정의한 Bean을 객체로 만들어 관리하고 개발자가 필요할 때 제공한다.

원하는 만큼 많은 객체를 가질 수 있다.

의존성 주입을 통해 애플리케이션의 컴포넌트를 관리한다.

• 스프링 컨테이너는 서로 다른 빈을 연결해 애플리케이션의 빈을 연결하는 역할을 한다.
• 개발자는 모듈 간에 의존 및 결합으로 인해 발생하는 문제로부터 자유로울 수 있다.
• 메서드가 언제, 어디서 호출되어야하는지, 메서드 호출에 필요한 매개변수를 준비해서 전달하지 않는다.

▶️ 왜 스프링 컨테이너를 사용할까?

new 생성자를 사용해서 객체를 생성할 필요가 없다. -> 낮은 결합도

객체간의 참조가 많을수록 의존성이 높아진다.

높은 의존성은 객체지향 프로그래밍의 핵심 중 하나인 낮은 결합도를 지키지 못하게 한다.

그래서 의존성을 낮추기 위해 스프링컨테이너가 필요하다.

▶️ 기존 방식 vs Spring Container

• 기존의 방식 : 새로운 정책이 생길 때 마다 변경 사항을 일일이 수정해야 했다. 작업 초반부는 하나하나 수정할 수 있지만 코드가 거대해질 경우 의존도가 높아져있고 그에 따른 코드 변경 시간이 많이 들어간다.

• Spring Container : 구현 클래스에 있는 의존을 제거하여 인터페이스에만 의존하도록 설계한다. 거대한 코드를 수정할 때도 일부분만 수정하면된다.

▶️ 스프링 컨테이너의 생성 과정은 어떻게 될까?

주로 사용하게 되는 설정방식은 Java 기반의 애너테이션 기반 설정이다.

(하지만 XML 방식에 대해서도 이해를 하고 있어야 한다.)

참고) XML 이란 무엇인가?

XML(eXtensible Markup Language) W3C에서 개발된, 다른 특수한 목적을 갖는 마크업 언어를 만드는데 사용하도록 권장하는 다목적 마크업 언어

다른 많은 종류의 데이터를 기술하는데 사용할 수 있다.

주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 데이터를 쉽게 주고 받을 수 있게하여 HTML의 한계를 극복

텍스트 데이터 형식으로 유니코드를 사용(전 세계 언어 지원)

지금은 임의의 자료구조를 나타내는데 널리 사용됨 (대표적인 예가 웹 서비스)

- 위키백과 -

Configuration Metadata 사용

※ Configuration Metadata 가 무엇일까?

⬇️ 공식문서

https://docs.spring.io/spring-boot/docs/current/reference/html/configuration-metadata.html

스프링 컨테이너는 매개변수로 넘어온 설정 클래스 정보를 사용하여 스프링 빈을 등록한다.

new AnnotationConfigApplicationContext(구성정보.class) 로 스프링에 있는 @Bean의 메서드를 등록

애너테이션 기반의 자바 설정 클래스로 Spring을 만드는 것을 의미한다.

XML 기반으로 만드는 ClassPathXmlApplicationContext도 있다.

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"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd">


    <bean id="..." class="...">  
        <!-- collaborators and configuration for this bean go here -->
    </bean>


    <bean id="..." class="...">
        <!-- collaborators and configuration for this bean go here -->
    </bean>


     <!-- more bean definitions go here -->

</beans>

<beans id=“...”> : 빈 정의를 식별하는데 사용되는 문자열

<beans class=“...”> : 빈의 유형을 정의하고 클래스 이름을 사용

➤ 스프링 컨테이너의 종류

▶️ BeanFactory

스프링 컨테이너의 최상위 인터페이스

빈을 등록하고 생성, 조회하고 돌려주는 등 빈을 관리하는 역할

getBean() 메서드를 통해 빈을 인스턴스화 할 수 있음

@Bean이 붙은 메서드 명을 스프링 빈의 이름으로 사용하여 빈 등록

▶️ ApplicationContext

BeanFactory의 기능을 상속함

BeanFactory 기능 + 부가기능 제공

참고) 부가기능

• MessageSource : 메세지 다국화를 위한 인터페이스
• EnvironmentCapable : 개발, 운영 등 환경변수 등으로 나눠 처리, 애플리케이션 구동 시 필요한 정보들을 관리하는 인터페이스
• ApplicationEventPublisher : 이벤트 관련 기능을 제공하는 인터페이스
• ResourceLoader : 파일, 클래스 패스, 외부 등 리소스를 편리하게 조회

※ 컨테이너 인스턴스화

ApplicationContext 생성자에 제공된 위치 경로는 컨테이너가 로컬 파일 시스템, Java CLASSPATH 등과 같은 다양한 외부 리소스로부터 구성 메타데이터를 로드할 수 있도록 하는 리소스 문자열

➤ new와 생성자 주입 코드 차이점

new를 사용하는 대신 생성자를 통해 의존 객체가 주입되고 느슨한 의존 관계가 이루어짐 -> 객체지향적 프로그래밍 가능

구현 클래스는 Bean 설정에 따라 유연하게 변하게 됨

생성자가 주입된 객체 입장에서는 어떤 구현 객체가 주입될 지 알 수 없고 알 필요도 없음

어떤 객체가 주입될 지는 외부에서 결정

생성자가 주입된 객체는 오로지 실행에만 집중하게 됨

❑ Bean(빈)

➤ 빈이란?

스프링 컨테이너에 의해 관리되는 재사용 소프트웨어 컴포넌트이다.

Spring 컨테이너가 관리하는 자바 객체를 의미하며 하나 이상의 빈을 관리한다.

빈은 인스턴스화된 객체를 의미함

스프링 컨테이너에 등록된 객체를 스프링 빈이라고 함

참고) Spring Bean != Java Bean

자바 빈

• private로 선언된 필드와 Getter/Setter로만 이루어져 있다
• 생성자가 없는 no-Argument 생성자만 존재한다
• java.io.Serializable을 구현한다

스프링 빈은 스프링 컨테이너에 등록된 객체를 의미한다.

@Bean이 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록함

빈은 클래스의 등록정보, Getter/Setter 메서드를 포함

빈은 컨테이너에 사용되는 설정 메타데이터로 생성됨

설정 메타데이터

• XML / 자바 애너테이션, 자바코드로 표현함
• 컨테이너의 명령과 인스턴스화, 설정, 조립할 객체를 정의함

➤ Bean 접근방법

ApplicationContext를 사용하여 bean 정의를 읽고 액세스할 수 있음

• getBean을 사용하여 bean의 인스턴스를 가져올 수 있음
• ApplicationContext 인터페이스는 bean을 가져오는 몇 가지 방법들이 있음
• 응용프로그램 코드에서는 getBean() 메서드로 호출하여 사용하면 안된다. (IoC/DI)

➤ BeanDefinition

스프링은 다양한 설정 형식을 BeanDefinition이라는 추상화 덕분에 지원할 수 있음

빈은 BeanDefinition(빈 설정 메타정보)으로 정의되고 BeanDefinition에 따라서 활용하는 방법이 달라짐

BeanDefinition(빈 설정 메타정보)

• 속성에 따라 컨테이너가 Bean을 어떻게 생성하고 관리할지 결정함
• @Bean / <bean> 당 1개씩 메타 정보가 생성됨
• Spring이 설정 메타정보를 BeanDefinition 인터페이스를 통해 관리하기 때문에 컨테이너 설정을 XML이나 Java코드로 설정할 수 있음(스프링 컨테이너는 설정 형식이 무엇인지 모르고 BeanDefinition만 알면 됨)

읽어주셔서 감사합니다. 좋은하루 되세요 🤗

오개념에 대한 지적은 언제나 환영입니다.

❑ Spring Framework 들어가기전

지금까지 Java의 기본과 핵심을 배웠다.

Java의 기본문법만으로 어떤 소프트웨어를 만들 수 있을까?

지금까지 배운것으로는 콘솔 출력 프로그램 또는

Java GUI API인 AWT나 Swing을 사용한 데스크탑 애플리케이션을 만들 수 있을 것이다.

➤ AWT(Abstract Window Toolkit)

자바의 본 플랫폼에 의존하는 윈도, 그래픽스, 사용자 인터페이스 위젯 툴킷

GUI를 제공하는 표준 API인 자바 파운데이션 클래스(JFC)의 일부

AWT는 수많은 자바 ME(Java Platform Micro Edition, 임베디드를 위한 자바 플랫폼)를 위한 GUI툴킷이다.

➤ 스윙(Swing)

자바에서 GUI를 구현하기 위해 JDK에서 기본적으로 제공하는 개발 툴킷

선마이크로시스템즈의 자바기반클래스의 일부

기존에 발표되었던 AWT가 OS및 윈도 시스템의 자원을 그대로 제공하기 때문에 자바에서 지향하는 “Write Once, Run Everywhere(WORE)”를 구현하기 위해 각종 시스템에서 공통적으로 제공하는 버튼, 대화창 등만을 구현했다.

그래서 여러 환경에서 동일한 화면을 보여줄 수 있지만 대신 해당 시스템의 고유한 모습을 보여줄 수 없다.

❑ 스프링 실습 환경 구성

먼저 설정해야 하는 것들이 몇 가지 있다.

1. JDK-11 설치
2. 환경변수에 JAVA_HOME 설정
3. IntelliJ Community Edition 설치

Spring Initializr 공식 사이트로 이동

https://start.spring.io/

원하는 Spring Boot 실행 환경과 필요한 모듈을 포함하는 템플릿 프로젝트를 생성해 준다.

Spring Boot 애플리케이션은 WAS 배포용인 War 파일 형태로 배포할 수 있지만, 일반적으로 Spring Boot 애플리케이션은 WAS를 내장하고 있는 Jar 파일 형태로 배포해서 실행한다.

스프링 != 스프링 부트

스프링 부트는 스프링을 잘 활용하기 위해 스프링에서 나온 프로젝트

Packaging : 개발한 코드를 빌드해서 하나의 결과물로 만들어 낸다

ADD DEPENDENCIES 에서 ‘Lombok’ 과 ’Spring Web’을 선택하고 GENERATE를 누른다.

그러면 zip 파일이 다운로드 된다.

다운로드한 zip 파일은 압축해제 한다.

그 다음에 intelliJ에서 Open으로 압축을 푼 프로젝트를 열면 된다.

❑ Spring Framework 소개

➤ Framework란?

Frame은 틀, 구조, 뼈대 등의 의미이다.

벽에 거는 액자를 프레임이라고 부르기도 한다.

자동차에서는 뼈대가 되는 강판을 프레임이라고 부른다.

이처럼 Frame은 어떤 대상의 큰 틀이나 외형적인 구조를 의미한다.

지금까지 배웠던 것 중에 Framework는 Collections Framework가 있다.

Collections Framework 안에 있는 Map, Set, List 등은 데이터를 저장하기 위해 자주 사용되는 자료구조를 바탕으로 자바에서 제공하는 클래스이다.

그렇다면 콜렉션에 왜 framework라는 말을 붙일까?

자바에서 framework, 틀 하면 제일 먼저 생각나는 것이 인터페이스(Interface)이다.

자바의 콜렉션은 Map, List, Set같은 인터페이스와 그 인터페이스를 구현한 구현체들의 집합이다.

이렇게 Framework는 프로그래밍을 하기 위한 기본적인 틀이나 구조를 제공한다.

그 외에도 프레임워크는 다양한 기능들을 제공한다.

개발하고자 하는 애플리케이션이 다른 애플리케이션과 통신하고 데이터를 데이터 저장소에 저장하는 등의 기능들도 프레임워크나 라이브러리에서 제공한다.

이를 통해 개발자는 애플리케이션의 핵심 로직을 개발하는 것에만 집중할 수 있도록 해준다.

➤ Framework 와 Library?

프레임워크와 라이브러리는 얼핏 보면 같은 개념이지만 차이점이 있다.

프레임워크와 라이브러리는 여러가지 필요한 기능들을 제공한다는 점에서는 비슷하지만 중요한 차이점이 바로 애플리케이션에 대한 제어권이다.

라이브러리는 애플리케이션 흐름의 주도권이 개발자에게 있다.

개발자가 짜 놓은 코드내에서 필요한 기능이 있으면 호출해서 자유롭게 사용이 가능하다.

이에 반해 프레임워크는 애플리케이션 흐름의 주도권이 개발자가 아닌 프레임워크에 있다.

프레임워크는 불러오면 코드 상에서 보이지 않는 상당히 많은 일들을 한다.

개발자가 메서드내에 코드를 작성해두면 스프링 프레임워크에서 개발자가 작성한 코드를 사용하여 애플리케이션의 흐름을 만들어낸다.

이것이 Spring Framework의 핵심개념 중 하나인 IoC(Inversion Of Control,  제어의 역전)이다.

❑ Spring Framework를 배워야 하는 이유

➤ Spring Framework란?

스프링 프레임워크는 Java 기반의 웹 애플리케이션을 개발하는데 필요한 프레임워크이다.

2004년 버전 1.0이 처음 릴리즈 된 이후로 Java 기반의 웹 애플리케이션을 개발하는데 있어 표준이라 해도 과언이 아닐만큼 대세가 되었다.

그런데 자바 기반의 웹 애플리케이션을 개발하기 위한 프레임워크는 스프링만 있는 것은 아니다. Apache Struts2, Apache Wicket, JSF(Java Server Faces), Grails 와 같은 자바 또는 JVM 기반의 웹 프레임워크들이 존재한다.

▶️ 그런데 왜 스프링 프레임워크가 각광받는 걸까?

대부분의 기업들이 기업용 Enterprise 시스템용 애플리케이션 개발에 있어 Framework를 선택할 때, 개발 생산성을 높이고 어떻게하면 유지보수를 더 용이하게 할 것인가에 많은 초점을 맞춘다. 스프링 프레임워크는 개발 생산성을 향상시키고 유지보수를 용이하게 해주고 그 이상도 달성할 수 있게 해준다.

*기업용 Enterprise 시스템 : 기업의 업무(조직의 업무, 고객을 위한 서비스 등)를 처리해주는 시스템, 대량의 사용자 요청을 처리해야 하기 때문에 서버의 자원 효율성, 보안성, 시스템의 안전성이나 확장성 등을 충분히 고려해서 시스템을 구축한다.

Spring Framework를 사용하는 이유는 이전의 기술들을 알아보면 이해할 수 있다.

➤ Spring Framework 이전의 기술들

▶️ JSP를 이용한 애플리케이션

JSP(Java server page)

백엔드/프론트엔드의 구분없이 코드에 html/Javascript, Java가 뒤섞여 있는 방식이다.

가독성이 떨어지고 유지보수도 매우 어렵다.

프론트엔드/백엔드를 구분하지 않았던 예전엔 양쪽을 모두 개발하는 개발자들이 많았기 때문에 이런 방법을 이용했다.

▶️ 서블릿(Servlet)을 이용한 애플리케이션

JSP 방식과 Spring에서도 내부적으로 Servlet 방식을 사용한다.

서블릿은 클라이언트 웹 요청 처리에 특화된 Java 클래스의 일종이다.

서블릿 방식을 이용한다는 의미는 서블릿을 위한 자바 코드가 클라이언트 측 코드에서

분리되어 별도의 자바 클래스로 관리된다는 것을 의미한다.

하는 일에 비해 코드가 너무 길어보인다는 단점이 있다.

▶️ Spring MVC를 이용한 애플리케이션

서블릿 방식의 코드를 Spring MVC 방식의 코드로 바꾸면 코드가 간결해진다.

서블릿 방식은 클라이언트의 요청에 담긴 데이터를 꺼내오는 작업을 개발자가 직접 코드로 작성해야하고, 캐릭터셋도 지정해주어야 한다.

하지만 Spring MVC 방식의 코드에서는 눈에 보이지 않지만 그런 작업들을 Spring에서 알아서 처리해준다.

그런데도 Spring 기반의 애플리케이션의 기본 도구를 잡는 설정 작업이 여전히 불편하다는 단점이 있다.

그래서 이러한 문제를 대부분 개선한 Spring Boot가 나왔다.

▶️ Spring Boot을 이용한 애플리케이션

이전 기술에서 구현한 것을 더 짧은 코드로 간결하게 작성할 수 있다.

Spring MVC에서 겪었던 설정의 복잡함을 Spring Boot에서는 찾아볼 수 없다.

Spring의 복잡한 설정 작업도 Spring이 대신 처리해주기 때문에 개발자는

애플리케이션의 핵심 비즈니스 로직에만 집중할 수 있게 되었다.

※ 심화 학습

자바 서블릿이란?

자바 서블릿 자체를 사용하는 기술은 현재 거의 사용하고 있지 않지만 Spring MVC같은 자바 기반의 웹 애플리케이션 내부에서 여전히 사용되고 있다.

서블릿 컨테이너란?

서블릿 기반의 웹 애플리케이션을 실행해주는 것부터 시작해서 서블릿의 생명주기를 관리하며, 쓰레드 풀을 생성해서 서블릿과 쓰레드를 매핑시켜 주기도 한다.

아파치 톰캣(Apache Tomcat)은 서블릿 컨테이너의 한 종류로써 Spring MVC 기반의 웹 애플리케이션 역시 기본적으로 아파치 톰캣에서 실행 된다.

읽어주셔서 감사합니다. 좋은하루 되세요 🦾

오개념 지적은 환영입니다~