< 식당으로 알아보는 API >

식당에 가면 주방으로 달려가서 요리를 주문하지 않는다. 식당에 들어가면 점원에게 요리를 주문한다. 그리고 점원은 주방에 가서 '요리를 만들어 달라'라고 요청한다. 그리고 요리가 완성되면 점원이 손님에게 요리를 전달한다. 

여기서 손님은 클라이언트, 주방에서 일하는 요리사를 서버라고 생각하면 된다. 그리고 중간에 있는 점원을 API라고 생각하면 된다. 이상황을 웹 사이트에 방문하는 상황에 적용해서 생각해보자. 사용자가 주소를 입력해서 '구길 메인 화면을 보여줘'라고 요청을 할 것이다. 그러면 API는 이 요청을 받아 서버에게 가져다준다. 그러면 서버는 API가 준 요청을 처리해 결과물을 만들고 이것을 다시 API로 전달한다. 그러면 API는 최종 결과물을 브라우저에 보내 화면을 볼 수 있게 된다.

이처럼 API는 클라이언트의 요청을 서버에 잘 전달하고, 서버의 결과물을 클라이언트에게 잘 돌려주는 역할을 한다. 그러면 REST API란 무엇일까?

< 웹의 장점을 최대한 활용하는 REST API > 

Rest API는 웹의 장점을 극대화하는 인터페이스 설계 방식이다.

REST는 'Representational State Transfer'의 줄임말로, 이는 '자원의 상태를 표현(Represent)하여 주고 받는' 방식을 의미한다. 말하자면, REST API는 자원을 이름으로 구분하고 그 상태로 주고 받는 일관된 인터페이스 설계 방법을 제시한다.

처음 REST API에 대해 들어보면 , 스프링 부트나 리액트, Vue.js와 같은 특정 기술인 줄 착각할 수 있으나. 하지만, REST API는  특정 기술이 아닌 URL 설계 방식을 말한다. 

이 REST API의 설계 원칙을 따르면 개발자 입장에서 여러 가지 장점이 있지만, 그와 동시에 몇가지 단점도 존재한다.

< REST API의 특징 >

REST API는 서버/클라이언트 구조, 무상태, 캐시 처리 가능, 계층화, 인터페이스 일관성과 같은 특징이 있다.

< REST API의 장점과 단점 >

REST API의 장점은 URL만 보고도 무슨 행동을 하는 API인지 명확하게 알 수 있다는 것이다.

상태가 없다는 특징이 있어 클라이언트와 서버의 역할이 명확하게 분리된다.

HTTP 표준을 사용하는 모든 플랫폼에서 사용할 수 있다.

REST API의 단점은 HTTP 메서드, 즉, GET,POST와 같은 방식의 개수에 제한이 있고, 설계를 하기 위해 공식적으로 제공되는 표준 규악이 없다.

그럼에도 REST API는 주소와 메서드만 보고 요청의 내용을 파악할 수 있다는 강력한 장점이 있어 많은 개발자들이 사용한다.

심지어 'REST하게 디자인한 API'를 RESTful API라고 부르기도 한다.

< REST API를 사용하는 방법 >

< 규칙 1. URL에는 동사를 쓰지말고, 자원을 표시해야 한다. >

URL은 자원을 표시해야 한다는 말에서 자원은 무엇을 말할까? 자원은 가져오는 데이터를 말한다. 예를 들어 학생 중에 id가 1인 학생의 정보를 가져오는 URL은 이렇게 설계할 수 있다.

/students/1
/get’student?student_id=1

처음에 이 URL을 보면 '어떻게 해도 괜찮은 것 아닐까?'라고 생각할 수 있지만, REST API에 더 맞는, 즉 RESTful API는 1번이다. 왜냐하면 2번의 경우 자원이 아닌 다른 표현을 섞어 사용했기 때문이다. 2번의 경우 동사를 사용해서 추후 개발 시에 혼란을 줄 수 있다. 예를 들어 서버에서 데이터를 요청하는 URL을 설계할 때 어떤 개발자는 get을 어떤 개발자는 show를 쓰면 어떻게 될까? 그러면 URL 구조가 get-student, show-data와 같이 엉망이 될 것이다. 행위는 '데이터를 가져온다'지만 표현이 중구난방이 될테니 말이다. 그래서 RESTful API를 설계할 때는 이러한 동사를 쓰지 않는다.

< 규칙 2. 동사는 HTTP 메서드로 >

앞서 동사에 대해서 이야기 했는데, 이건 HTTP 메서드라는 것으로 해결한다. HTTP 메서드는 서버에서 요청을 하는 방법을 나눈 것인데, 주로 사용하는 HTTP 메서드는 POST,GET,PUT,DELETE 이다. 각각 만들고,읽고,업데이트하고,삭제하는 역할을 담당하는데 보통 이것들을 묶어 CRUD라고 부른다. HTTP 메서드의 감을 잡기 위해 블로그에 글을 쓰는 설계를 한다고 생각해보자. 

이외에도 슬래시는 계층 관계를 나타내는데 사용하거나, 밑줄 대신 하이픈을 사용하거나, 자원의 종류가 컬렉션인지 도큐먼트인지 따라 단수, 복수를 나누거나 하는 등의 규칙이 있다. 

Reference : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

스프링 데이터는 비즈니스 로직에 초점을 맞출 수 있도록 데이터베이스 사용 기능을 클래스 레벨에서 추상화한다. 이를 위해 제공하는 여러 인터페이스를 통해 스프링 데이터를 활용할 수 있다. 이들 인터페이스는 CRUD와 같은 다양한  메서드를 포함하며, 이를 사용하면 스프링 데이터가 자동으로 쿼리를 생성해준다.

