마이바티스 쓸때 커넥션객체, 쿼리객체 안만듬.
스프링
jar파일이 다 쪼개져있음
필요한 것만 갖다 쓰면 됨. -> 가볍다.
뭐가 필요한지.
각 묘듈들 간에 의존성이 어떻게 되고 있는지. 사과박스
빈들을 컨테이너가 관리하니까 의존성도 얘가 관리.
- 빈 등록
- 의존관계 형성
- 컨테이너 객체 생성. 어플리케이션으 ㅣ엔트리포인트에서
컬렉션주입.팩토리가 어떻게 동작했는지
자바로 관리
컨테이너의 계층구조.
상위 컨테이너가 가지고 있는 것들 하위가 물려받아서 사용가능.
웹모듈
프론트컨트롤러 패턴
요청이 들어올때 엔트리 포인트가 프론트컨트롤러
유저, 관리자 컨트롤러 분리할 수 있음. 하지만 공통적으로 조회하는 부분
일반 유저에서도 persistence에 접근할 수 있어야되고 관리자도 접근할 수 있어야되는데 그러면 persistence가 중복되게 등록되야됨
-> 계층구조 사용.
persistence에서 상위에 등록시키면 빈을 중복되게 등록할 필요 없음.
루트는 프론트컨트롤러보다 먼저 등록이 되야됨
-> 리스너 사용한것.
리스너 콜백메서드(어플리케이션 시작됬다는 것도 있을것)에서 루트 컨테이너 등록.
상위, 하위에서 이거 사용하면 @service, .. 상위, 하위 중복되게 등록됨
new로 생성하면 스프링 컨테이너 밖에 있어서 주입 안됨. -> nullpoint
흐름은 프론트가 결정
-> 구조 등록
이것들 기본적으로 등록되있음.
하지만 우리의 뷰네임 기본으로 못찾아냄
-> xml에 등록 해줘야됨.
ui는 동기, 데이터는 비동기로 가져가면 json
스프링 - req안에 있는 정보 파악할 수 있는거 많이 지원
원래는 한 메서드에서 다 처리하고 req에서 헤더 꺼냈는데 @RequestMapping에 파악할 수 있는거 많이 지원
스프링쓰면 jackson안써도 됨. 그리고 json으로 내보내면 jsp탈필요 없음.
-> viewresolver 따로 등록
memberList
-> "/member/memberList"
=> 이 이름으로 뷰리졸버가 찾음. 처음에 json없어서 tiles-> tiles.xml뒤져서 데피니션네임이랑 비교해서 찾음
톰캣을 jsp컨테이너라고 부를수있었던 이유는 이 서블릿이 있어서.
-> 이런것들은 동적요청
default서블릿이 웹서버 역할 대신하고 있었던것.
정적인 요청까지 프론트가 받은것. -> 뒷단 컨트롤러에서 처리할 수 있어야됨.
하지만 종류 많음(html, css...)
-> 스프링에서 제공함
resource - 정적자원 처리
WEB-INF - 동적자원처리
mapping - 컨트롤러 매핑
/** 확장자 등 모든거 다 잡겠다.
어지간한 정적처리 톰캣한테 넘겨서 우리도 부담 적어짐.
resource파일 썼을때 장점
정적자원 따로 모아서 관리가능
2. 캐시 안남길 수 있음
캐시 컨트롤 할 수 있던것들 (cashcontroll..) 한번에 할 수 있음.
스프링에서는 이거를 필터로 해결.
모든 정적자원 프론트통해 들어옴. 그전에 필터거침
거기서 캐시처리해주면 됨.
스프링 컨테이너 안에있다면 빈으로 등록되야됨
web.xml 읽는애-> 톰캣. 이 필터객체 톰캣이 관리
스프링컨테이너 밖에 있는 애들은 빈들 주입 못받음
-> 스프링 핸들어 인터셉터로 해결
cPath
1.web.xml에 등록되있는 리스너 상속받아서 우리만의 리스너 만들기
2.스프링이 가지고 있는 이벤트처리구조 사용
컨테이너의 최상위는 Application
지금 우리가 있는데는 WebApplication
-> 애를 잡아야됨. 얘가 시작됬을때 cPath잡게
파일업로드체크필터 - 스프링 밖에 있음
컨테이너 안에서 멀티파트리졸버 형태로 관리함.
part 들어왔을때 그거를 multipart로 바꿔주는 애도 H.A
@ResponseBody 여기서는 직렬화에 마샬링까지 해라는 의미.
-> 꼭 jsonView 말고 이렇게 할수도 있다는 것
jsonView - model을 대상으로 마샬링함. 그래서 add한 키로 꺼내서 쓸 수 있는것.
그런데
위에 방법은 모델이 없음. ->
여기가 paingVO로 되야된다는것.
필드나가서 꼭 jsonView로 쓰지 않을수도 있다.
스프링
얼마나 핸들러 어뎁터를 잘 써먹냐
req, resp, session 받는거 되도록 쓰지마라
H.A 되게 많은 일 해주는데 직접 받으면 다 못써먹음
핸들러 어뎁터 이용해서 검증하는 방법
required생략하면 true
근데 안들어오면 핸들러어뎁터가 400내보냄
커맨드 오브젝트에 대한 검증도 핸들러 어뎁터가 하는게 맞다
annotation-driven 이거 넣었을때 20개정도 올라가는데 그중에 하나가 CommonValidator.
@Valid, @Validation사용.
req가 가지고 있던 member라는 객체의 해당 프로퍼티 검증결과 알려주겠다.
커스텀테그는 서버사이드 코드. 실행하면 없어진다.
- 어노테이션 붙이기
- 그룹설정
- 커맨드오브젝트에 하이버네이트 적용. 이게 있어야 검증
- 검증 결과 - errors로 받아옴
검증되는 객체랑 떨어져있으면 못넣음
검증되는 객체 바로 뒤에 Errors 넣어야 관계형성됨.
커스텀 에러메세지 만들기
fmt 커스텀테그 로케일에 따라 나타낼 수 있는지 -> 스프링에게 넘어감
VIEW-웹에 종속됨.
그래서 프로퍼티스파일도 하위에 넣음.
로케일 꼭 필요한건 아님. - 필터에 사용.
하지만 필터는 스프링 밖에 있음. 전략들 주입 받을 수 없음.
-> 핸들러 인터셉트 사용
뭔가 처리하기 전에 전처리, 후처리 하고싶을때 인터셉트. 필터랑 똑같은 기능. 하지만 필터는 밖에있고 얘는 안에 있다.
/** 뎁스구조 상관없이 모든 거 포함.
