Contents
1. join-mustache로 보는 회원가입 시나리오1. join-mustache로 보는 회원가입 시나리오
1. 중복체크를 하지 않고 회원가입 버튼 클릭할 경우
- 회원가입 페이지에서 username과 password, email을 입력하고 회원가입 버튼을 누른다.
- 그러면 onsubmit에 의해 valid 함수의 결과가 리턴된다.
- 유저네임 중복체크에 대한 isUsernameAvailable이라는 변수가 false이고, 이는 중복 체크가 안됐거나 이미 존재하기 때문에 사용 불가능하다는 의미이다.
- valid함수에서는 중복체크를 하지 않고 회원가입 버튼을 눌렀을 경우 isUsernameAvailable이 false이므로 아이디 중복체크를 필요로 한다는 알림을 띄우게 된다.


2. 중복 체크를 하고 회원가입 버튼 클릭할 경우(1) - 정상적 접근
3. 중복 체크를 하고 회원가입 버튼 클릭할 경우(2) - 비정상적 접근
public Map<String, Object> 유저네임중복체크(String username) {
User user = userRespository.findByUsername(username);
Map<String, Object> dto = new HashMap<>();
if (user == null) {
dto.put("available", true);
} else {
dto.put("available", false);
}
return dto;
}
em.createNativeQuery -> JPA의 도움을 못 받음(ORM), 복잡한 쿼리쓸 때 사용
em.createQuery ->
em.createNamedQuery -> 쓰지X
em.EntityGraph -> 연관관계 배우고 나서
table은 entity
table을 모델링 한것도 entity
PC는 client마다 request 객체마다 가진다. (클라이언트마다 전용 pc)
-> 생성됐다가 삭제됐다가..
em.find -> User 객체를 PC에서 받음 -> 캐싱?
select 줄인다 = i/o가
PC에 해당 pk를 가진 객체가 있을 때 캐싱됨!!!
화면에서 찾아야될 객체가 pc에 있으면 select 안해도 됨
controller에서 @ResponseBody를 리턴타입 앞에 붙이면 파일이 아니라 데이터인 object를 json으로 return
제네릭은 리턴할때 와일드카드로 리턴
한개짜리 필드 -> dto보다는 map으로 하는게 낫다!
map과 js object 타입이 비슷함
Share article