** @RestController
** ajax(Asynchronous JAvascript Xml)
** Mashalling
** XML 출력
** Error
1. 물리적 에러 : 문법 오류로 인해서 애플리케이션이 실행이 안되는 것
2. 논리적 에러 : 문법 상의 오류는 없어서 실행은 되지만 결과가 예상과 다르게 나오는 경우
3. 예외(Exception) : 문법 상의 오류는 없어서 시행은 되지만 특수한 상황이 발생하면 프로그램이 중단되는 것
4. 단언(Assertion) : 특수한 상황이 발생하면 강제로 예외를 발생시켜 애플리케이션을 중지시키는 것
** Web에서의 예외 처리
** Server에서의 예외 처리
** Java Web programming에서의 예외 페이지를 출력
1. jsp 페이지나 web.xml 파일에 예외가 발생하면 보여질 페이지를 설정
2. Controller에서 예외가 발생했을 시에 사용할 페이지를 직접 설정 - @ExceptionHandler 이용
** Error 페이지 작성
** 변경 가능성이 있는 문자열 작성
1. Java에서 작성된 경우 : 문자열을 변경하면 complie, build, run을 전부 다시 수행
2. 일반 텍스트 파일에 작성된 경우 : 문자열을 변경하면 run만 다시 수행
3. 데이터베이스에 저장해서 읽어서 출력하는 경우 : 아무 것도 할 필요 없음 : 대신에 읽어올 때 느림
** 지역화 코드
** 유효성 검사 - Validation Check
1. 클라이언트 사이드
2. 서버 사이드
3. 데이터베이스
** Spring에서의 유효성 검사를 서버에서 수행하는 것
** primary key나 unique한 데이터의 중복 검사는 서버를 이용해야 한다/
** spring에서의 유효성 검사
1. Validation 인터페이스는 유효성 검사를 수행해주는 메소드를 소유한 인터페이스
2. Member 클래스의 유효성 검사 클래스
** Web Site를 위한 서버를 만들 것이냐, REST API 서버를 만들 것이냐
** @RestController
- spring 4.0부터 제공하는 Controller로 요청을 처리하는 메소드에서 String을 리턴하면 String을 그대로 클라이언트에게 전송하고 DTO 또는 Map 그리고 List나 배열을 리턴하면 JSON형식으로 변환해서 클라이언트에게 전송한다.
- String을 리턴하는 경우 csv를 제공하고자 하는 경우이고 그 이외 자료형은 JSON 리턴을 위해서 사용한다.
** ajax(Asynchronous JAvascript Xml)
- 비동기적으로 서버의 데이터를 가져와서 사용하는 것
- 전체 화면 갱신없이 데이터를 가져와서 화면의 일부분을 수정하기 위해서 주로 사용
- 모바일처럼 네트워크의 안정성을 담보할 수 없는 경우 전체 화면을 갱신하는 도중 네트워크가 연결해제되면 화면에 아무것도 출력하지 못한다.
- ajax를 이용하면 서버의 데이터를 가져와서 출력하는 부분은 나중에 보여지고 다른 부분은 계속 출력된다.
- 가져와야 하는 데이터가 많은 경우에도 전체 화면 갱신의 형태를 사용하면 데이터를 전부 가져올 때까지 화면에 아무 것도 출력되지 않은다.
- 최근에는 SPA(하나의 페이지로 모든 콘텐츠를 제공 - Single Page Application)도 유행인데 ajax를 기반으로 생성한다.
** Mashalling
- RPC(Remote Procedure Call) : 원격에 있는 프로시저를 호출
- 대표적인 RPC가 Web Server
** XML 출력
- MarshallingView 이용해서 XML 형식으로 사용
- 아직도 RSS(Rich Site Summary - 뉴스나 블로그 처럼 실시간으로 변경되는 데이터를 제공하는 콘텐츠 표현방식) 에서는 xml을 주로 이용
- 직접 서버를 만든다면 JSON을 이용하는 것이 효율적이다.
- XML parsing은 반드시 해 두어야 한다.
- Back End 개발자는 데이터를 생성하는 것과 파싱하는 것을 모두 할 수 있어야 한다.
- CSV, XML, JSON
- Front End 개발자는 데이터 파싱하는 것을 할 수 있어야 한다.
- XML을 출력할 때는 DTO 클래스에 출력할 속성을 설정한다.
- DTO 클래스의 List를 갖는 별도의 클래스를 생성해서 데이터를 저장하고 MashallingView로 출력
** Error
1. 물리적 에러 : 문법 오류로 인해서 애플리케이션이 실행이 안되는 것
- 대다수의 IDE는 무법 오류가 발생하면 에러 표시를 출력한다.
- 컴파일을 하고 실행되는 언어들은 IDE가 코드를 작성하면 그 때 그 때 컴파일을 해보고 오류 표시를 해준다.
- 소스 파일을 만들었는데 ClassNotFoundException이 발생하면 IDE가 컴파일을 못한 것이므로 클래스를 지우고 다시 생성하는 것이 좋다.(이 때 클래스명을 바꾸는 것이 좋다)
- 컴파일을 하지 않고 한 줄씩 읽어가면서 실행하는 스크립트 언어들은 IDE에서 에러 표시를 하지 않는다.
- 이 경우는 소스 코드를 읽어가면서 에러 나는 부분을 직접 수정해야 한다.
2. 논리적 에러 : 문법 상의 오류는 없어서 실행은 되지만 결과가 예상과 다르게 나오는 경우
- 로직을 잘못 설계해서 발생하는 에러이므로 디버깅(메모리의 값 확인)을 해서 잘못된 로직을 수정해야 한다.
3. 예외(Exception) : 문법 상의 오류는 없어서 실행은 되지만 특수한 상황이 발생하면 프로그램이 중단되는 것
- 예외 메시지를 읽고 수정해야 한다.
- 소스 코드에서 이런 문제가 발생한다면 예외 처리를 해서 예외가 발생하더라도 애플리케이션을 계속 수행하도록 할 지를 결정해야 하고 이런 예외는 별도의 파일에 기록을 해두는 것이 좋다.
- 예외 중에는 개발자가 해결할 수 있는 예외가 있고 해결할 수 없는 예외도 있는데 해결할 수 없는 예외들을 나중에 다른 방법으로 해결해야 하기 때문에 기록을 해두는 것이 중요하다.
//if처럼 동작 - catch는 여러 개 생성 가능
try{
예외 발생 가능성이 있는 코드
}cathch(예외 변수){
예외가 발생했을 때 수행할 내용
}finally{
예외 발생 여부에 상관없이 수행할 내용
}
4. 단언(Assertion) : 특수한 상황이 발생하면 강제로 예외를 발생시켜 애플리케이션을 중지시키는 것
- 조건을 만족하는 경우에만 애플리케이션이 수행되도록 하는 것
** Web에서의 예외 처리
- Web Page에서는 예외가 발생하면 WAS가 가지고 있는 예외 페이리지가 출력되어 있다.
- 되도록이면 예외가 발생했을 때 별도의 페이지를 출력해주는 것이 좋다.
** Server에서의 예외 처리
- 데이터를 넘겨주는 서버를 구축한다면 예외가 발생하거나 잘못된 파라미터를 대입했을 때 여기에 해당하는 데이터를 만들어주는 것이 좋다.
** Java Web Programming에서의 예외 페이지를 출력
1. jsp 페이지나 web.xml 파일에 예외가 발생하면 보여질 페이지를 설정
2. Controller에서 예외가 발생했을 시에 사용할 페이지를 직접 설정
@ExceptionHandler 이용
** Error 페이지 작성
- jsp 파일에서는 isErrorPage 속성을 true로 설정하면 exception 객체를 사용할 수 있는 페이지가 된다.
- IE 하위 버전에서는 에러페이지의 내용이 512바이트가 안되면 IE 자체 에러 페이지를 출력한다.
- edge는 다른 브라우저와 동일하게 처리
** 변경 가능성이 있는 문자열 작성
1. Java에서 작성된 경우 : 문자열을 변경하면 complie, build, run을 전부 다시 수행
2. 일반 텍스트 파일에 작성된 경우 : 문자열을 변경하면 run만 다시 수행
3. 데이터베이스에 저장해서 읽어서 출력하는 경우 : 아무것도 할 필요 없음 - 대신에 읽어올 때 느림
** 지역화 코드
언어코드_국가코드
ko_kr - 한글_대한민국
en_us - 영어_미국
- 대다수의 API에서는 지역화를 할 때는 기본 이름에 _언어 코드나 국가코드를 설정해야 한다.
** 유효성 검사 - Validation Check
1. 클라이언트 사이드
- 서버에게 데이터를 전송하기 전에 파라미터의 유효성을 체크
- 응답이 빠르다. 서버의 트래픽을 줄일 수 있다.
- 클라이언트 사이드의 코드는 유저가 확인할 수 있다.
- 코드의 난독화를 이용해서 보안을 유지하는 경우가 있다.
의미없는 주석을 추가하거나 공백이나 엔터를 제거해서 수행한다.
- 웹의 경우는 HTML5의 속성이나 자바스크립트를 이용해서 수행한다.
2. 서버 사이드
- 클라이언트가 서버에게 데이터를 넘겨주는 시점에 수행
- 보안이 필요한 데이터는 무조건 서버에서 유효성 검사를 수행해야 한다. 그 이유는 데이터는 네트워크를 이용해서 전송되면 변질의 위험성이 있기 때문이다.
- SQL의 매개변수로 사용되는 데이터는 반드시 데이터베이스 작업 전에 유효성 검사를 수행해야 한다.
암호화를 하지 않은 상태에서 로그인 처리
select email, pw
from user
where email = #{email} and pw = #{pw};
위의 경우에 비밀번호를 'ddd or 1=1' 형태로 대입하면 ?
- 비밀번호는 복화화가 불가능한 암호화를 이용해서 저장하고 데이터베이스가 아니라 Service에서 비교하도록 만들어야 합니다.
3. 데이터베이스
- 제약조건을 이용해서 유효성을 검사
** Spring에서의 유효성 검사를 서버에서 수행하는 것
** primary key나 unique한 데이터의 중복 검사는 서버를 이용해야 한다.
- 웹의 초창기에는 팝업창을 이용해서 이런 작업을 처리했는데 그 이후 팝업 창 대신에 ajax를 이용해서 검사를 수행하다가 최근에는 데이터를 전송할 때 서버에서 수행하는 형태로 변경되었다.
** Spring에서의 유효성 검사
- Validator 인터페이스와 Errors 그리고 BindingResult 클래스를 이용해서 유효성 검사를 수행
1. Validator 인터페이스는 유효성 검사를 수행해주는 메소드를 소유한 인터페이스
- 유효성 검사를 수행하고자 하는 경우 Validator 인터페이스를 상속받는 클래스를 생성
1) public boolean supports(Class <?> clazz)
- 유효성검사 수행 DTO 클래스.class.isAssignableForm(clazz)를 호출해서 리턴
2) public void validate(Object target, Errors errors)
- 이 메소드에서 target을 DTO 클래스로 형변환하고 필요한 검사를 하고 errors에 에러 메시지를 설정한다.
2. Member 클래스의 유효성 검사 클래스
public classd MemberValidator implements Validator{
public boolean supports(Class <?> clazz{
return Member.class.isAssignableFrom(clazz);
}
public void validate(Object target, Errors errors){
Member member = (Member)target;
if(member.getEmail() == null){
errors.rejectValue("email", "메시지이름");
}
}
}
** Web Site를 위한 서버를 만들 것이냐, REST API 서버를 만들 것이냐
- Web Site를 위한 서버 : 서버가 많은 일을 수행, Spring 유효성 검사를 사용
- REST API 서버 : 클라이언트가 많은 일을 수행, Spring 유효성 검사를 사용하지 않고 일반 로직으로 유효성 검사를 수행한다.
'안드로이드&IOS 앱 개발자 양성' 카테고리의 다른 글
| 안드로이드&IOS 앱 개발자 양성(67일차) (0) | 2020.07.10 |
|---|---|
| SpringMVC_OracleMybatis - 회원관리 (0) | 2020.07.10 |
| SpringMVC 실습(64 ~ 67일차) (0) | 2020.07.08 |
| 안드로이드&IOS 앱 개발자 양성(65일차) (0) | 2020.07.08 |
| 안드로이드&IOS 앱 개발자 양성(64일차) (0) | 2020.07.07 |