추가적으로, 스프링 데이터는 페이징 처리 기능이나 메서드 이름으로 자동 쿼리 빌딩 등 다양한 기능을 제공한다. 그리고 각 데이터 베이스의 특성에 맞춰 확장 기능을 제공한다. 예를 들자면, JPA(Java Persistence API) 표준 스펙은 스프링 데이터 JPA를, MongoDB는 스프링 데이터 MongoDB를 사용할 수 있다.

🤔  < 스프링 데이터 JPA란? > 🤔 

스프링 데이터 JPA는 스프링 데이터의 일반적인 기능에 JPA 특화 기능이 추가된 라이브러리이다. 여기서 제공하는 JpaRepository 인터페이스는 스프링 데이터의 PagingAndSortingRepository 인터페이스를 상속받아 만들어졌으며,

JPA를 좀 더 간편하게 사용할 수 있는 메서드를 제공한다.

예를 들어, 스프링 데이터 JPA를 사용하지 않고, 엔티티의 상태를 바꾸려면 다음과 같이 작업을 해야 한다.

@PersistenceContext
EntityManager em;

public void join() {
// 기존에 인티티 상태를 바꾸는 방법(메서드 호출을 해서 상태 변경)
Member member = new Member(1L, "홍길동");
em.persist(member);
}

하지만 스프링 데이터 JPA를 사용하면, 데이터베이스의 CRUD 작업을 간편하게 처리할 수 있다. 다음과 같이 JpaRepository 인터페이스를 상속받은 사용자 정의 인터페이스를 만들고, 제네릭에는 <관리할 엔티티 이름, 엔티티 기본키 타입>을 입력하면, 기본적으로 제공되는 CRUD 메서드를 사용할 수 있다.

public interface MemberRepository extends JpaRepository<Member, Long> {
}

🐻‍❄️< 스프링 데이터 JPA에서 제공하는 메서드 사용해보기 > 🐻‍❄️

1.src/main/java/me/taeyoung/springbootdeveloper 경로에 MemberService.java를 생성해 코드를 아래와 같이 작성했다.

① save() 메서드를 호출해 데이터 객체를 저장할 수 있다. 전달 인수로 엔티티 Member를 넘기면 반환값으로 저장한 엔티티를 반환받을 수 있다.

②.findById() 메서드에 id를 지정해 엔티티를 하나 조회할 수 있다. findAll()메서드는 전체 엔티티를 조회한다.

③.deleteById()메서드에 id를 지정하면 엔티티를 삭제할 수 있다.

< 예제 코드 살펴보기 >

지금까지 많은 Annotation을 사용했다. 이제 Annotation이 어떤 역할을 하는지 알아볼 차례이다.

[Member.java]

①. @Entity Annotation은 Member 객체를 JPA가 관리하는 엔티티로 지정한다. 즉, Member 클래스와 실제 데이터베이스의 테이블을 매핑시킨다. @Entity의 속성 중에 name을 사용하면 name의 값을 가진 테이블 이름과 매핑되고 테이블 이름을 지정하지 않으면 클래스 이름과 같은 이름의 테이블과 매핑이 된다. 여기서는 테이블 이름을 지정하지 않았으므로 클래스 이름과 같은 데이터베이스의 테이블인 member 테이블과 매핑된다. @Entity Annotation에서 테이블을 지정하고 싶다면 다음과 같이 name 파라미터에 값을 지정해주자.

② protected 기본 생성자이다. 엔티티는 반드시 기본 생성자가 있어야 하고, 접근 제어자는 public 또는 protected 이어야 한다. public보다는 protected가 더 안전하므로 접근 제어자가 protected인 기본 생성자를 생성한다. 

③ @Id는 Long 타입의 id 필드를 테이블의 기본키로 지정한다.

④ @GeneratedValue는 기본키의 생성 방식을 결정한다. 여기서는 자동으로 기본키가 증가하도록 지정했다.

여기서는 IDENTITY라는걸 사용 했는데, 다양한 자동키 생성 설정 방식이 있다.

Auto :선택한 데이터베이스 방언에 따라 방식을 자동으로 선택(기본값)

IDENTITY : 기본 키 생성을 데이터베이스에 위임(= AUTO_INCREMENT)

SEQUNCE :  데이터 베이스 시퀀스를 사용해 기본 키를 할당하는 방법. 오라클에서 주로 사용

TABLE : 키 생성 테이블 사용

⑤ @Column Annotation은 데이터베이스의 컬럼과 필드를 매핑해준다. 대표적인 @Column Annotation의 속성을 알아보자.

name : 필드와 매핑할 컬럼 이름. 설정하지 않으면 필드 이름으로 지정해준다.

nullable : 컬럼의 null 허용 여부, 설정하지 않으면 true(nullable)

unique : 칼럼의 유일한 값(unique) 여부. 설정하지 않으면 false

columnDefinition : 컬럼 정보 설정. default 값을 줄 수 있다.

[MemberRepository.java]

Repository는 엔티티에 있는 데이터들을 조회하거나 저장, 변경, 삭제를 할 때 사용하는 인터페이스로, 스프링 데이터 JPA에서 제공하는 인터페이스인 JpaRepository클래스를 상속받아 간단하게 구현할 수 있다.

JpaRepository 클래스를 상속받을 때, 엔티티 Member와 엔티티의 기본키 타입 Long을 인수로 넣어준다. 이제 해당 리포지토리를 사용할 때 JpaRepository에서 제공하는 여러 메서드를 사용할 수 있게 된다. 

Source :스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

'패킷'이라고 해도 사용자 마음대로 만든 패킷을 네트워크로 전달 할 수는 없다.  애초에 상대에게 패킷이 상대에게 도착했는지 알 수 없을 뿐만 아니라, 성령 도착했다 하더라도 상대가 패킷을 이해했는지 알 수 없다.

