nota's story

4일차는 코딩 위주로 수업해서 생략

#
URL에 따라서 다른 서블릿을 호출하게 되면 서블릿을 여러개 만들어야 하니까,
DisPpatcher Servlet 하나만 사용하고
URL 자체를 명령어로 인식해서, cmd라는파라미터에 따라 액션을 다르게 한다.
어떤 URL이 어떤 명령어인지는 Handler Mapping이 알아서 해주고,
여기서 어떤 명령어인지를 판단하여 Controller를 부른다.
Controller에서는 직접 코딩하여 모델을 만드는게 아니고,
Controller에서는 의지하는 객체를 가지고 있는거...
의지하고 있는 객체는 모델이 되겠지?
이 모델은 또 구현클래스로 두지 말고,
인터페이스를 만들어 추상화하여 loose coupling을 한다.
=> 결합도가 낮아져서 다형성을 가진다.
이때 단순히 인터페이스만 가지고 있는다고 결합도가 낮아지는건 아니고,
팩토리 패턴을 생성하여 어떤 케이스에 따라 어떤 구현 클래스를 사용할지를 결정.

#
SPRING에서는 forward가 디폴트
forward는 url은 그대로 두고, 버퍼의 내용만 변경
다른 컨트롤러 쪽을 호출하기 위해서는 url이 변경돼야 하기 때문에 redirect를 사용
다시 정리해보자면,
action에서 바로 뷰를 보여줄 때는 forward로 가면 되는데
action에서 다른 action으로 가려면 redirect로 가야한다.

#
ORM, AOP, DI 등의 개념은 확실히 알아둡시다.

#
AOP(Aspect Oriented Programming)
관점 지향 프로그래밍. Aspect가 키워드!!!
OOP를 날려버리자 하고 나온게 AOP가 아님
(AOP가 도입된다고 OOP가 사라지는게 아님)

OOP의 장점은 재사용성(중복코드가 줄어듬)
OOP의 단점은 필요없는거까지 상속받는다.
OOP에서는 재사용하기 위해서는 주종관계로 묶여져야 한다는 단점이 있음.

AOP에서는 바라보는 관점에 따라서 핵심코드와 공통소스가 캡슐화되게 해서,
주종관계를 맺지 않고 재사용이 가능.
이때 관점이라는걸 정의하기 위해서 아키텍쳐가 필요.
핵심과 공통을 분리하기 위함이 AOP의 목적.
분리를 하게 되면 뭐가 뭔지 모르기 때문에 이 핵심코드와 공통소스 캡슐화 등을 알아서 해주는걸 각종 프레임웍에서 문법에 의해 해준다.

운전을 예로 들면, 운전을 하기 위해 차를 빼고 다시 주차하는게 공통소스
운전을 해서 여행을 가든 출퇴근을 하든 하는게 핵심코드
운전자가 원하는건 운전을 하는거지, 차를 빼고 주차하는게 아니다.
이 차를 빼고 주차하는걸 공통소스로 관리.

밥먹는걸 예로 들면, 밥을 먹기 위해 상을 차리고 다먹고나서 설거지를 하는게 공통소스
밥을 어떻게 잘 먹는게 핵심코드
식충이가 원하는건 밥을 먹는거지, 상을 차리고 설거지를 하는게 아니다.
이 상을 차리고 설거지를 하는걸 공통소스로 관리

*advice : what과 when이 결합된 것
공통관심 사항을 핵심로직에 언제 적용할 것인가를 정의

*joinpoint : where의 의미
공통관심사항을 적용할 수 있는 애플리케이션의 실행지점
advice를 적용하는 지점

*pointcut : advice가 실제로 적용되는 jointpoint

#
오늘 MVC Spring, DB적용
다음시간에 DI적용하여 어플만듬
그다음시간에 AOP 등 마무리

#
ORM은 Object Relation Mapping : 즉, 다른 프레임워크와 연동하는 것.

#
Spring MVC
Model : 모델 자체가 컴퍼넌트, 컴퍼넌트 자체가 자바로 코딩한 비즈니스 로직.
View
Controller
모델과 뷰를 구분하고자 하는 형식이 MVC
여기서 모델이 주코드와 부코드로 나뉘게 됨.

#
<Spring MVC의 큰 흐름>

1.
Client에서 Dispatcher Servlet으로 가는건, web.xml에서 설정
(.do일때 이 서블릿으로 가라는걸 설정.)
서블릿은 요청을 처리해주고, 전체 관리하는 역할을 함.
Dispatcher 서블릿은 Spring에서 제시하는 서블릿.

