스프링의 개괄적인 개요

1. 정적 컨텐츠 vs MVC와 템플릿 엔진 vs API

 이 세가지는 브라우저에 정보를 나타내는 것이라고 생각하면 될거 같다. 

 먼저 정적(static) 컨텐츠의 경우  아래 그림처럼 컨트롤러에 등록되지 않은 파일(resource/static) 을 말한다. 정보를 주고받기에 제한된 파일이기에 그 페이지 안에서의 동적 움직임이 아닌 다른 페이지와 동적으로 움직여야 한다면 쓸모가 없다.

 이제 MVC의 경우 Model, View, Controller 의 약자인데 static에서 말한 것 처럼 controller에 등록된 파일들을 말한다. 이때 Model 타입의 변수를 통해 정보를 받아올 수 있는데 이 정보들은 웹페이지 상에 파라미터(웹 주소 상에서 ? 이후 부분에 해당)로 등록되어 넘어온다. 이 함수의 리턴 값이 String이고 여기에 resource/template 하위의 html문서 명을 넣어주면 그 html 파일을 브라우저에 보여준다. 이 파일을 view 라고 해서 이 세가지 줄임말인 MVC라는 개념이 있다.

 마지막으로 API의 경우 MVC의 Controller와 비슷하나 @ResponseBody 어노태이션을 함수 위에 입력해야 하고 Model개념이 없다. Viewer가 없기에 String이라던지 객체, html코드자체를 리턴 할 수 있다. 그리고 @ResponseBody 어노테이션은 HTTP의 패킷의 body 부분을 가르킨다.

 

 2. 스프링 빈, 의존 개념

 빈이란? Spring IoC 컨테이너가 관리하는 자바 객체인데 자세하게는 모르겠지만 스프링이 관리하는데 이때 관리의 의미가 A 객체를 만드는데 B가 필요하다면 이를 기존에는 그 클래스 파일을 import하고 new를 쓰지 않아도 B를 가져다 쓸 수 있다는 것 같다. 사실 IoC를 정확하게 안배웠는데 제어의 역전이라고 알고 있다. 이게 무엇인지 개괄적으로 알고있는데 아마 다음에 자세히 다뤄야지! 앗, 그리고 방금 A와 B처럼 A가 B에 의존한다고 생각하면 된다.

 

3. 그렇다면, 스프링 빈을 등록하는 방법은~?

 첫째로 컴포넌트 스캔 개념이 있다. 사실 @Component 어노테이션을 클래스 위에 명시해 주면 스프링 빈으로 자동으로 등록된다. 위에서 @Controller를 통해 MVC나 API를 사용할 수 있었던 것도 스프링 빈으로 등록된 덕분이었다. 근데 여기서 스프링은 한 발 더 앞서가서 @Controller @Service @Repository 라는 어노태이션에 @Component 어노테이션을 포함해 주는데 이러한 이유는 대게의 백엔드가 Repository를 통해 DB에 접근하고 Service에 이 데이터에 대한 비즈니스 로직을 실행해주고 이 값을 Controller를 통해 브라우저에 띄우는 과정으로 백엔드가 구성되어 있다. 이때 각 부분에서 위에서 말한 의존관계가 자연스럽게 나타나게 되고 그래서 위 세가지 어노테이션에 @Component를 포함하지 않았나~ 싶다. 추가적으로 의존관계가 필요한 함수들에는 (대게 생성자 함수) @Autowired 라는 어노테이션이 필요하다~!

 두번째로 자바 코드를 통해 직접 스프링 빈을 등록 하는 방법이 있다. java하위에 Config 클래스를 만드는데 이름 답게 @Configuration이라는 어노테이션을 클래스 위에 명시해준다. 이제 이 클래스에는 대게 생성자 함수들을 만들어 주고 각 함수들 위에 @Bean 어노테이션을 명시해주면 완벽! 여기서 정말정말 신기한게 있다! 무엇이냐하면 인터페이스 I의 생성자 함수를 호출한다. 이때 당연히 리턴값이 객체이어야 하므로 I를 상속받음 A라는 클래스 생성자 함수를 통해 백엔드가 돌아가는 와중에 조금 더 좋은 DB관리방식을 따르는 B라는 클래스가 있다고 하자. 당연히 B도 I를 상속받는다. 이때 B를 사용해서 DB를 관리하고 싶다면 이 Config 클래스의 A를 리턴하는 생성자 함수의 리턴 값을 B로 바꾸기만 하면 끝난다. 말이 조금 복잡하지만 단순하게는 같은 인터페이스를 가지는 두 클래스가 있다면 원하는 클래스로 바꾸는 과정이 정말 단순하다는 것이다!

 추가로 말하자면 이 것이 스프링의 SOLID 개념 중 OCP 개념을 위반한 것인데 이를 지키기 위해 IoC와 DI 개념이 있는 것이다.

 

4. DB 접근 법

 이는 대게 코드와 같이 보아야 하므로 DB접근 역사를 이야기 하자면 

                               Jdbc -> 스프링 JdbcTemplate -> JPA -> 스프링 데이터 JPA

순으로 발전했다고 생각하면 좋다. 단순하게 보면 Jdbc는 정말 하나하나 직접 구현해야만 하고 스프링 JdbcTemplate은 Jdbc의 반복 코드 대부분을 제거해준다. 하지만 SQL은 직접 작성 해야만 한다. 그렇다면 JPA는?!?! 눈치를 챘다면! 기본적인 SQL을 JPA가 만들어 준다. 그렇다면 끝판왕인 스프링 데이터 JPA는 정말 신기하게도 많은 개발자들이 대게 사용하는 함수들의 메서드들을 코드로서 이미 제공해주어 그냥 그 함수를 쓰기만 하면 된다. 하지만 주의해야 할 것은 스프링 데이터 JPA는 대게 사용하는 함수들이 있으므로 내가 만들고 싶은 DB접근하는 함수들은 직접 만들어야 한다. 따라서 너무 의존하면 안돼~!

 추가적으로 실무에서는 JPA와 스프링 데이터 JPA를 사용하고 복잡한 동적 쿼리는 Querydsl 이라 부르는 라이브러리 하지만 이 조합도 충분하지 않다면 JPA가 제공하는 네이티브 쿼리라는 것을 이용하거나 스프링 JdbcTemplate을 사용해야만 한다. 휴,,, 배울게 많구나! 아싸뿅!

 

5. AOP

 마지막으로 AOP에 대해 다루자면 깊게는 다루지 않았기에 간단하게만 이야기 하자면 많은 함수들에 대해 같은 동작들을 실행하게 하고 싶다면 AOP를 이용하면 된다. 여기서 흥미로운 것은 위에서 말한 의존관계에 있는 자바 빈들의 경우 프록시라는 각각의 자바 빈들의 복제품이 나타나서 위에 말한 같은 동작들에 대해 실행 하고 실제 자바 빈을 건드린다. 아래 그림과 같은 개념이다!

 

느낀점...

전체적인 개념 부분만 보았는데도 정말 배울게 많다고 느꼈다. 그리고 블로그에 정리하니깐 확실히 머리속에 자리가 꽉 잡힌거 같아서 좋네 ㅎㅎ. 아무튼 어려운 백엔드 세계이지만 그래도 열심히 꾸준히 해봐야지! 이젠 여기서 코드적인 부분도 익숙하게 하는 것이 다음 목표닷!