2013년 9월 10일 화요일

MVC Architecture

* MVC Architecture


1) Control이 Servlet 기술에 종속.
2) Control 들의 공통코드를 분리할 필요성이 있다.
3) Control에 URL을 부여하여 Client와의 결합력이 높다.

* 문제점
- 결합력이 높으면 의존하는 객체에 연결을 많이 받는다.

* Facade 패턴(= Facade 패턴을 Control에 적용한 것이 Fromt Controller 패턴.)
- 외부와의 접점을 최소화 시킨다.
- 내부의 복잡함을 감춘다.




2013년 9월 9일 월요일

JSP Servlet

Internationalization (국제화)
= i18n

Localization
= l10n

https://jstl.java.net/ 다운로드. 2개 다운로드하여 libs 폴더에 넣는다.



=================================================================================

Expression Language
- ServletContext, HttpSession, ServletRequest 등으로 부터 데이터를 좀 더 쉽게 꺼내고
-  VO 객체의 getXXX() 메서드 호출을 좀더 쉽게 하기 위해 등장한 문법.
ex)
${appplicationScope.xxx} <== ServletContext
${sessionScope.xxx} <== HttpSession
${requestScope.xxx} <== ServletRequest
${pageScope.xxx} <== pageContext
${xxx} <== PageContext > ServletRequest > HttpSession > ServletContext

















































2013년 9월 4일 수요일

MVC pattern


* 다른 서블릿으로 요청을 위임

1) fowarding



2) including

* JSP 기본객체
- JSP를 가지고 자동으로 생성한 서블릿의 jspService() 메서드에 선언된 객체들.



2013년 9월 3일 화요일

Session

* HttpSession 의 관리.
- 요청시 헤더정보에 Session ID 값이 없으면, HttpSession 객체를 생성한다.
- 응답 할 때 응답헤더에 Session ID를 포함한다.
- 웹브라우저는 Session ID를 받게되면, 메모리에 보관하고, 매 요청시 서버에 보낸다.



* Cookie
- 서버에서 보낸 data를 웹브라우저에서 보관하는 것.
- 서버에 요청 시 SessionID를 주고 받은 쿠키정보를 매번 보낸다.

* getSession()
- 클라이언트에서 보낸 쿠키 정보 중에 SessionID가 있다면, SessionID에 해당하는
  세션 객체를 찾는다.
- 유효 하다면 그 객체를 리턴한다.
- 유효하지 않다면 새로운 객체를 리턴한다.
- SessionID가 없다면, 새로운 세션 객체를 만들고, 그 객체를 리턴한다.

=============================================================================

JSP



C:\javaide\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\web004\org\apache\jsp\test


[JSP 구성 요소]

* 템플릿 데이터(Template data)
- 출력문으로 만들기 위해 그냥 작성하는 텍스트
- out.write()와 같은 출력문으로 변환됨.

* 스크립트릿(scriptlet)
- 자바 코드를 작성하는 태그
- 예) <% 자바코드 %>
- 그대로 자바소스파일에 복사된다.

* 표현식(expression element)
- 변수나 어떤 식의 결과 값을 출력할 때
- 예) <%= 자바 변수나 식 %>
- out.print(자바 변수나 식) 으로 변환된다.

* 지시문(directive element)
- 특정 자바 코드로 변환된다.
- 예) <%@ page import="java.util.*,java.net.*"%>
    => 자바소스 파일에서 import 문으로 변환된다.
- 예) <%@ page contentType="text/html;charset=UTF-8"%>
    => response.setContentType("text/html;charset=UTF-8"); 문으로 변환됨.

* 선언문(declaration element)
- 클래스 블럭에 복사됨.
- 인스턴스 및 클래스 변수/메서드/스태틱블럭
- 예) <%! 인스턴스변수, 클래스변수, 메서드, 스태틱블럭, 초기화블럭 %>  
- 어차피 클래스 블럭에 복사되기 때문에 작성하는 위치에 상관없다.

2013년 9월 2일 월요일

로그인 구현

* 로그인 구현

- Web Architecture 에서 HTML의 용도.
- HTML과 서블릿의 연동 방식의 이해.
- GET 요청과 POST 요청의 차이점.

1. 로그인 폼 (HTML 이용) /auth/LoginForm.html
- HTML을 이용한 UI 생성.

2. 사용자 인증처리 Servlet (LoginServlet.java)
- 이메일과 암호를 조회하여 그 결과를 출력.
- $contextRoot/auth/login

==========================================================================

authentication(인증) : 사용자 있냐/없냐

authorization(권한인증) : 일반사용자/ 관리자 / ... / ... 

위의 두가지를 합쳐서 auth

==========================================================================



head: 웹 브라우저에게 이 문서에 대한 부가 정보를 제공한다.

title: 웹브라우저의 타이틀바에 출력 또는 탭에 출력된다.

body 웹브라우저 내용창에 출력할 것을 기술

form: 서버에 전달할 내용을 수집하는 입력폼 

action: 요청을 전달할 대상이 되는 서블릿의 URL


input: 사용자로부터 입력을 받는 UI 컴포넌트를 생성

type: 입력 상자의 종류(text, checkbox, radio, ..)

name: 서버에 값을 보낼 때 사용할 파라미터 이름(url?파라미터명=값&파라미터명=값...)

value: 서버에 전달할 값. 사용자가 입력한 값

placeholder: 사용자에게 안내하는 문구를 입력 상자에 미리 출력.

submit: 사용자가 입력양식의 값 입력을 마친 후 이를 서버에 보내기 위해 사용.