그래서 네트워크 세계에서는 패킷을 처리하기 위한 규칙이 존재한다.

이 규칙을 프로토콜(통신 프로토콜)(protocol, communication protocol)이라 부른다. 이 프로토콜이 통신에 필요한 기능별로 명확하게 규정되어 있기 때문에 PC 제조사나 운영체제(OS)가 다르더라도, 유무선에 관계없이 동일하게 패킷을 교환할 수 있다.

웹사이트를 방문할 때 URL을 입력할 때가 있는데, 여기에서 처음 입력한 https가 이 프로토콜에 해당한다.

HTTPS는 Hypertext Transfer Protocol Secure의 약자로서, 웹서버와 웹브라우저 사이에서 패킷을 암호화하여 교환할 때 사용하는 프로토콜이다. 웹브라우저에서 URL 첫 부분에 https라는 문자를 붙임으로써 'HTTPS 로 결정된 규약에 따라 패킷을 처리합니다.'라고 선언한다.

< 프로토콜에 결정되어 있는 것 >

네트워크에는 많은 프로토콜이 각각 다양한 역할을 하며 존재한다.

[물리적 사양 ]

LAN 케이블 소재나 커넥터 형태, 그 핀 할당(핀 배열)에 이르기까지 네트워크에서 눈에 보이는 것들은 모두 프로토콜에 정의되어 있다. 그리고 와이파이 환경에서 전파의 주파수는 물론, 패킷을 전파로 변환하는 방식도 프로토콜에 정의되어 있다. PC의 NIC(Network Interface Card)는 프로토콜에 정의된 내용에 기반해 케이블이나 전파 등의 전송 매체에 패킷을 보낸다.

[송신 상대 특정]

이름이나 주소를 모르면 소포가 도착하지 않는 것처럼, 어디에 위치한 누구와 통신하고 싶은지를 모르면 패킷을 전달할 수 없다. 그렇기 때문에 네트워크 세계에서도 현실 세계와 같이 주소를 할당해서 송신 상대를 구별한다. 예를 들면. 구글에는 www.google.com이라는 친숙한 문자 주소와 172.217.175.4라는 생소한 숫자 주소가 할당되어 있다. 이 패킷을 송신할 때는 정보를 기반으로 송신 상대를 구별한다.

[패킷 전송]

송신 상대를 특정한 뒤에는 패킷을 상대에게 전달해야 한다. 앞서 설명한 것처럼 컴퓨터는 데이터를 패킷으로 작게 나누어 네트워크로 보낸다. 그때 실제 우편 소포와 마찬가지로 헤더라는 화물표를 붙인다. 헤더에는 송신지, 수신지뿐만 아니라 원래 데이터로 복원하기 위한 순번이나 서버(서비스) 정보 등 전송에 필요한 제어 정보가 포함되어 있다. 프로토콜에는 헤더의 어디에서 어디까지(몇 번째 비트에서 몇 번째 비트까지) 어떤 정보를 포함하고 어떤 순서로 교환하는지 등이 정의되어 있다. 패킷 교환 네트워크를 구성하는 패킷 교환기(네트워크 기기)는 헤더의 정보를 기반으로 릴레이처럼 패킷을 전송한다.

<신뢰성 확립>

패킷은 펼처진 네트워크를 따라 산과 계곡을 넘고 바다를 건너 전 세계 어디든 다다른다. 그러므로 언제,어디에서,어떤 상황에서 패킷이 손상되거나 사라지는지 모른다.  프로토콜은 그런 상황이 발생해도 이상이 없도록 에러를 알리거나 데이터를 재전송하는 구조를 제공한다.또한 유한한 네트워크 자원이 패킷으로 가득 차서 잠기지 않도록 하기 위한 구조도 제공한다. MVNO(Mobile Virtual Network Operator) 가입 스마트폰을 이용하는 경우, 점심시간이나 출퇴근 시간대에 웹서비스를 찾지 못한 경험을 했을 것이다. 이는 한정된 네트워크 대역을 모두 함께 잘 공유할 수 있도록 네트워크에서 제어하기 때문이다.

<보안 확보>

최근에는 이름이나 주소, 생년월일이나 계좌번호 등 중요한 정보를 인터넷을 통해 교환하는 일이 많다. 인터넷은 누구나 연결할 수 있는 공공 네트워크이다. 언제 어디에서 누가 정보를 보려는지 알 수가 없다. 프로토콜은 이러한 중요 정보를 안심하고 교환할 수 있도록 올바른 통신 상대인지 인증하고 통신을 암호화하는 구조를 제공한다. 예를 들어, 온라인 스토어에서 무언가를 구입하고자 할 때 먼저 사용자 이름과 비밀번호를 입력해 로그인할 것이다. 그때 웹브라우저는 접속 대상 서버가 올바른 통신 상대인지 확실히 인증한 후, 사용자 이름과 비밀번호를 암호화해서 송신한다.

Source : 그림으로 공부하는 TCP/IP 구조

https://product.kyobobook.co.kr/detail/S000001952227

🌳< 애자일(Agile) 방법론 >🌳

애자일 방법론은 급변하는 소프트웨어 개발 환경에 맞춰 유동적으로 개발을 진행하는 방법론이다.

빠르게 변하는 요구사항에 대응하기 위하여, 작은 단위로 개발을 진행하며, 그 결과를 즉시 피드백받는 방식을 통해,프로젝트의 효율성을 높이는데 초점을 둔다.

< 애자일 방법론 등장 배경 >

애자일 방법론은 기존의 전통적인 개발 방법론이 소프트웨어 개발 환경의 변화에 빠르게 대응하기가 어려웠다.

