[Spring] Spring Framework 도입 / POJO / IOC / DI Container

Spring Framework에는 Spring MVC Fattern, Spring DI, Spring JDBC, Spring AOP, Spring Security 등 여러가지가 포함되어 있음. 
이렇게 여러개의 모듈들이 합쳐진 것이 통틀어서 Spring Framework임.

하나하나가 완벽한 Component이므로 꼭 Spring에서 제공하는 거 다 안 써도 됨. 다른 거 끼워서 쓰면 됨.

Spring JDBC 현업에서 거의 안 씀. 대신 JPA, MyBatis(MyBatis의 이전 버전은 IBatis)를 씀.
일본에서는 Spring JDBC를 많이 씀.

Spring Framework에만 집중하지 말고 Framework란 무엇인가....? -> 회사에서 어떤 Framework를 쓰든 적응할 수 있어야 함.

 

 

---

Spring Architecture 

출처 : docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/overview.html

 

- Core Container

Framework에서 가장 핵심이 되는 게 Core Container. 
이게 바로 DI. 이거 없으면 안 돌아감. 
DI = Dependency Injection(의존성 주입). Hasing을 DI라고 함.
어떠한 객체의 외부에서 다른 객체를 만들어 따로 주입하여 외부 객체에 의존하도록 만드는 방식.

ex) 필요한 객체가 의존함. Account가 Customer에 꽂히는데 Customer가 Account를 필요로 하므로 Customer가 Account에 의존함. ( 관련 포스팅 : https://hayden-archive.tistory.com/68 )

DI 돌리려면 Beans, Core, Context, Expression Language 이런 라이브러리들이 있어야 함.

 

- AOP(Aspect-oriented programming)

DI Framework가 구축된 상태에서 AOP Framework가 됨. AOP는 Back에서 씀. 
AOP를 쓰는 회사도 있고, 안 쓰는 회사도 있음.

 

- Data Access/Integration

Core Container, AOP까지 되면 DB쪽이 가능.(이 중에서 JDBC에서 제공하는 Spring Framework 대신 MyBatis를 쓰겠음)

 

- Web

마지막으로 Web 쪽에서 제공되는 라이브러리를 쓸 것임.(Portlet, Struts는 이전에 쓰던 방식이라서 요즘 잘 안 씀)

 

하다 보면 Maven 구조를 만나게 될텐데 이 구조가 되게 중요함.

 

 

---

Spring Framework Arichtecture

Factory Method Fattern 관련 포스팅 ( https://hayden-archive.tistory.com/215 )

출처 : www.egovframe.go.kr/wiki/doku.php?id=egovframework:rte:ptl:spring_mvc_architecture

 

 

출처 : www.java4coding.com/contents/spring/spring-mvc-architecture

Dependency => A를 만들어서 B에 넘김. 이 때, A가 B보다 먼저 만들어져 있어야 함. 개발 순서도 앞에꺼를 먼저 만들고 가야 함. (ex: DAO 객체를 Service에 넘겨야 하니까 DAO를 먼저 만들어야 함.) -> 이게 바로 DI. 개발자 입장.
서비스 요청의 흐름은 개발자와 상관 없음. 이건 클라이언트 관점.
포트폴리오에서 이 두 방향을 명확히 명시하는 것이 중요함. 프로젝트에 있어 전체적인 생각 필요.

개발자 입장에서 제일 중요한 게 사실은 DAO. Component가 하는 일은 DAO 호출.
DAO 잘 짜야 함. 그러려면 DB 모델링을 잘 짜야 함.
DAO가 수정이 많이 되는데, DAO 수정하면 Service 수정해야 하고 Controller 수정해야 하고...
프로젝트 규모가 작을 때는 괜찮은데, Enterprise급으로 가게 되면 모든 이들의 발목을 잡게 될 수 있음.

DAO가 아무리 변화가 많이 되어도 Service에 영향을 미치지 않으려면, 관계를 끊어야 함. Coupling한다.
1) Tight한 Coupling => 생성자로 주입. 
2) Loose한 Coupling => Setter로 주입.
DAO의 독립성을 보장해야 함. DAO가 수정되더라도 Service에 영향을 미치지 않도록 해야 한다 -> 그래서 DI Framework가 나옴.(여기서 Spring Framework가 출발함)

 

 

---

재사용성을 높이기 위한 방법 : IOC

 Step 1. Hasing 

바로 객체 생성해서 쓰면 재사용성 떨어짐.

 

 

 Step 2. 인터페이스 구현 

인터페이스(Hello)를 만들고, 인터페이스를 구현한 클래스(HelloImpl)를 만들고 인터페이스를 구현함.
인터페이스 타입으로, 인터페이스에 기반한 컴포넌트 객체를 만들고, 메소드를 호출함.

그런데 Step 2는 Step 1보다는 재사용성이 높지만 그래도 여전히 재사용성이 낮다.

 

 

코드 재사용성을 높이는 방법 1) 인터페이스를 쓴다. 2) 코드에 실체 클래스명이 언급되면 안 됨.(구상 객체 이름이 언급x) - new 뒤에 구상 객체명을 쓰지 않으려면, 객체 생성을 내가 하지 않고, Container에게 맡겨야 함.

 

* 용어 정리

POJO(Plain Old Java Object) plain 어떤 첨가물도 없다.(ex:플레인 요거트) 그 어느 것으로부터 제약받지 않음. implements, extends 없이 setter, getter로만 깔끔하게 있는 클래스.  "그냥 POJO로 해라" == "상속받거나 인터페이스 구현하지 말고 기본적인 클래스로 만들어라."

IOC(Inversion Of Control) 제어의 역전.  객체 생성의 권한이 개발자에게 있었는데, Container에게 넘어감.  객체 생성은 개발자가 못하고, 주문서를 넣고 컨테이너가 만들어주면 받아옴.

 

 

 Step 3. IOC( Inversion Of Control ) - DI Container 

 

 

---

대략적인 프레임워크

원리를 이해하는 것이 중요하다. 나중에는 가져다 쓸 건데 그게 바로 Maven

앞으로 DB와 연결할 때 JDBC 대신 MyBatis 사용할 것.