2.
이때 .do로 통일하면 하나의 서블릿이기 때문에, 어떤 서비스를 해야할지 단서를 붙여서 호출해야 하는데
이걸 해주는게 Handler Mapping(기존 MVC에서는 'list.do?cmd=login' 이런식으로 처리했음)

3.
Dispatcher 서블릿에서 이 호출이 어떤 요청인지 Handler Mapping을 통해서 판단
(커맨드와 비즈니스 로직을 맵핑)

4.
 Controller는 기존MVC의 Action과 같은 역할.
컨트롤러에서 비즈니스 로직 등을 구현.
DI를 적용시켜서 로직, DB 등과 관련된걸 불러오고 처리.

5.
ActionForward를 통해서 ModelAndView를 설정하여 Dispatcher Servlet으로 넘김

6.
Dispatcher Servlet에서 ViewResolver를 불러서 어떤 뷰를 불러올지 결정

#
211.63.89.30

#
샘플로 만든 MVC프로젝트에서,
jsp에서 .do?cmd=login url 이동
=> web.xml에서 읽고 Action Servlet으로 가서 service 메서드 호출
=> ActionServlet에서 cmd를 받아서, getAction 호출
=> Action Factory의 getAction에서 cmd 값에 따라서 어떤 모델을 부를건지 결정
=> 이 받은 action을 가지고 action.execute 실행
=> execute를 ActionForWard가 받아서, true면 sendRedirect// false면 requestDispatcher 호출

#
객체를 속성과 기능과 함께 인스턴스화 할 때(OOP) 한계가 있다
그래서 객체를 만들어서 서로 협업(조립)시킨다 => Framework

설계도(클래스, 객체)를 만드는 이유 : 재사용성을 위함

Spring에서의 협업 : Extend가 아니라, POJO(평범한 자바)로 가지고 있는(haser) 개념으로 가고, 이를 이용해 협업한다. 이때 코드를 분리하고 조립(factory)하게 된다.

메인부에서 객체를 선언하고, 어떤걸 만들지 조립하고, 호출하는게 일반적인 개발의 흐름
근데 이렇게 하면 개발자가 공식대로 다 만들고, 일정한 패턴으로 코딩해야함
프레임워크에서는 IOC 컨테이너를 서비스해서, 얘네 문법만 익히면 기본적인 패턴이나 문법이 적용된 상태로 코드를 분리할 수 있고 조립할 수 있다

Spring 모듈중에 Core가 있고, 그 안에 DI가 있음. 이는 협업하는 객체를 wiring해줌. => 코드의 분리 + 확장성 향상

문법에서 set은 집어넣고, get은 반환하는 건데..
@Required를 하면 반드시 DI를 하도록 한다.
@Autowired를 하면 자동으로 묶어준다.(DI해준다)

xml을 보면 bean으로 객체를 만들고, property를 만듬.
예시에서 person이 book을 가지고 있다.
book이 1개뿐이면 person과 book이 같은 타입이니까 잘 가져오게 되는데(book을 person에 DI시키는데),
book이 2개라면 타입이 겹치니까 이름으로 가져올 수밖에 없음. => annotation으로 해결 가능

setBook에 @Requried만 쓰면 에러가 남(DI를 안 해놨으니까)
거기에 @Autowired를 추가하면 에러가 사라짐(하나하나 bytype으로 DI가 되니까)
참고로, 바로 bean에 접근하는 resource 개념이 있음
그리고 bean에 안 만들어줘도 다른 annotaion을 이용해서 가능하도록 할 수 있다.

내가 primitive 자료형(기본자료형) 혹은 레퍼런스 자료형(오픈 api)를 가지고 있을 수 있는데,
이를 DI시켜서 루즈 커플링해서 사용하는게 spring framework의 핵심

spring에서는, xml뿐만 아니라 java 소스만으로 DI를 시켜줄 수 있도록 제공한다(@bean).
기존의 방식인 xml로 DI시키는 것도 있고, java 소스로 DI시키는 것도 있고 함께 사용할 수 있음.

#
@Qualifier를 사용하면 값을 넣을 수 있음
setBook 메서드 위에다가 쓰면 객체가 하나라면 괜찮은데 여러개일 경우 여러개에 모두 한 value만 들어가게 되니까, 파라미터에다가 하나씩 붙여주면 값을 넣을 순 있음.