모바일 환경의 부상과 함께 소프트웨어 개발 트렌드가 급변하며, 고객의 요구사항이 점점 더 다양하고 복잡해졌다.

이에 따라, 빠르게 변경되는 요구사항에 유연하게 대응할 수 있는 개발 방법론의 필요성이 대두되었고, 그 결과로 애자일 방법론이 탄생하게 되었다.

< 애자일 방법론 특징 >

 애자일 방법론은 개발 절차나 도구보다, 개인과 팀 간의 소통을 중요하게 생각한다. 개발 계획은 단기적으로 세워져, 언제든지 고객의 요구 변화에 유연하게 대응할 수 있다. 이런 접근 방식은 개발 프로세스를 효율적으로 만들고, 동작하는 소프트웨어를 빠르게 제공할 수 있게 한다.

또한 애자일 방법론은 고객과의 지속적 협력을 중요하게 생각한다. 고객의 피드백은 개발 과정에서 중요한 부분이며, 이를 통해 개발 과정이 끊임없이 개선될 수 있다.

이렇게 이해하면, 애자일 방법론은 실질적으로 다음과 같은 핵심 원칙에 따라 실행된다.

1. 개인과 상호작용을 공정과 도구보다 중요시한다.

2. 변화에 대응하며 계획을 따르는 것보다는 더 중요하다.

3. 포괄적인 문서보다 동작하는 소프트웨어를 더 중요하게 생각한다.

4. 계약 협상보다 고객과의 협력을 더 중요하게 본다.

< 애자일 방법론 유형 >

애자일 방법론은 대표적으로 XP,린(Lean),스크럼(SCRUM)등이 있다.

①. XP(eXtreme Programming)

• XP는 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론이다.
• 기존의 방법론에 비해 실용성을 강조한 방법론이다.
• 1~3주의 반복 개발 주기를 가지며, 5가지 가치와 12개의 실천 항목이 존재한다.

②.스크럼(SCRUM)

스크럼은 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론이다.

③.린(Lean)

린은 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론이다.

린은 JIT(Just In Time), 칸반(Kanban)보드를 사용한다.

Reference : Reference : 2023 수제비 정보처리기사

https://product.kyobobook.co.kr/detail/S000200275590

< ORM란? >

ORM이란, Object-Relational Mapping의 약자로, 객체 지향 프로그래밍 언어를 사용하여 호환되지 않는 유형 시스템 간에 데이터를 변환하는 프로그래밍 기법을 말한다. 즉, 프로그래밍 언어의 객체와 데이터베이스의 데이터를 자동으로 연결해주는 역할을 한다.
< JPA란? >
Java에서는 JPA(Java Persistence API)를 ORM 표준으로 사용하며. JPA는 자바에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다. 이 JPA를 사용하면 개발자는 데이터베이스의 데이터를 마치 자바의 객체처럼 쉽게 다룰 수 있게 된다.

위의 두 가지 개념을 잘 모를 시 아래 링크를 통해 학습을 하고 읽는 걸 추천 한다.

https://taeyoungcoding.tistory.com/300

하지만  JPA는 인터페이스이므로 실제 동작을 위해서는 이를 구현한 ORM 프레임워크를 추가로 선택해야 한다.

 < Hibernate란 ? >

ORM 프레임워크 중 하나인 Hibernate는 JPA 인터페이스를 구현한 구현체이자 자바용 ORM 프레임워크이다. 이는 내부적으로 JDBC API를 사용하며, Hibernate를 통해 개발자는 직접적인 SQL 쿼리문 없이도 데이터베이스와의 작업을 수행할 수 있다.

Hibernate의 가장 큰 장점은 데이터베이스의 종류에 상관없이 일관된 코드로 데이터베이스 작업을 처리할 수 있다는 점이다. 즉, MySQL, Oracle, PostgreSQL 등 어떤 데이터베이스를 사용하더라도, Hibernate를 통한 코드 작성 방식은 동일하다.

< 엔티티 매니저란? >

<엔티티>

엔티티(Entity)는 기본적으로 자바 객체이다. 하지만 이는 일반적으로 자바 객체와는 조금 특별한 성질을 가지고 있다.

바로 "데이터베이스 테이블과 매핑" 된다는 특성이다. 

<엔티티 매니저>

엔티티 매니저(entity manager)는 엔티티의 생성,수정,삭제 등의 작업을 수행한다. 이러한 엔티티 매니저는 '엔티티 매니저 팩토리(Entity Manager Factory)'에서 만들어진다. 

예를 들어, 두 명의 사용자가 동시에 회원 가입을 한다고 생각해보자. 이때 각 사용자의 회원 가입 요청에 대해 엔티티 매니저 팩토리는 독립적인 엔티티 매니저를 생성한다. 각 엔티티 매니저는 자신이 담당하는 사용자의 정보를 데이터베이스에 저장하게 된다. 이렇게 각각의 엔티티 매니저를 통해 회원 가입 처리가 완료되면, 사용자 정보는 데이터베이스에 안전하게 저장된다. 

스프링 부트에서는 직접 엔티티 매니저 팩토리를 생성,관리하지 않는다. 스프링 부트는 내부적으로 엔티티 매니저 팩토리를 하나만 생성하고 이를 공유한다. 이런 점이 바로 스프링 부트가 간편함과 효율성을 제공하는 비결 중 하나이다.

< Spring boot가 엔티티 매니저를 사용하는 방법 예시 >

스프링 부트에서는 @PersistenceContext 또는 @Autowired 어노테이션을 사용해서 엔티티 매니저를 사용한다.