<br>
- 다음 라인에 이어지는 내용을 출력할 것을 지시. 
- 웹브라우저는 기본적으로 엔터를 무시한다.
- tag의 규칙에 따라 내용을 출력할 뿐이다.       

* Element
- startTag + content + endTag
 
* root element ex) <html>... </html> 
- 가장 바깥쪽에 있는 element 
- 하나의 파일에 root element는 하나만 존재. 

출력은 block방식과 inline방식으로 출력됨.
- block: 한라인 전체를 점유 ex) h1, p, div, ...
- inline: 라인을 그대로 유지 ex) a, i, span, ...

==============================================================================

* Redirect
- 서버의 응답결과에 자동 요청 정보를 포함한다.

* 자동 요청 방법
1) Redirect: ex) 로그인화면 -> 바로 메인화면.

2) Refresh: ex) 로그인화면 -> 로그인성공 화면 출력 -> 메인화면.

GET vs POST
- form 태그는 기본으로 GET 요청을 한다.
- method 속성에 POST를 지정해야 POST 요청을 수행한다.

1) GET 방식
- 요청URL에 데이터를 붙여서 서버에 보낸다.
- URL에 데이터가 포함되어 있기 때문에 검색결과를 공유할 때는 유용하다.

[보안]
- 하지만, URL이 웹브라우저에 캐시되기 때문에 쉽게 노출된다.
- 또한, URL이 웹브라우저 주소창에 보이기 때문에 입력 데이터가 쉽게 노출된다.

[Binary]
- URL에 포함되기 때문에 image, 동영상과 같은 binary 데이터를 서버에 보낼 수 없다.

[전송크기]
- HTTP 프로토콜에서 요청라인의 크기가 제한되어 있기 때문에, 대량의 데이터를 서버에
보낼 수 없다.

2) POST 방식
- HTTP 요청 프로토콜에서 Message body 영역에 데이터를 서버에 보낸다.
- URL을 저장해봐야 입력 데이터를 포함하지 않기 때문에 게시물조회나 검색에
  맞지 않는다.

[보안]
- 보내는 값은 웹브라우저 주소창에 노출되지 않고, 캐쉬되지 않는다.

[binary]
- HTTP 요청정보에서 Message body 영역에 보내기 때문에 binary date 전송이 가능하다.

[전송크기]
- 제약없다.

* HTTP 요청을 구분하여 쉽게 다루는 방법
- GenericServlet을 상속받지 말고, HttpServlet을 상속 받아라.
- get 요청을 처리하고 싶으면 doGet()을 재정의.
- post 요청을 처리하고 싶으면 doPost()을 재정의.
- xxx 요청을 처리하고 싶으면 doXxx()을 재정의.

// 상속 및 구현관계
- public interface Servlet {...}
- public abstract class GenericServlet implements Servlet {...}
- public abstract class HttpServlet extends GenericServlet {...}

DB Modeling

* DB Modeling
- Modeling: 생각하고 있는 바를 글이나 그림으로 표현.
- 데이터의 구조와 상관관계를 표현하는 것.
- 전체 그림(시스템을 다루는 data들)을 빠르게 이해할 수 있다.

1. 테이블 정의
- 컬럼 식별
- data를 구분하기 위한 키 설정.

2. 정규화 수행
- data의 중복 제거
  -> 메모리 절약.
  ->data 신뢰성을 높인다. (무결성)

정규화 방법
1) 제1정규화
- 중복컬럼, 중복data 제거 후 별도 테이블로 정의한다.
- 부모-자식 관계를 맺는다.

2) 제2정규화
- PK(Primary Key)가 두개 이상일 경우

3) 제3정규화
- 어떤 컬럼이 PK가 아닌 일반 컬럼에 중복되는 경우
- 별도 테이블로 분리
- 부모-자식 관계를 맺는다.

3. 도메인 정의
- 컬럼들을 분류하여 하나의 타입으로 정의
- 도메인을 컬럼에 설정
- 컬럼의 정의를 쉽게 변경 할 수 있다.

4. DBMS에 종속적인 물리 모델을 정의한다.

5. 모델을 SQL문으로 전환한다.

============================================================================

http://www.exerd.com/ 다운.

Rendering: 명령어에 맞춰서 화면에 뿌려지는 것.

*관계
1. 식별관계: FK == PK
2. 비식별관계: FK != PK


* N : N 관계 해소
테이블을 한개 더 만든다. (관계테이블)




2013년 8월 29일 목요일

요구사항 식별

* 요구사항 식별
1. Actor 식별 (Primary Actor)
- Actor: 시스템을 이용하는 사람이나 프로세스.
- Supplementary Actor (= Secondary) : 시스템에 의해 이용당하는 다른 시스템.




2. Use-case 식별
- Actor가 시스템을 사용해서 달성하려는 업무목표(사용목표)

Use-case 크기
- 2주 ~ 6주 내에 개발이 가능한 범위
- 체크리스트
 1) 업무에 시작과 끝이 명확해야 한다. (카운트가 가능하여야 한다.)
 2) 한 사람이 한 순간에 한 장소에서 수행하는 작업.
 3) 업무여야 한다. (서로관련이 있는 것들은 한개로 통합한다.)
   ex) C,R,U,D -> xxx관리

3. Use-case 명세서 작성
 1) Use-case 명
 2) actors
 3) pre-condition (사전 조건)
   - Use-case를 시작하기 위한 사전 시스템 상태
 4) post-condition
   - Use-case를 종료한 후 시스템 상태
   - 종료 조건
 5) 기본 시나리오
   - actor와 시스템간의 눈에 보이는 대화.
 6) 예외 시나리오
   - 오류 발생시 actor 와 시스템의 시나리오.

========================================================================

* 시스템이 다루는 Data를 관리