모델2에서 Front Controller패턴으로
모델2에서 Front Controller패턴으로
Front Controller 적용원인
1. 각 컨트롤러 사이의 중복적인 코드의 문제
2. 개발자의 개발패턴의 차이
=> 이로인해 모델2방식은 좀 더 강제적인 형태인 Front Controller방식을 적용
<참고문헌 : 코드로 배우는 Spring 웹 프로젝트>
'전공서적 > 코드로 배우는 Spring 웹 프로젝트' 카테고리의 다른 글
| 모델2패턴의 이해 (0) | 2017.10.24 |
|---|
모델2패턴의 이해
모델2패턴의 이해
스프링 MVC는 모델2방식 구조르 이요하기 때문에 이론적으로 모델2방식에 대한 이해가 필요하다
최근의 모든 웹 개발은 거의 모델2방식을 사용한다.
모델2방식은 흔히 MVC구조를 응용하는 것이라고 생각하는데 가장중요한것
모델2구조에서는 다음과 같은 용어들이 사용된다
모델(Model) |
데이터 혹은 데이터를 처리하는 영역을 의미한다 |
뷰(View) |
결과 하면을 만들어 내는 데 사용하는 자원이다 |
컨트롤러(Controller) |
웹의 요청(request)을 처리하는 존재로 뷰와 모델사이의 중간 통신 역할을 한다 |
컨트롤러는 모델계층과 연동해서 필요한 데이터를 처리하고, 결과를 뷰로 전송하게 된다.
모델2방식의 장점 |
개발자와 웹 퍼블리셔의 영역을 분리할 수 있다 |
컨트롤러의 URL을 통해서 뷰를 제어하기 때문에, 뷰의 교체나 변경과 같은 유지보스에 유용 |
<참고문헌 : 코드로 배우는 Spring 웹 프로젝트>
'전공서적 > 코드로 배우는 Spring 웹 프로젝트' 카테고리의 다른 글
| 모델2에서 Front Controller패턴으로 (0) | 2017.10.24 |
|---|
함수 호이스팅
함수 호이스팅
<참고문헌 : 인사이드자바스크립트>
'전공서적 > 인사이드자바스크립트' 카테고리의 다른 글
| 배열 (0) | 2017.10.26 |
|---|---|
| 객체비교 (0) | 2017.10.25 |
| 자바스크립트 참조타입(객체타입) (0) | 2017.08.30 |
| null 과 undefined (0) | 2017.08.30 |
| 문자열 (0) | 2017.08.30 |
자바스크립트 참조타입(객체타입)
자바스크립트 참조타입(객체타입)
<참고문헌 : 인사이드자바스크립트>
'전공서적 > 인사이드자바스크립트' 카테고리의 다른 글
| 객체비교 (0) | 2017.10.25 |
|---|---|
| 함수 호이스팅 (1) | 2017.08.31 |
| null 과 undefined (0) | 2017.08.30 |
| 문자열 (0) | 2017.08.30 |
| 참조타입의 특성 (0) | 2017.08.25 |
null 과 undefined
null과 undefined
//null타입 변수 생성
<참고문헌 : 인사이드자바스크립트>
'전공서적 > 인사이드자바스크립트' 카테고리의 다른 글
| 함수 호이스팅 (1) | 2017.08.31 |
|---|---|
| 자바스크립트 참조타입(객체타입) (0) | 2017.08.30 |
| 문자열 (0) | 2017.08.30 |
| 참조타입의 특성 (0) | 2017.08.25 |
| for in 문과 객체 프로퍼티 출력 (0) | 2017.08.10 |
문자열
문자열
var str = 'test';
'전공서적 > 인사이드자바스크립트' 카테고리의 다른 글
| 자바스크립트 참조타입(객체타입) (0) | 2017.08.30 |
|---|---|
| null 과 undefined (0) | 2017.08.30 |
| 참조타입의 특성 (0) | 2017.08.25 |
| for in 문과 객체 프로퍼티 출력 (0) | 2017.08.10 |
| Javascript 문자열 (0) | 2017.08.06 |
참조타입의 특성
참조타입의 특성
//1번
var objA = {
val : 40;
};
//2번
var objB = objA;
console.log(objA.val); //(출력값) 40
console.log(objB.val); //(출력값) 40
//3번
objB.val = 50;
console.log(objA.val); //(출력값) 50
console.log(objB.val); //(출력값) 50
1번
objA 객체를 리터럴 방식으로 생성
여기서 objA변수는 객체 자체를 저장하고 있는 것이 아니라 새성된 객체를 가리키는 참조값을 저장
2번
변수 objB에 objA값을 할당.
objA는 1번에서 생성된 객체를 가리키는 참조값을 가지고 있으므로 변수objB에도 이같은 객체의 참조값이 저장
-> 즉, 아래 그림같이 objA와 objB 변수가 동일한 객체를 가리키는 참조값을 가지게 되는 것
=> 따라서 a.val과 b.val값이 40
objA ->
val : 40
objB ->
3번
변수 objB가 가리키는 객체의 val값을 40에서 50으로 갱신
이때 변수 objA도 변수 objB와 동일한 객체를 참조하고 있으므로 a.val값이 50으로 변경
<참고문헌 : 인사이드자바스크립트>
'전공서적 > 인사이드자바스크립트' 카테고리의 다른 글
| null 과 undefined (0) | 2017.08.30 |
|---|---|
| 문자열 (0) | 2017.08.30 |
| for in 문과 객체 프로퍼티 출력 (0) | 2017.08.10 |
| Javascript 문자열 (0) | 2017.08.06 |
| Javascript 기본타입 (0) | 2017.08.06 |
애자일 정리
프로젝트를 실패하는 이유
같은 목표라도 생각의 차이가 있기 때문에 일의 우선순위 or 기능을 생각하는 가치의 차이
서로가 다른 목표와 문제점을 갖고 있기때문에 핵심이 모호해짐
애자일 등장배경
( 우선 애자일을 사용한다고 해서 생산성이 높아지는 것은 아님 )
- S/W개발의 환경변화
- 결과물의 배포시기가 중요해짐 (얼마나 완성됐는지 한눈에 볼 수 있어서 애자일 선택)
- 개발 생산성 저하
- 폭포수형 개발 방법론에 대한 반대 운동으로 시작
『폭포수 모델』
장점 |
단점 |
낮은 복잡성 진행과정을 세분화하여 관리가 용이 전체과정에 대한 이해 용이 |
소프트웨어 거대화 및 요구사항 구체화가 어려움 시스템이 개발완료되는 시점에야 완성가능 각 진행단계에서 문제 시 그 이전단계로 피드백되는 경우발생 |
기존 방법론의 한계 | |
| 문서 및 절차 위주의 방법론 -> 변화대응에 어려움 개발자의 개발능력의 차이로 인한 불안정 | |
애자일 방법론 정의
- 더 나은 의사소통
- 지속적인 변화관리
ex)
만들다 보니 추가, 변경된 기능 or 고객변심 - 우선순위에 다라 중요한 것 먼저 ㄱㄱ
ex)
우리조는 백로그작성 후 각자 개발할 것 중 우선순위대로 포스트잇붙임
애자일 기본가치 (애자일 선언문)
- 프로세스와 도구중심이 아닌, 개개인과의 상호 소통을 중시한다(자주 보여주는 피드백)
- 문서중심이 아닌, 실행 가능한 소프트웨어를 중시한다
- 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다
- 계획중심이 아닌 변화에 대한 민첩한 대응을 중시한다
- 단순함, 해도되고 안해도되면 최대한 안하게하는 기교 (일을 단순화 시킬 수 있어야 한다)
메일발송 시스템 에러
메일발송 시스템 에러
에러 종류
com.sun.mail.smtp.SMTPSendFailedException
메일 발송 시 from쪽 로그인이 안되어 있는 경우
또는
메일 발송하는(ex. gmail)메일가서 보안 수준을 낮추는 방법
이 외에도 방법이 있겠지만
난 이 방법으로 오류해결