이 Annotation을 사용하면 Spring boot가 관리하는 엔티티 매니저를 손쉽게 사용할 수 있다. 

@PersistenceContext
EntityManager em; // 프록시 엔티티 매니저. 필요할 때 진짜 엔티티 매니저 호출

여기서 중요한 점은 스프링 부트는 기본적으로 빈은 하나만 생성하여 공유한다는 점이다. 따라서 동시성 문제가 발생할 수 있다. 이 문제를 해결하기 위해 스프링 부트는 '프록시 엔티티 매니저'를 사용한다. 이는 실제 엔티티 매니저와 연결하는 가짜 엔티티 매니저로, 필요할 때 데이터베이스 트랜잭션과 관련된 실제 엔티티 매니저를 호출한다.

빈에 대해 궁금한 것은 더 보기 클릭 <

🤔< 영속성 컨텍스트란? >🤔

영속성컨텍스는 JPA의 가장 중요한 개념 중 하나로, 단순히 이해 하자면 엔티티를 저장하고 관리하는 가상의 데이터베이스 공간이라고 볼 수 있다. 엔티티 매니저는 이 영속성 컨텍스트를 통해 엔티티를 관리하며, 데이터베이스와의 상호작용을 효과적으로 수행한다.

< 영속성 컨텍스트의 핵심 특징 > 

1차 캐시

영속성 컨텍스트는 내부에 1차 캐시라는 메모리 공간을 가지고 있다. 이 곳에는 데이터베이스에서 조회한 엔티티가 저장되면서, 이후 같은 엔티티를 조회하려 할 때 이 캐시를 먼저 확인하여 데이터베이스 접근을 줄이는 역할을 한다. 이렇게 함으로써 데이터 조회 속도를 크게 향상 시킬 수 있다.

쓰기 지연

쓰기 지연(transactional write-behind)는 엔티티에 대한 변경(추가,수정,삭제)이 일어났을 때, 즉시 데이터베이스에 반영하는 것이 아니라, 트랜잭션을 커밋하는 시점에 한꺼번에 반영하는 기능이다. 이를 통해 데이터베이스의 부담을 줄이면서, 성능을 향상시킬 수 있다.

변경 감지

영속성 컨텍스트는 트랜잭션 커밋 시점에 1차 캐시에 저장된 엔티티와 현재 엔티티의 상태를 비교한다. 이를 통해 변경된 내용이 있는지를 자동으로 감지하고, 이를 데이터베이스에 반영한다. 

지연 로딩 

지연 로딩(lazy loading)은 엔티티가 실제로 사용되는 시점에서 데이터베이스에서 데이터를 로딩하는 기능이다. 이를 통해 불필요한 데이터 로딩을 최소화하여 애플리케이션의 성능을 향상시킬 수 있다.

< 엔티티의 상태 > 

엔티티는 4가지의 상태를 가진다. 영속성 컨텍스트가 관리하고 있지 않는 분리(detached)상태, 영속성 컨텍스트가 관리하는 관리(managed)상태, 영속성 컨텍스트와 전혀 관계가 없는 비영속(transient)상태, 삭제된(removed)상태로 나뉜다.

이 상태는 특정 메서드를 호출해 변경할 수 있는데, 필요에 따라 엔터티의 상태를 조절해 데이터를 올바르게 유지하고 관리할 수 있다.

< 엔티티의 상태 변경 예시 코드 >

public class EntityManagerTest {

@Autowired
EntityManager em;

public void example() {
// 1. 엔티티 매니저가 엔티티를 관리하지 않는 상태(비영속 상태)
Member member = new MEmber(1L, "홍길동");

// 2. 엔티티가 관리 상태가 된다.(관리 상태)
em.persist(member);
// 3. 엔티티 객체가 분리된 상태가 된다.(분리 상태)
em.detach(member);
// 4. 엔티티 객체가 삭제된 상태가 된다.(삭제 상태)
em.remove(member);
 }
}

1.엔티티를 처음 만들면 엔티티는 비영속 상태가 된다.

2.persist() 메서드를 사용해 엔티티를 관리 상태로 만들 수 있으며, Member 객체는 영속성 컨텍스트에서 상태가 관리 된다.

3.만약 엔티티를 영속성 컨텍스트에서 관리하고 싶지 않다면 detach()메서드를 사용해 분리 상태로 만들 수 있다.

4. 또한 더 이상 객체가 필요 없다면 remove()메서드를 사용해서 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제할 수 있다. 

Reference : Reference : 출처 : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

< Tomcat Install, JetBrains ultimate version and JDK HotSpot 11 version download >

첫번째 : JDK HotSpot 11 version download (JDK HotSpot11 다운로드 하기)

https://adoptium.net/temurin/releases/?version=11

Windows jdk-11.0.18+10 version msi download (위에서 3번째) 다운로드를 한다.

설치 이후에 cmd에서 아래 명령을 입력하면 성공적으로 설치되었는지 확인할 수 있다.

javac.exe -version 치고 엔터 -> 자바 컴파일러 버전 확인하는 명령어

java.exe -version 치고 엔터 -> 자바 실행 파일 버전 확인하는 명령어

두번째  JetBrains ultimate version 설치

https://www.jetbrains.com/ko-kr/idea/download/#section=windows

링크를 미리보기 할 수 없기에 Ctrl + C , Ctrl + V 하기 바람.

이후에 JetBrains Ultimate Version을 설치 한다.

세번째 Tomcat 설치

①. 아래의 링크 및 Apache Tomcat site에 접속 후 아래의 zip 파일을 다운 받는다. 

Apache Tomcat® - Apache Tomcat 9 Software Downloads

②.다운로드 후 System32쪽에 파일을 넣는다. 

③.환경 변수 설정 하기 

