사용자가 비밀번호를 바꾼다고 했을 때, 서비스 계층에서는 RestController계층으로부터 데이터를 전달받고그 멤버의 비밀번호 속성을 바꾸어 다시 스프링부트 JPA 레포지토리 계층에 전달하여 db에 저장해야한다.그래서 제일 마지막에 memberRepository.save()로 데이터를 전달하는데, 여기서 이 save메서드를 작성하지않아도 DB에 자동으로 비밀번호가 바뀌어서 정상적으로 저장된다.
—>그 이유는 우리가 JPA(스프링부트 JPA) 프레임 워크를 사용하면서 EntityManager라는 인터페이스도 같이 생기게 되는데(기능은 Hibernate에서 구현됨) 이 EntityManager 가 우리가 @Entity어노테이션을 붙인 클래스에 대해 영속성 컨텍스트라는 매커니즘을 사용하여 해당 클래스와 DB의 엔티티 사이를 지속적으로 관리한다. 이 메커니즘으로 인해 원래 DB에 데이터와 매칭되는 객체가 프로그램 단계에서 속성값이 바뀌었을 때 자동으로 DB에 업데이트 적용까지 하게 한다.
---------------서비스 계층----------------------------------
public void updatePw(MemberUpdateDto memberUpdateDto){
Optional<Member> optionalMember= memberRepository.findByEmail(memberUpdateDto.getEmail());
Member tempMember = optionalMember.orElseThrow(()->new EntityNotFoundException("없는 사용자입니다"));
tempMember.changePw(memberUpdateDto.getNewPassword());
**memberRepository.save(tempMember);
-->그런데! 이 save메서드 구문을 삭제해도 자동으로 update된다!!**
}
싱글톤 객체는 Component 어노테이션을 통해 구현되는데 이 Bean어노테이션도 싱글톤 객체를 구현하여 사실상 Component어노테이션과 같다고 볼 수 있다. 단, Component는 클래스 차원에서 적용되고 Bean은 메서드 차원에 적용된다. 이때는 메서드의 리턴 타입이 객체이고, 리턴되는 개체에 싱글톤 객체를 구현하고 싶을 때 사용하는 경우가 많다. 그리고 필수적으로 Bean어노테이션을 붙이기 전에 해당 메서드가 정의된 클래스에 @Configuration어노테이션을 붙여야한다. Configuration 과 Bean어노테이션은 세트 같은 느낌. (@Configuration은 스프링에 Bean을 정의하기 위한 어노테이션으로 클래스 차원에서 선언되어야한다.)
----------------MemberRestConroller클래스(계층)-----------------------
@DeleteMapping("/delete/{id})"
public String deleteMember(@PathVarialbe Long id){
memberService.deleteMember(id);
return "Okay!";
}
**-->무엇을 삭제할 때 기본적으로 해당 객체의 id값을 조회하여 해당 id를 가진 객체삭제해야하므로
PathVariable방식으로 id변수를 받는게 편하다.**
----------------MemberService클래스(계층)----------------------------
public void deleteMember(Long id){
Member member=memberRepository.findById(id).orElseThrow(()->new NoEntityFoundException);
memberRepository.delete(member);
**-->RestController로부터 메서드를 통해 전달받은 id를 레포지토리 계층으로부터 조회하면
해당id를 가진 객체를 찾을 수 있다. 그런다음 삭제하면 끝.
또는 memberRepository.deleteById(id)로 객체의 id값을 전달해 바로 객체를 삭제하는 방법도 있으나,
멤버(객체) 그 자체를 delete하는 메서드가 좀 더 객체지향스럽다고 할 수 있다.**
}
컴퓨터간 통신방법에는 IP프로토콜, TCP프로토콜, HTTP프로토콜 등이 있다.
IP프로토콜 :가장 오래된 프로토콜로, IP주소를 통해 데이터를 목적지로 보냄. 그런데 막상 목적지(서버)에 도착했는데 서버가 작동불능이거나 하면 데이터가 전달이 안되는 거임. 따라서 잘 도착했는지 보장될 수 가 없는 등 여러 한계가 존재함.
TCP프로토콜
:그런 한계로 나타난게 TCP프로토콜로 3 way handshake를 특징으로 가짐 :3 way handshake는 SYN, SYN+ACK, ACK 단계로 이루어짐
1단계(SYN): 클라이언트가 서버에게 ‘연결이 가능한 지’ 요청메시지를 보내는 단계
2단계(SYN+ACK):서버가 연결요청에 대해 허락하고 ‘연결 가능해'라고 클라이언트에게 답장하는 단계
3단계(ACK):클라이언트도 서버가 요청을 받아들인걸 확인하고 데이터를 전달하고 서버와의 연결을 계속 유지.
데이터를 보내기 전에 서버의 상태를 확인하기 때문에 신뢰성이 있는 데이터 전달. 그리고나서 서버와의 연결을 계속해서 유지함. 이로인해, 지속적인 연결성이 있으므로 채팅이나, 알림서비스와 같은 실시간 연결서비스는 tcp프로토콜로 구현해야함. 연결성은 계속해서 유지하므로 서버에 과부하가 걸린다는 단점도 존재.
HTTP프로토콜
:HTTP프로토콜은 TCP프로토콜을 기반으로 하며, 서버에 과부하가 걸리는 TCP의 단점을 보완하는 프로토콜.
:TCP를 기반으로 하기 때문에, 3 way handshake로 서버와 연결. 따라서 신뢰성 있는 데이터 전송이 가능하며, TCP에서는 데이터를 전달하고 나서도 계속해서 서버와의 연결을 유지하는 반면, HTTP프로토콜은 연결을 끊어버림. 그리고 다시 데이터를 전송할 때 마다 3way handshake 단계를 거치는 것.