[KH정보교육원 당산] 66일 (SpringFramework - DI)

프레임워크는 개발에서 기본이 되는 뼈대, 틀을 제공
즉, 개발자에게 모든것을 위임하는 것이 아니라
애플리케이션의 기본 아키텍쳐는 프레임워크가 제공하고, 그 뼈대에 살을 붙이는 작업만한다.

일반적으로 시스템을 개발하는 과정에서 대부분의 개발자들은 산출문에 입각하여 개발,
아키텍처의 일관성이 잘 유지된다.

프레임워크 사용 장점

Presentation 처리 영역 : Spring(MVC)
=> MVC 아키텍처를 제공하는 UI Layer 프레임워크 / Spring 프레임워크에 포함

Business 처리 영역 : Spring(IoC,AOP)
=> 컨테이너 성격을 갖는 프레임워크
      IoC,AOP 모듈을 이용

Persistence 처리 영역 : MyBatis
=> SQL명령어와 자바 객체(VO,DTO)를 매핑해주는 기능
      기존에 사용하던 SQL명령어를 재사용하여 개발하는 차세대 프로젝트에 유용하게 적용할 수 있다.


POJO => 예전의 자바 객체를 의미(일반 자바 클래스 객체)

POJO가 아닌 클래스 : servlet클래스
javax.servlet / javax.servlet.http 패키지 import
public클래스로 선언
Servlet, GenericServlet,HttpServlet 중 하나를 반드시 상속
doGet(),doPost() 재정의 필요

제어의 역행(Inversion of Control)
=> 비즈니스 컴포넌트를 개발할 때, 신경을 써야하는 부분: 낮은 결합도/높은 응집도

IoC가 적용되기전
: 애플리케이션 수행에 필요한 객체의 생성, 객체와 객체 사이의 의존관계를 개발자가 직접 자바코드로 처리

IoC가 적용된 후
: 객체 생성을 컨테이너가 대신 처리, 객체와 객체 사이의 의존관계가 사라짐

AOP

 => 핵심 비즈니스 로직과 각 비즈니스 메서드마다 반복해서 등장하는 공통 로직을 분리함으로써
       응집도가 높게 개발할 수 있도록 지원

공통적으러 사용하는 기능들을 외부 클래스로 분리

컨테이너(Container) 
=> 특정 객체의 생성과 관리를 담당,
     객체의 운용에 필요한 다양한 기능을 제공,
     일반적으로 서버 안에 포함되어 배포 및 구동
대표적인 컨테이너 :

servlet 컨테이너 => servlet 객체를 생성하고 관리(tomcat서버에 포함)
EJB컨테이너 : EJB 객체를 생성하고 관리
스프링 : 애플리케이션 운용에 필요한 객체를 생성, 객체간의 의존관계를 관리

Servlet은 자바로 만들어진 클래스
따라서 반드시 객체 생성을 해야 객체가 가지고 있는 메서드도 호출가능

Servlet컨테이너가 HelloServlet 클래스 객체를 생성하고 doGet()메서드를 호출

Servlet 컨테이너 동작 순서
1.web-ing / web.xml 파일을 로딩하여 구동
2.브라우저로부터 요청된 /hello.do 수신
3.com.jdh.biz.HelloServlet 클래스를 찾아
4.객체를 생성하고, doGet()메서드를 호출
5.doGet() 메서드의 실행 결과를 클라이언트 브라우저로 전송

스프링 컨테이너 역시 Servlet컨테이너와 유사하게 동작하므로
위와 비슷한 요소들이 존재한다.

제어의 역행(IoC)은 결합도와 관련된 개념으로 이해

기존 자바 기반 방식으로 애플리케이션을 개발할 경우
개발자가 객체들을 생성하고 객체들 사이의 의존관계를 처리.

 

---

Spring 사용방법
1. 스프링 프레임워크를 이용한 새로운 프레임워크 개발
  => 이클립스(인텔리제이) 내부에 라이브러리를 설치
  => 주로 대기업 / 전자정부

2. 스프링 프레임워크를 이용해서 프로젝트
  => 이클립스,인텔리제이 내에 스프링 플러그인을 설치
  => 스프링 전용툴 사용(STS)

 

 

** 기존 프로젝트 구조 = export하지 못한다.(DynamicWeb 구조로 보내진다.)
war파일로 export

라이브러리 관리 : 인터넷(Maven) => pom.xml

 

Spring legacy project - MVC project 이러한 구조를 가지고 있다.

 

 

 

---

 

프로젝트를 처음 생성한 후에 에러가 날것이다.(Build Path)

pom.xml을 열어서 환경을 먼저 설정해준다

자바는 1.8 버전을 사용할 것이고, 스프링은 4.3.4버전을 사용

자바 버전 및 스프링 버전

자바버전과 같게 맞춰준다.

 

마찬가지로 자바버전 설정 

 

서버 추가

사용할 서버 추가

 

---

기본 설정 라이브러리

라이브러리 관리는 Maven을 통해서 한다.(pom.xml 에서 추가/삭제)

 

spring-beans => 빈즈 태그에 관련된 라이브러리
spring-core => 스프링에 관련된 함수나 메서드관련 라이브러리
spring-expression => 스프링에 관련된 연산관련 라이브러리
spring-webmvc => mvc에 관련된 라이브러리

junit => 테스트를 위한 라이브러리
log4j => 로그를 찍어보기 위한 라이브러리
javax.inject => 의존성주입을 위한 라이브러리
aspectjrt => 관점지향프로그래밍

 

 

 