C:\Program Files\Eclipse Adoptium\jdk-11.0.18.10-hotspot\bin  path로 설정 

(꼭 환경 변수 설정 부터 먼저 해야 한다. 안 그러면 cmd에서 

neither the java_home nor the jre_home environment variable is defined at least one of these environment variable is needed to run this program 이라는 Error 발생)

 < Tomcat 실행 하기 >

cmd 실행 하기 -> cd apache-tomcat-9.0.71 입력 후 엔터

-> cd bin 입력 후 엔터

-> startup.bat 입력 후 엔터 

위의 명령어는 C:\Windows\System32\apache-tomcat-9.0.71\bin>startup.bat 경로에 있다는 걸 알 수 있다. 

< Tomcat Server 종료하기 >

 cmd -> cd apache-tomcat-9.0.71 -> cd bin -> shutdown.bat

🎁 < (단일 책임 원칙(Single Responsibility Principle) >🎁

단일 책임 원칙(Single Responsibility Principle)은 SRP이라고도 불린다. SRP는 Object-Oriented-Programming에서

매우 중요한 원칙 중 하나 이다.  이름에서 알 수 있듯이, 각각의 클래스는 단 한 가지의 책임만을 가져야 한다는 원칙이다.

이 원칙은 가독성과 유지보수성을 높이는데 있어 중요한 역할을 한다. 더 자세히 알아보자.

🤔  < (그래서.. 단일 책임 원칙이 뭘까?) >🤔 

SRP는 한 클래스는 하나의 책임만 가져야 한다는 개념. 즉, 클래스는 한 가지의 기능만을 수행해야 하며, 그 이상의 기능이 추가되면 별도의 클래스로 분리해야 된다는 것. 이를 통해 클래스의 복잡성을 줄일 수 있으며, 클래스가 자신의 책임을 더 잘 이해하고, 다른 클래스와 독립적으로 유지보수 및 수정이 가능해지는 것이다.

🐻‍❄️ < SRP의 필요성 >🐻‍❄️

이 원칙이 필요한 이유는 간단하다. 한 클래스가 여러 가지 책임을 가질 경우, 클래스의 복잡성이 증가하고, 한 책임에 대한 변경이 다른 책임을 가진 코드에 영향을 미칠 가능성이 높아진다.

예를 들어, 계산기 클래스가 있을 때, 이 클래스가 숫자 계산뿐만 아니라 파일에서 데이터를 읽고,결과를 파일에 쓰는 역할까지 수행하게 된다면, 이 클래스는 두 가지의 책임을 가지게 된다. 이렇게 되면, 계산 로직과 파일 입출력ㅇ 로직이 서로 간섭할 수 있으며, 한 가지 로직의 수정이 다른 로직에도 영향을 끼칠 수 있다.

< SRP를 위반한 예시 >

public class Calculator {
  private List numbers = new ArrayList<>();
  private int result;
  
  public void loadNumbersFromFile(String fileName) {
     // 파일에서 숫자를 로드하여 numbers 리스트에 추가하는 코드
  }
  public void addNumber(int number){
    numbers.add(number);
  }
  public void calculateSum() {
    result = 0;
    for(int number : numbers) {
      result += number;
    }
  }
  
 public void saveResultToFile(String fileName){
 //결과를 파일에 저장하는 코드   
 }
}  
}

위 코드에서 Calculator 클래스는 숫자를 더하는 책임과 파일 입출력 책임을 동시에 가지고 있다.

< SRP를 준수한 예시 >

public class Calculator {
    private List numbers = new ArrayList<>();
    private int result;

    public void addNumber(int number) {
        numbers.add(number);
    }

    public void calculateSum() {
        result = 0;
        for (int number : numbers) {
            result += number;
        }
    }
}

위의 코드에서는 Calculator 클래스는 숫자를 더하는 책임만 가지고 있다. 파일 입출력은 별도의 클래스에서 담당하도록 분리되었다. 이렇게 하면 클래스의 책임이 명확하게 구분되며, 코드의 가독성과 유지보수성이 향상된다.

Reference: Wikipedia: Single Responsibility Principle

StackOverflow: What is the Single Responsibility Principle?

🌳<데이터 베이스란?>🌳

데이터베이스는 효율적으로 데이터를 저장하고 검색할 수 있는 시스템이다. 데이터베이스의 주요 이점은 많은 사용자가 데이터를 안전하게 활용하고,관리 할 수 있다는 것이다.

💻<데이터베이스 관리자, DBMS>💻

데이터베이스를 효율적으로 관리하고 운영하기 위한 소프트웨어를 DBMS(database management system)이라고 한다.

DBMS의 역할은 여러 사용자가 동시에 데이터베이스에 접근하고 사용할 수 있도록 하는 것이며, 이를 통해 데이터의 공유가 가능하다. 또한, DBMS는 다양한 요구사항을 만족시키면서도 데이터베이스를 효율적으로 관리해야한다.

그래서 일반적으로 사람들이 '데이터베이스'라고 부르는 MYSQL이나 Oracle 같은 것들은 실제로는 DBMS인 것이다. 이들은 데이터를 관리하는 방식에 따라서 관계형,객체-관계형,문서형,비관계형 등 다양한 유형으로 나뉠 수 있다. 이중에서 가장 널리 사용되는 유형은 관계형 DBMS이다.

📀<관계형 DBMS>📀

RDBMS라고 부른다. 관계형이라는 말을 쓰는 이유는 이 DBMS가 관계형 모델을 기반으로 하기 때문이다. RDBMS는 어렵게 생각할 필요 없이 테이블 형태로 이루어진 데이터 저장소를 생각하면 된다. 예를 들어 회원 테이블이 있다고 가정하면 각 행은 고유의 키,즉, 아이디를 가지고 있고, 이메일,나이와 같은 회원과 관련된 값들이 들어간다.

