[SpringFramework] 일간 뷰어 인터뷰_ 스프링 프레임워크 기초 편

스프링 프레임워크 기초 편

Q. 이제 본격적으로 ‘프레임워크’에 대해서 알아보도록 하겠다. ‘프레임워크’란 무엇인가?

프레임워크(Framework)는 말 그대로 ‘뼈대, 틀’을 뜻한다. 앞서 MVC 패턴 모델2에는 초기 디자인 시간
이 많이 걸린다는 단점이 있었다. 똑똑한 개발자들은 이 문제를 해결하고 싶었다. 그렇기에 자주 쓰는
디자인 구조를 구조화 시켜놓고 이를 ‘프레임워크’라고 부른다. .

간단하게 정리하자면 다음과 같다.

• 프레임워크

– 뼈대 혹은 틀

– 소프트웨어 관점 : 아키텍처에 해당하는 골격 코드

• '아키텍쳐' , '골격'

– 애플리케이션을 개발할 때 가장 중요한 것이 애플리케이션의 구조를 결정하는 것이 아
키텍처인데 이 아키텍처에 해당하는 골격 코드를 프레임워크가 제공한다.

예) 컵을 만든다. A와 B는 자유롭게 컵을 만든다. A의 퇴사, A가 만든 컵을 고쳐야 한다....

이렇게 미리 디자인 틀을 만들어 놓으면 매번 새로운 틀을 설계할 필요가 없다.

더불어 프로젝트를 하는 경우, 미리 만들어 놓은 체계적인 틀을 사용하면 유지보수가 용이하다.
특히나 여러 사람들을 거쳐서 수정이 이루어지는 경우, 공유되는 큰 틀이 있다면 이해가 빠르다.

프레임워크의 장점을 정리해보자.

Q. 스프링 프레임워크가 하는 역할은 정확하게 무엇인가?

스프링 프레임워크가 하는 역할을 그림으로 정리하자면 다음과 같다. 역시나 불펌 그림이다.

이 그림에서 스프링프레임워크가 하는 일은 파란색 선으로 표시했다.

mvc 프레임워크는 화면구현 POJO 생명주기는 모델처리 daO/ or MAAPING은 MYBATIS  

Q. 스프링 프레임워크의 주요 특징은 무엇인가? 스프링 프레임워크만의 큰 장점이 있기에 사람들이
많이 사용하는 것이 아닌가.

스프링 프레임워크의 주요 특징을 정리하면 다음과 같다.

이때 ‘영속성과 관련된 다양한 API를 제공한다’ 항목은 뉘앙스가 어렵지, 정작 실습해보면 별거 아니다.
우리는 여태까지 사용하고 싶은 라이브러리들을 다운받고 이를 buildPath나 복붙을 통해 라이브러리를 추가했다.

그러나 스프링프레임워크에서는 web.xml에서 적어주면 자동으로 라이브러리가 추가된다.

Q. DI에 대해서 구체적으로 설명해달라. AI도 아니고 DepenDency Injection 의존성 주사가 대체
무슨 말이란 말이냐.

DI(DepenDency Inject)을 설명하기 위해 그림을 불펌하겠다.

이 그림을 예시를 보아라. 본래 classA에서 class B 객체를 불러와 사용하려면 new B()를 불러와  
변수 B b에 넣고 사용해야 한다.

그러나 스프링프레임워크에서는 new B()로 인스턴스를 생성하지 않아도 스프링이 자동으로 객체를
생성하여 주입해준다. 그러나 대신에 set 메서드를 선언해주어야 한다. 예를 들어 class A에서 스프링 상에서
class B의 객체를 불러와 B b의 변수에 넣어 사용하고 싶다. 그러면 변수 선언 시에는 B b만 선언 해준 뒤,

class A의 안에서

public void setB(B b){

this.b = b

}

메서드를 선언해준다.

위의 예시를 실행하기 위해 해야할 일은 다음과 같다.

1. A 인스턴스 생성
2. B 인스턴스 생성
3. setB(B b)메서드 선언

Q. 굳이 메서드까지 만들면서 왜 DI를 사용하는가? 더 번거롭지 않나.

DI를 사용하는 이유는 의존성을 낮추기 위함이라 할 수 있다.