# MVC
- 웹은 전부 MVC로 되어있음(Spring, 전자정보 등등)
- 모델과 뷰를 분리함

# Spring MVC
- Client가 Dispatcher Servlet을 호출(요청을 위해)
=> 이때 Spring에서는 url 전체를 command로 본다.
- 서블릿이 호출되면 Handler Mapping이 불러와짐(키, 밸류 형태로 어떤 액션을 할지 맵핑)
- 핸들러맵핑이 확인해서 관련된 컨트롤러를 불러옴
- 컨트롤러가 ModelAndView를 디스패쳐 서블릿에 넘겨줌
- 확인해서 ViewResolver를 불렀다가 View를 볼러옴

#
http://www.springsource.org/download/community
위 링크 통해서
spring-tool-suite-3.1.0.RELEASE-e3.8-win32-installer
spring-framework-3.0.1.RELEASE-A-with-docs
spring-framework-3.0.1.RELEASE-A-dependencies
다운로드

#
framework : 작업환경
spring : 봄 =. 따뜻한 환경에서 공부하라고 로드존스가 만듬
spring framework : 오픈API, 경량의 컨테이터

#
IOC 패턴 : 제어 역행. 프로그램의 흐름이 역으로 변하는 것.
일반적인 흐름 필요한 객체를 생성 -> 조립을 함 -> 호출함
제어역행은 객체를 만들고 조립하는 과정을 위임하는 것(spring framework한테 위임)
http://vandbt.tistory.com/43

#
팩토리 : 객체를 어떻게 생성할 것인가, 어떻게 조립할 것인가, 생성한 객체를 어떻게 돌려줄 것인가를 고민하는 방법

#
POJO(Plain Old Java Object)
: 옛날 자바. Extend Object가 생략되어있고, Action으로부터 상속을 받음.
단일상속을 사용하면 inner class를 사용해야하고 확장성이 적고 등등 여러가지 문제
이저가 아니라 해저로 하자(가지고 있자).
만약에 그 레퍼런스가 없으면 내가 다 만들어야 하잖아
객체가 들어와야 하는데 구현객체가 들어오면 안되니까, 패턴에 의해서 framework로부터 그걸 받는다
포조가 나왔기 때문에 spring이 더 발전하지 않았나...

#
Spring framework 모듈 구조
OOP 기반이고, AOP가 OOP를 도와주는 개념으로 들어옴. AOP는 원래 있던 이론인데, 이를 spring에서 도입해서 개발자에게 서비스 하는 것임
Core에는 IOC 개념이 들어감
ORM에는 객체를 연결해서 매핑. 다른 프레임웤과 연동할 때 사용
DAO는 JDBC 사용을 지원하기 위함.
스프링 MVC 를 알기 위해서는 일반 MVC가 뭔지 알아야 이해가 됨

#
팩토리 패턴

#
스트레이지 패턴

#
커맨드 패턴

#
DI모듈

#
spring-tool-suite-3.1.0.RELEASE-e3.8-win32-installer 설치
STS.exe 실행하여 뉴프로젝트 - 스프링프로젝트 생성함
뉴 패키지, 뉴 클래스 생성
java 파일 안에 private 2개 만든다음에
ctrl + space + o 로 객체 생성
java파일 우클릭 - new - spring configuration.. .눌러서 xml 파일 생성

* bean : IOC 기반의 factory.
bean에 id, name있음. id가 좀 더 제약이 없기 때문에 id를 보통 씀
bean에 class경로 잡아줌 => 실질적으로 일할 땐 어노테이션을 많이 씀(class 일일이 잡아줄 필요 없음)
scope에 있는 prototype : 매번 계속해서 객체가 생성됨, singleton : 한번만 생성됨(static개념). 디폴트는 싱글톤.
property로 넣으려면 getter, setter가 생성되어있어야 함
alt + shift + s => r 누르면 getter .setter 생성
alt + shift + s => s 누르면 toString생성됨

*spring container = ioc container

*bean들만 팩토리하는게 beanFactory

#
플럭시 패턴

#
Dpendency Injection(DI : 의존성 주입)
A클래스와 B클래스가 있을 때 B를 A로 DI하게 되면, B의 소스를 고칠 때 A에 있는 수많은 사용부분을 고쳐야 하게 된다.(결합도가 너무 높다)

#
bean 아래의 constructor 생성 관련 교육