이때 데이터 1, Yoontaeyoung@test.com,10 한 줄을 행이라고 하고, ID,이메일,나이와 같은 구분을 열이라고 한다.

⚡< 데이터베이스를 시작하기전 "꼭" 알아둬야할 데이터베이스 용어 >⚡

<테이블>

테이블은 데이터베이스에서 데이터를 정리하고 구성하는데 사용되는 핵심적 구조이다. 행(row)와 열(column)의 형태로 구성되며, 각 행은 다양한 속성을 나타내는 데이터들로 이루어져 있다.

<행>

행(row)은 테이블의 구성 요소 중 하나이며 테이블의 가로로 배열된 데이터의 집합을 의미한다. 예를 들어 회원 테이블이 있다고 할 때 ID가 1번인 회원의 이메일,나이 같은 정보가 모여있는 집합이 1번 회원에 대한 행이라고 할 수 있다. 행은 반드시 고유한 식별자인 기본 키를 가진다. 행을 레코드(recode)라고 부르기도 한다.

<열>

열(column)은 테이블의 구성 요소 중 하나로, 특정 데이터 유형이 저장된다. 예를 들어, 회원 정보 테이블에서 '이메일'과 '나이'는 각각의 열이 될 수 있으며, 이 열들은 데이터의 무결성을 보장한다. 즉, 각 열은 해당하는 데이터 유형만을 저장한다.

<기본키>

기본키(primary key)는 행을 구분할 수 있는 식별자이다. 이 값은 테이블에서 유일해야 하며, 중복 값을 가질 수 없다. 보통 데이터를 수정하거 삭제하고, 조회할 때 사용되며 다른 테이블과 관계를 맺어 데이터를 가져올 수도 있다. 또한 기본키의 값은 수정되어서는 안 되며 유효한 값이어야 한다. 즉 NULL이 될 수 없다.

<쿼리>

쿼리(query)는 데이터베이스에서 데이터를 조회하거나 삭제,생성,수정 같은 처리를 하기 위해 사용 하는 명령문이다. SQL이라는 데이터베이스 전용 언어를 사용하여 작성한다. 

🔥< ORM이란? >🔥

ORM(Object-relational mapping)은 데이터베이스와 프로그래밍 언어 사이의 '다리'역할을 한다. 데이터베이스에 저장된 정보를 프로그래밍 언어가 이해할 수 있는 형태, 즉'객체'로 변환해주는 기법이다.

그럼 ORM이 왜 필요한지 예를 들어 설명해보자. 데이터베이스에 '홍길동'이라는 이름과 '20'이라는 나이가 저장되어 있다고 가정해보자. 이 정보를 자바 같은 프로그래밍 언어로 활용하려면 일반적으로 SQL이라는 데이터베이스 전용 언어를 사용해야 한다. 하지만 ORM이 있으면, 별도로 SQL을 배우지 않아도 이 정보를 자바 객체로 바로 사용할 수 있다.

즉, ORM은 프로그래밍 언어로 데이터베이스를 손쉽게 다룰 수 있게 해주는 도구라고 볼 수 있다. 이런 ORM 활용에는 ㄷ장단점이 있다.

< 장점 > 

ⓐ.SQL을 몰라도 프로그래밍 언어로 데이터를 다룰 수 있다.

ⓑ.코드를 객체지향적으로 작성할 수 있어 비즈니스 로직에 더 집중할 수 있다.

ⓒ.데이터베이스 시스템을 쉽게 변경할 수 있다. (예:MySQL에서 PostgreSQL로)

< 단점 >

ⓐ. 프로젝트가 복잡해질수록 ORM 사용이 어려워진다.

ⓑ. 복잡한 쿼리를 실행하기 어렵다.

Reference : 출처 : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

TestController.java 파일을 열고 클래스 이름 위에 마우스 커서를 놓고 클릭한 다음 Alt + Enter 을 누르면 [Create Test] 가 나타난다.

위의 Create Test를 누르면 아래와 같은 창이 나타난다.

OK를 누르면 TestControllerTest.java 파일이 test/java/패키지 아래에 생성된다. 생성된 파일을 다음과 같이 작성한다. 여기서는 테스트 코드를 작성하기 위해 또 새로운 Annotation을 사용했다.

🚀 < 위의 코드에서 꼭 알아둬야 할 Annotation > 🚀

<@SpringBootTest>

@SpringBootTest Annotation은 Main Application class에 추가하는 Annotation인 @SpringBootApplication이 있는 Class를 찾고, 그 Class에 포함되어 있는 Bean을 찾은 다음에 Test용 "Aplication Context"라는 것을 만든다.

<@AutoConfigureMockMvc>

@AutoConfigureMockMvc는 MockMvc를 생성하고 자동으로 구성하는 Annotation이다. MockMvc는 Aplication을 서버에 배포하지 않고도 Test용 MVC환경을 만들어 요청 및 전송, 응답 기능을 제공하는 유틸리티 클래스다. 즉, 컨트롤러를 테스트 할 때 사용되는 클래스다.

<@BeforeEach>

테스트를 실행하기 전에 실행하는 메서드에 적용하는 Annotation. 여기서는 MockMvcSetUp() 메서드를 실행해 MockMvc를 설정해준다.

<@AfterEach>

테스트를 실행한 이후에 실행하는 메서드에 적용하는 Annotation. 여기서는 cleanUp() 메서드를 실행해 member 테이블에 있는 데이터들을 모두 삭제해준다.

이제, Logic을 Test하는 코드를 작성해보자.

기존의 작성한 코드에 아래의 코드를 추가한다.