그림을 통해 이를 설명하겠다.

당황해 하지 말아라. 두 번째 그림은 첫 번째 그림을 단지 예시화 시킨 것이다.

인터페이스에 정의해야 하는 메서드들을 미리 정의해둔다. 이때 인터페이스에 있는 메서드들은
알맹이가 없으며, 단지 제목만 정의할 뿐이다. 제목만 있는 메서드들을 정의해놓은 인터페이스는
목차와 같다.

그 후, 정의해야하는 메서드들을 jdbcDao 또는 ibatisDao 등의 클래스들로 구현해준다.

구현 후, 서비스 클래스에서 인터페이스에서 정의한 메서드를 사용하고 싶다. 그렇다면, 메서드를
구현한 클래스(jdbcDao 클래스와 ibatisDao 클래스) 중에서 원하는 것을 선택해서 사용한다.
이때 원하는 클래스*(‘빈(bean)’이라고 한다)를 골랐으면 이를 xml 설정에서  등록* 해야 한다는 것을 잊지말자.

이렇게 하면  서비스 클래스의 의존성을 낮출 수 있다. 왜냐하면 ‘이 클래스가 아니면 안돼’의 neccesary가
아니라 ‘이 클래스도 괜찮고 저 클래스도 괜찮네’의 option이 되기 때문이다.

참고로 jdbcDao든 ibatisDao든 서비스 클래스에서 가져와서 사용하는 클래스들의 기능은 같다.  

*사용하기 원하는 클래스를‘빈, Bean’이라고 부른다. 빈을 보관/설정하기 위해 xml 설정 파일에 등록한다.  

* xml 파일에서 클래스 등록 접수처리를 받고 서비스 클래스에 객체를 생성 한 뒤 이를 주입 해주는
역할의 친구 이름이 ‘컨테이너*’이다. 이 큰 과정을 ‘역행 제어’라고도 하는데 용어는 몰라도 된다.

*’컨테이너’. 다루는 김에 역할 정의를 해보자. 스프링 컨테이너는 객체관리(생명주기 - 생성, 주입, 삭제)담당이다.  

이 그림의 진행 과정을 서비스 클래스 입장에서 정리하자면 다음과 같다.

(1) 서비스 클래스에서 객체 생성

(2) 원하는 기능에 해당하는 클래스를 선택하여 xml에 등록(그 후 컨테이너가 처리)

(3) 서비스 클래스에서 xml에 등록한 클래스를 끌어와 사용하기.

Q. xml에 사용하고자 하는 클래스를 등록하는 방법은 어떻게 되는가?

스프링 DI를 설정하는 방법은 크게 두 가지가 있다.

1. 스프링의 DI 설정: 생성자 방식
2. 스프링의 DI 설정: 프로퍼티 방식

<!-- 빈(객체) 등록, 관계 설정(의존 설정) : 생성, 반환, 삭제-->

<bean id="jdbcDao" class="member.dao.JdbcDao"></bean>

<bean id="mybatisDao" class="member.dao.MybatisDao"></bean>

<bean id="dao" class="member.dao.MemberDao"><qualifier value="newDao" /></bean>

(1)생성자 방식.

<!-- 스프링의 DI 설정: 생성자 방식 -->

<bean id="memberRegSvc" class="member.service.MemberRegService">

0. <constructor-arg ref="mybatisDao"/>

1.

<constructor-arg>

<bean class="member.dao.MybatisDao"/>

</constructor-arg>

2.

<constructor-arg>

<ref bean="mybatisDao"/>

</constructor-arg>

</bean>

셋 다 같은 의미이다.

0과 2번은 member.dao.MybatisDao의 id를 적어 준 것이고, 1번은 클래스 자체를 적어준 것이다. 한번만 사용한다면 1번이 더 효율적이다.

(2) 프로퍼티 방식

1.

<bean id="memberDeleteSvc" class="member.service.MemberDeleteService">

<property name="dao"*>

<ref bean="mybatisDao"/>

</property>

<bean>

2.

<bean id="memberDeleteSvc" class="member.service.MemberDeleteService" p:dao-ref="mybatisDao"/>

Q. 스프링 프레임워크의 모듈?