---

일반적으로 객체 사용하던 방법
StarBucks 클래스 
MegaCoffee 클래스
Consumer 메인클래스

각각 역할을 클래스마다 생성하여 메인클래스에서 호출시에 각 클래스마다 객체를 생성하여 호출
=> 결합도가 높다.(자바 소스 코드)

인터페이스 사용(다형성)
Coffee 인터페이스 생성

인터페이스를 생성하여 해야할 일을 정의해 놓는다. 각 클래스마다 인터페이스 구현

=> 결합도가 전에 쓰던 방식보다 낮아짐.

Factory패턴
BeanFactory

** BeanFactory클래스 생성

public class BeanFactory {

	public BeanFactory() {
	}
	
	public Object getBean(String beanName){
		if(beanName.equals("starbuks")){
			return new StarBucks(); 
		} else if(beanName.equals("megacoffee")) {
			return new MegaCoffee();
		}
		return null;
	}

}

resource 폴더안에 xml문서를 생성한다.

빈 태그를 통하여 해당 클래스 객체를 생성

<beans ~~~~~~~~>
	<bean id="starbucks" class="com.jdh.test.StarBucks" />
</beans>

빈의 이름이 starbucks 이므로 BeanFactory를 통하여 해당 클래스 객체를 생성하여 리턴
=> 결합도를 더 낮춤

 

 

---

빈 라이프 사이클

<bean name="특수기호가능" class="클래스의정확한경로" init-method="메서드명" destory-method="메서드명">
</bean>

 

StarBucks 클래스에 추가된 메서드 이다.

// 항상 먼저 실행
	public void initMethod() {
		System.out.println("객체 초기화");
	}

// 다른 메서드가 다 실행된후 마지막에 실행
	public void destory() {
		System.out.println("객체 삭제");
	}

 

메서드명이 initMethod 이므로 bean태그 안의 init-method 속성은 initMethod로 해야한다.

destory도 마찬가지

 

init-method => 클래스를 이용하여 객체가 만들어지고 해당객체가 getBean()에 의해 반환되기 직전
즉, 초기화 직전

1. id생성
2. init-method 초기화 직전
3. ~~실행내용
4.destroy-method 소멸직전 *확인하는 방법 : 해당 객체를 관리하는 컨테이너를 자원해제
5.소멸

 

 

---

생성자를 통한 의존성 주입

기존의 CheeseCake와 CarrotCake 생성 했고, Cake라는 인터페이스 생성하여 각 카페들한테 구현 시킨다.

 

pom.xml 수정

<bean id="starbucks" class="com.jdh.test.starbucks">
	<!-- 스타벅스 객체 안에 치즈케이크를 넣어줄것이다.. -->
	<!-- 먼저 치즈케이크 객체를 생성한 후에 생성자를 통하여 객체를 넣어준다. -->
	<constructor-arg ref="cheesecake"></constructor-arg>
</bean>

<bean id="cake" class="com.jdh.test.CheeseCake"></bean>

StarBucks 클래스의 생성자

public StarBucks() {
		System.out.println("스타벅스 객체 생성");
	}

	public StarBucks(Cake cake) {
		System.out.println("치즈케익 오더");
	}

생성자를 통하여 의존성을 주입 시킬때는 <constructor-arg ~~>태그를 사용한다.

** 만약 생성자를 통해 객체를 주입할 경우
<constructor-arg ref="객체명"></constructor-arg>
또는
<constructor-arg>
	<ref bean="객체명" />
</constructor-arg>

** 생성자를 통해 일반데이터를 주입할 경우
<constructor-arg value="데이터"></contructor-arg>
또는
<constructor-arg>
	<value type="데이터타입">데이터</value>
</constructor-arg>

빈 태그를 통하여 CheeseCake값을 전달 하였으므로 해당 Cake를 받을 변수가 있어야한다.

이때 당근케이크든 치즈케이크든 상관없이 받을 수 있는 Cake라는 인터페이스를 구현 했기 때문에 데이터타입은 Cake가 된다.

 

---

기존 코드를 생성자를 통한 주입이 아닌 

setter를 통한 주입 방법

 

StarBucks의 전역 변수로 private Cake cake; 생성 후 setter를 만든다.

 

pom.xml 수정

<bean id="starbucks" class="com.jdh.test.StarBucks">
	 <property name="cake" ref="cheeseCake"></property>
</bean>
	 
<bean id="cheeseCake" class="com.jdh.test.CheeseCake"></bean>

 

<bean~~~>
     <property name="멤버변수명" ref="객체명" />
</bean>

 여러개의 private 멤버변수에게 전달할 경우
<bean~~~>
    <property name="멤버변수명" ref="객체명 />
    <property name="멤버변수명" ref="객체명 />
    <property name="멤버변수명" value="데이터" />
.
.
</bean>

 

**   set을 통하여 값이 전달 되기 때문에 기존에 있던 생성자는 지워준다.

 

 

property 태그를 사용하지 않는 방법도 있다.

 

pom.xml -> Namespaces 에서 p ~~~~~~~~를 선택한 후 저장

<beans ~~~> 내부에 아래 코드가 추가 된것을 볼 수 있다.

xmlns:p="http://www.springframework.org/schema/p"

p:변수명-ref="참조할 객체의 이름이나 아이디"

 

기본형이나 문자형 변수에 직젒 값을 설정할 경우

p:변수명="설정할값"

 

---