위의 코드 중 ① 위치에서 perform() 메서드는 요청을 전송하는 역할을 하는 메서드다. 결과로 ResultActions 객체를 받고, ResultActions 객체는 반환값을 검증하고 확인하는 andExpect() 메서드를 제공해준다. 

② 위치에서 .accpet 메서드는 요청을 보낼 때 무슨 타입으로 응답을 받을지 결정하는 메서드다. JSON.XML등 다양한 타입이 있으나, 여기서는 JSON을 받는다고 명시해두도록 한다.

③ 위치에서 .andExpect()메서드는 응답을 검증한다. TestController에서 만든 API는 응답으로 OK(200)을 반환하므로 이에 해당하는 메서드인 isOK를 사용해 응답 코드가 OK(200)인지 확인한다.

 ④ 위치에서 jsonPath("$[0].${필드명}")은 JSON의 응답값의 값을 가져오는 역할을 하는 메서드이다. 0번째 배열에 들어있는 객체의 id,name값을 가져오고, 저장된 값과 같은지 확인한다.

🎶< HTTP 주요 응답 코드 >🎶

테스트 코드가 완성되었으니 Run  "TestControllerTest"를 선택한다.

테스트가 완료 되었음을 확인 할 수 있다.

Reference : 출처 : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612

Spring Boot는 Application을 Test하기 위한 Tool과 Annotation을 제공한다. 

Spring-boot-starter-test 스타터에 테스트를 위한 도구가 모여 있다.

여기 중 JUnit과 AssertJ를 가장 많이 사용한다.

🌳 < JUnit 이란 ? > 🌳

Junit은 Java 단위 테스트 프레임워크이다. 단위 테스트란, 작성한 코드가 의도대로 작동하는지 작은 단위로 검증하는 것을 의미한다. 이때 단위는 보통 메서드가 된다. JUnit을 사용하면 단위 테스트를 작성하고 테스트하는데 도움을 준다.

< 특징 >

1) @Test Annotation으로 메서드를 호출할 때마다 새 인스턴스를 생성, 독립 테스트가 가능하다.

2) 예상 결과를 검증하는 Assertion method 제공

< Junit으로 단위 테스트 코드 만들어보기 > 

① : JUnitTest File을 만든다. [ src -> test -> java] 폴더에 JUnitTest.java 파일을 생성하고 코드를 따라 작성해보자.

< Code 설명 >

@DisplayName : 테스트 이름 정해주기.

@Test : 테스트를 수행하는 메서드

이후 jUnitTest를 run 하면 아래와 같은 결과가 콘솔창에 출력 된다.

만약 테스트가 실패하면 어떻게 될까? 실패를 위한 테스트 케이스를 하나 더 추가해보자. junitTest() 메서드 바로 아래 다음에 다음 코드를 추가해보자.

위의 결과에서는 1 + 2는 3이 맞으므로 True가 Pass가 되었고,

1 + 3는 4인데 sum이 다르므로 Falied 되었다.

여기서 실패용 테스트 케이스를 실행시, 테스트가 실패했다는 표시와 함께 기댓값과 실제 받은 값을 비교해서 알려준다.

이렇게 JUnit은 테스트 케이스가 하나라도 실패하면 전체 테스트를 실패시켜 보여준다.

<자주 사용하는 JUnit Annotation >

앞서 JUnit은 각 테스트에 대해 객체를 만들어 독립적으로 실행 한다고 했는데 이번에 그 내용을 확인해볼 수 있다.

또 테스트는 Annotation에 따라 실행 순서가 정해진다.

JUnitCycleTest.java를 만든다. 

< @BeforeAll >

전체 테스트를 시작하기 전에 처음으로 한번만 실행한다. 예를 들어 데이터베이스를 연결해야하거나 테스트 환경을 초기화할 때 사용된다. 이 Annotation은 전체 테스트 실행 주기에서 한 번만 호출되어야 하기에 메서드를 static으로 선언해야 한다.

< @BeforeEach >

테스트 케이스를 시작하기 전에 매번 실행한다. 예를 들어 테스트 메서드에서 사용하는 객체를 초기화하거나 테스트에 필요한 값을 미리 넣을 때 사용할 수 있다. 각 인스턴스에 대해 메서드를 호출해야 하므로 메서드는 static이 아니어야 한다.

< @AfterAll >

전체 테스트를 마치고 종료하기 전에 한 번만 실행한다. 예를 들어 데이터베이스 연결을 종료할 때나 공통적으로 사용하는 자원을 해제할 때 사용할 수 있다. 전체 테스트 실행 주기에서 한번만 호출되어야 하므로 메서드를 static으로 선언해야 한다.

< @AfterEach >

각 테스트 케이스를 종료하기 전 매번 실행한다. 예를 들어 테스트 이후에 특정 데이터를 삭제해야 하는 경우 사용한다.

@BeforeEach와 마찬가지로 메서드는 static이 아니어야 한다.

Annotation을 중심으로 JUnit의 실행 흐름을 살펴보면 다음과 같다. @BeforeEach부터 @AfterEach까지 테스트 개수만큼 반복된 결과를 볼 수 있다.

위의 그림을 테스트 코드를 실행해서 출력 결과를 살펴보자.

위의 결과를 보면, @BeforeAll으로 설정한 메서드가 실행되고, 그 이후에는 테스트 케이스 개수만큼 @BeforeEach -> @Test -> @AfterEach의 생명주기로 테스트가 진행된다. 모든 테이스 케이스가 끝나면 @AfterAll으로 실행하고 종료한다.

Reference : 출처 : 스프링 부트 3 백엔드 개발자 되기 - 자바 편

http://www.yes24.com/Product/Goods/118625612