Spring 이해하기

김태성·2024년 7월 15일

개인 프로젝트-1

목록 보기
10/53
post-thumbnail

중요!

이 문서의 설명은 틀린부분이 많을 수 있습니다.
만약 글을 보실때는 각별히 주의해주시기 바랍니다.

서론

이전 글에서 Java가 어떻게 실행되는지, 특징이 무엇인지, 메모리, OOP 등등 여러가지 관점에서 Java를 알아보았다.

언어를 알아봤으니, 이제 프레임 워크를 알아볼 차례이다.
IoC/DI , AOP , PSA , POJO를 포함한 스프링 개념을 알아볼 것이다.

이후는 코딩에 필요한 지식들, testcode라던지(TDD), 애자일이라던지, GIT 사용방법이라던지.. 여러가지를 하고 난 이후 코딩에 들어갈 것 같다.
아무리 늦게 잡아도 이번주 안에는 코딩에 들어가는걸 목표로 삼고 있다.






그리고.. 큰일이 났다.
spring, tomcat, intellij plugin 등의 실행 과정을 검색하는데 정보가 하나도 없다.
블로그에 정리된 글이 있긴한데 stackoverflow, geeksforgeeks, spring 공식페이지 등
공신력 있는 사이트에서 정보를 얻으려고 해도 얻을 수가 없다.
그리고 찾으면 찾을수록 spring에 관련된 정보들이 끝도없이 나오는 것이었다.

진짜 문제는 데이터의 물량에 정신을 못차리고 2일이나 지났다는 거다.
일단은 개념을 찾아보며 생각해 보자....

  1. Spring 의 특징
  2. Spring 아키텍처
  3. Spring과 SpringBoot의 차이점
  4. Servlet , jsp model 1/2 , MVC
  5. TomCat(Was)
  6. Web on Servlet Stack vs Web on Reactive Stack
  7. Spring Web MVC
  8. Spring WebFlux
  9. Xml
  10. Bean lifecycle
  11. Spring 삼각형 (DI/IoC , AOP , PSA , POJO)
  12. JPA , ORM

과연 내가 이번주 주말부터 코딩을 할 수 있을지 진심으로 의문이 들기 시작했다.
이거 말고도 RESTful API와 디자인 패턴에 대해서도 알아봐야하는데...

Spring 특징

레퍼런스 : https://www.geeksforgeeks.org/introduction-to-spring-framework/

(project에서 참조하는 외부 라이브러리들 spring boot 3.3.1버전을 사용해서 spring 6.1.10 버전을 사용한다.)

Spring은 여러 하위 프레임워크들의 모음으로 생각할 수 있다. 따라서 여러 모듈들을 선택해서 사용할 수 있는데, 이를 잘 이해하면 Spring이 어떤것인지 파악할 수 있을 것이다.

1. IoC 컨테이너

런타임 중 클래스 객체 참조를 암묵적으로 제공하기 위해 DI/IoC 패턴을 사용하는 핵심 컨테이너이다. IoC 컨테이너에는 App 객체의 구성 관리를 처리하는 어셈블리어 코드가 들어있다.

  • org.springframework.beans
  • org.springframework.context 두 패키지를 제공한다.

2. 데이터 액세스 프레임워크

JDBC , Hibernate와 같은 지속성(persistance) API를 사용해 지속성 데이터를 데이터베이스에 저장하도록 해준다.

이는 예외처리, 데이터베이스 연결/상호작용, 트랜잭션 관리 등등 다양한 도움을 준다.
또한 개발자가 App 전체에 지속성 데이터에 액세스하는 코드를 쉽게 작성할 수 있게 해준다.

여기서 Persistance Data란 무엇인가에 대해 설명을 덧붙이자면
보통 객체는 파괴되었을때 속성이 모두 사라진다.(garbage collector에 의해 삭제)
하지만 이 데이터를 어딘가에 저장해 놓으면 객체를 다시 생성했을때 파괴되기 전의 상태로 돌아갈 수 있는데, 이를 persistance 라고 한다.

즉, 데이터가 처음부터 persistance 한것이 아니라, 저장을 함으로써 persistance 하게 변하는 것이다.

3. MVC 프레임워크

MVC 아키텍처 기반으로 웹앱을 빌드할 수 있다.
사용자가 만든 요청은 컨트롤러를 거쳐 다른 뷰, 즉 다른 JSP 페이지나 서블릿으로 전송된다.

MVC 관련 내용은 뒤에 자세하게 설명할 예정.

4. 트랜잭션 관리

Java Transaction API를 제공한다.
JDBC , hibernate , JavaDataObjects(JDO) 등 여러 API에 사용할 수 있다.

5. Spring Web Service

Java 클래스에서 서비스 앤드포인트/Definition을 생성하지만, App에서 관리하기 힘들다. 이를 해결하기 위해 XML 파싱으로 레이어 기반 접근을 관리한다.

이를 이해하기 위해서는 SOAP에 대해서 알아야 한다.
SOAP는 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.
레퍼런스 = https://ko.wikipedia.org/wiki/SOAP

또한 Spring Web Service는 다음과 같다.
레퍼런스 = https://spring.io/projects/spring-ws

  • Spring Web Service는 contract-first SOAP 개발을 용이하게 한다.
  • XML 페이로드를 조작하는 방법 중 하나를 선택하여 유연한 웹 서비스를 만드는걸 도와준다.

그리고 contract - first 와 contract - last 두 방법이 있는데 레퍼런스를 참고하자.
레퍼런스 = https://www.baeldung.com/spring-boot-soap-web-service

  • contract - first는 WSDL을 생성한 후 Java Class를 생성하고
  • contract - last는 Java Class를 생성한 후 WSDL을 생성한다.

그리고 WSDL이란 웹 서비스 기술언어 또는 기술된 정의 파일의 총칭으로, XML로 기술된다.
레퍼런스 = https://ko.wikipedia.org/wiki/WSDL

마지막으로 정리하자면

  • 웹 서비스란 플랫폼 독립적인 기계간의 서비스이다.
  • 웹 서비스에서 통신하려면 메시지 프로토콜이 필요하다.
  • 이 프로토콜을 SOAP라고 하고, 메시지는 HTTP를 통한 XML 문서이다.
  • 그리고 XML 계약은 WSDL에 의해 정의되는데, 이것이 너무 복잡하다.
  • 그럼으로 Spring Web Service는 contract-first 방법을 발전시켜 XML 계약을 도와준다.
  • 즉, Spring Web Service는 웹 서비스의 프로토콜 생성을 도와주는 프레임워크라 할 수 있다.

파고들수록 정보가 너무 많이 나와서 여기까지 기술하겠다.

6. JDBC 추상화 계층

사용자가 오류를 쉽고 효율적으로 처리하는데 도움을 준다.
Spring의 데이터 액세스는 JDBC에만 국한된것이 아니라 DAO는 JDBC에 바인딩 되지 않는다.

DAO오는 밑에 기술된다.

7. Spring TestContext 프레임워크

Spring 애플리케이션에 대한 단위 및 통합 테스트 기능을 제공한다.
또한 특정 통합 테스트 기능도 제공한다.

Spring 아키텍처

레퍼런스 : https://www.geeksforgeeks.org/spring-framework-architecture/?ref=lbp

Spring Framework 모듈은 견고하고 확장/유지에 용이한 엔터프라이즈 App을 구축할 수 있는 강력한 도구를 제공한다. 모듈형 아키텍처를 선택함으로써 불필요한 오버헤드를 줄일 수 있음.

Core Container

IoC/ApplicationContext를 포함하여 Spring 프레임워크의 기본 기능 제공
1. Spring Core : IoC/DI를 포함한 Spring 프레임워크의 기본 기능 제공
2. Spring Bean : BeanFactory, BeanWrapper를 제공
3. Spring Context : ApplicationContext를 제공하며 국제화, 리소스로딩, 이벤트 게시 및 사용기능과 같은 추가기능을 제공
4. Spring Expression Language(SpEL) : 런타임 중 객체를 쿼리하고 조작하기 위한 강력한 표현 언어를 제공. 속성 액세스, 메서드 호출, 조건문, 루프 및 유형 변환을 포함한 광범위 기능 지원.

Data Access/Integration

데이터베이스 및 기타 데이터 소스와의 통합을 지원.
1. Spring JDBC : JDBC 작업에 필요한 보일러플레이트 코드의 양을 줄이는 간단한 JDBC 추상화 계층을 제공하며 트랜잭션 관리를 지원
2. Spring ORM : Hibernate 및 JPA와 같은 객체 관계 매핑(ORM) 프레임워크와의 통합을 제공. ORM 프레임워크 위에 상위 수준의 추상화 계층을 제공
3. Spring Data : CRUD 작업, 메서드 이름에서 쿼리 생성, 페이지 나누기 및 정렬 지원, Spring 트랜잭션 관리와 통합 등 광범위 기능 제공. 또한 리포지토리 및 DAO 와 ㄱ같은 일반적인 데이터 액세스 패턴에 대한 지원도 제공
4. Spring Transaction : 선언적 트랜잭션 관리를 지원. 또한 JTA 트랜잭션 관리나 간단한 JDBC 트랜잭션 관리자를 사용하는것과 같은 다양한 트랜잭션 관리 전략을 지원.

Web

웹앱 구축을 지원.
1. Spring MVC : 웹앱 구축을 위한 MVC 프레임워크 제공. 자세한건 밑에 기술
2. Spring WebFlux : 반응형 프로그래밍 모델 제공. 역시 자세한건 밑에 기술
3. Spring Web Service : SOAP 기반 및 RESTful 웹 서비스 구축을 지원.(위에서 이미 설명함)

기타

추가 기능이 많음.
1. Spring Security : App에 대한 인증/권한 부여 기능 제공. 또한 다양한 보안 구성을 제공하여 세분화된 보안 정책을 적용할 수 있게 도와줌.
2. Spring Integration : 메시지 기반 및 이벤트 기반 아키텍처를 구축하기 위한 지원을 제공.
3. Spring Batch : 배치 처리 및 엔터프라이즈 시스템과의 통합을 지원. 배치 작업 테스트/디버깅/로깅/모니터링, SpringData,SpringIntegration과 같은 다른 모듈과의 통합을 지원하는 등 App 빌드/관리를 위한 다양한 도구, 유틸을 제공
4. Spring Cloud : 클라우드 네이티브 App을 빌드하기 위한 지원을 제공.

Spring과 SpringBoot의 차이점

레퍼런스 : https://www.youtube.com/watch?v=YSsl5-q2BR4

짧게 정리하자면

  • Spring은 기존 방식의 불편한 점을 개선하고자 나온 프레임워크다.
  • 하지만 여러가지 설정이 매우 복잡했고, 이를 재대로 하지 못하면 버그가 계속 발생했다.
  • Spring Boot는 dependency 버전까지 자동으로 설정해준다.
  • configuration도 한줄이면 끝난다.
  • Tomcat, Jetty 등 내장 서블릿 컨테이너 덕분에 파일 배포가 매우 간단하다.

Spring Boot는 기존 Spring의 불편한 점을 개선하기 위해 나왔고,
그 내용은 불편했던 설정을 자동화 해 줌으로써 개발자들이 개발에 집중할 수 있는 환경을 제공하는것이 주요 목적이다.

Servlet , jsp , mvc 1/2 , 프론트 컨트롤러

레퍼런스 : https://www.youtube.com/watch?v=PH8-V6ah0XQ
레퍼런스 : https://en.wikipedia.org/wiki/JSP_model_2_architecture

  • 초기 웹 페이지는 정적 페이지만 제공을 하였다. 하지만 client의 요구사항마다 다르게 응답해야 하는 경우가 발생하였다. 그래서 WAS라는 동적 컨텐츠 생성 서버를 따로 만들었다.

  • 동적 컨텐츠를 만드는데 사용되는 자바 기반의 웹 어플리케이션 프로그래밍 기술 혹은 그 기술에서 사용되는 객체를 Servlet이라고 한다.(모든 WAS가 servlet을 지원하는건 아니다.)

  • 하지만 Servlet은 가독성이 심각하게 나빠서 추가적인 것이 필요했다.

  • 그래서 Html 코드 내부에 자바 코드를 넣을 수 있는 JSP를 만들었다.(깡servlet보다 쉽다는거지 지금 보면 현기증난다.)

  • 이때 JSP model1 패턴이 나오기 시작했다. 하지만 비즈니스 로직과 HTML 코드가 분리되지 않아 여전 불편했다.

  • 그래서 비즈니스 로직과 HTML 코드를 분리하는 JSP model2 패턴이 개발되었다. JSP model2는 MVC2라고도 불리지만, JSP model2를 구현하기 위해 MVC 패턴이 필요하지 않는다. - wiki

  • 이후 Model - View - Controller(MVC)를 활용하는 Spring Framework가 개발되었다.

  • Spring은 중복 요청에 대한 오버헤드를 줄이고자 공통 로직을 처리하는 Front Controller로 Dispatcher Servlet이 담당한다.

그렇다면 jsp는 구식 로직이라서 몰라도 되나?

레퍼런스 : https://github.com/jreijn/spring-comparing-template-engines

어느 개발자가 Template Engine 별로 속도를 실험했다.
그중 JSP가 가장 빠르다고 나와있다.
또한 많은 레거시 코드와 전자정부 프레임워크에서도 JSP는 상당히 많이 쓰이며,
알아놔서 나쁠건 없으니 기회가 된다면 공부해 보자.

WAS , Servlet Container

레퍼런스 : https://ko.wikipedia.org/wiki/웹_애플리케이션_서버
이거 찾는데 하루 걸렸다. Spring dispatcher servlet과 Tomcat의 연결점이다.

WAS는 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다.

기본 기능은 다음과 같다.

  • 프로그램 실행 환경과 데이터베이스 접속 기능을 제공
  • 여러 개의 트랜잭션을 관리
  • 업무를 처리하는 비즈니스 로직을 수행

구성요소는 다음과 같다.

  • 일반 웹 모듈은 Java servlet or JSP
  • 비즈니스 모듈은 EJB로 구성

대표 애플리케이션 서버 : Apache TomCat
주의! Jetty는 Web Server이다!
레퍼런스:https://en.wikipedia.org/wiki/Jetty_(web_server)

그리고 Servlet Container이란 웹 서버의 컴포넌트 중 하나로, Servlet의 생명주기 관리, URL과 특정 서블릿 맵핑 등의 일을 하게 된다.
레퍼런스 : https://en.wikipedia.org/wiki/Web_container

그러니 나를 괴롭히던 TomCat 이놈이 도대체 뭐냐? 라는 것에 대한 대답은

  • TomCat은 WAS라는 동적 컨텐츠 생성 서버인 WAS이다.
  • TomCat은 Servlet을 관리하는 Servlet Container를 포함한다.
  • 그리고 Jetty 또한 Servlet Container를 포함한다.

다시 한번 정리를 해 보자면

App 서버 - TomCat
Web 서버 - Jetty

레퍼런스1 : https://taes-k.github.io/2020/02/16/servlet-container-spring-container/

레퍼런스2 : https://medium.com/@nikhilmanikonda/tomcat-who-i-am-and-what-i-do-e91ff72fb2ea

레퍼런스3 : https://tomcat.apache.org/tomcat-9.0-doc/config/context.html

위는 TomCat의 아키택쳐이다.
외부에서 들어오는 요청을 필터로 걸러 내부에 들어오게 되면 Servlet을 관리하여 요청을 처리하는 시스템이다.
이때, Context에 Servlet이 있는것이 보일 것이다.
저 Servlet을 Dispatcher Servlet으로 Front Controller로 사용하고,
Spring에서 Handling/View Resolver를 통한 로직 처리를 한다고 보면 된다.
이후 처리된 결과를 바탕으로 JSP를 통해 View를 보여준다.

그래서 결국에는 처음에 봤던것과 연결이 된다.
우리는 정적인 웹 페이지를 처리하던 시대에서 동적인 웹 페이지 처리가 필요했고,
그 동적인 웹 페이지를 만들기 위해 Servlet -> JSP -> MVC Framework의 발전이 있었다.
이때 TomCat은 하나의 App 서버로서 정적인 페이지 처리와 Servlet Container를 제공함으로써 동적 처리를 위한 환경을 만들어 주었고,

Spring은 이 Servlet에서 오는 요청을 바탕으로 서비스를 처리, 결과값을 반환한다.

즉, Servlet 이해가 Spring의 이해를 하는데 가장 큰 개념이 된다는 것이다.

Web on Servlet Stack vs Web on Reactive Stack

레퍼런스 : https://docs.spring.io/spring-framework/reference/web/webflux/new-framework.html

여기서는 간단하게 차이점만 짚고 넘어가겠다.

1. Servlet Stack

  • 명령형 프로그래밍
  • Spring MVC는 동기 / 블로킹 I/O
  • 스레드 모델당 요청 하나
  • Servlet API
  • Spring Security
  • Spring Data Repositories(JDBC , JPA , NoSQL)

2. Reactive Stack

  • 함수형 , 반응형 프로그래밍
  • Spring WebFlux는 논블로킹 / 멀티코어
  • Netty 사용(MVC , WebFlux 모두 TomCat , Jetty, Undertow 사용)
  • Reactive Streams Adapters
  • Spring Security Reactive
  • Spring Data Reactive Repositories(Mongo, Cassandra, Redis ...)

명령형 프로그래밍과 반응형 프로그래밍에 대해서 알게 된다면 이해하기 편해진다.

  • 명령형 프로그래밍은 말 그대로 명령을 내려 순차적으로 실행해 나가는 프로그래밍이다.
  • 반응형 프로그래밍은 데이터 스트림을 받을때 데이터의 변화에 반응하는 프로그래밍이다.

따라서, 특정한 요청에 대한 결과값을 뱉는 프로그램이라면 명령형이,
특정한 데이터의 변화를 처리하는 프로그램이면 반응형 프로그래밍이 맞는 것이다.
순차적으로 처리하는 명령형과 달리, 이벤트 기반 반응을 하기 위해서 비동기가 필요하다는 것이다.

즉, 이벤트가 여러개 발생했을때, 병렬적으로 처리하기 위한 스택이 필요했다는 소리다.
WebClient라고 비동기 처리를 보내는게 MVC에 있긴한데, WebFlux를 의존해야 한다.

Spring MVC

레퍼런스1 : https://www.geeksforgeeks.org/spring-mvc-framework/
레퍼런스2 : https://en.wikipedia.org/wiki/Jakarta_Servlet

흐름

  • 모든 요청이 FrontController 역할을 하는 Dispatcher Servlet에 의해 가로채진다.
  • DispatcherServlet은 XML 파일에서 핸들러 매핑 목록을 가져와 컨트롤러에 요청을 보낸다.
  • Model and View의 객체는 컨트롤러에 의해 반환된다.
  • DispatcherServlet은 XML 파일에서 View Resolver의 항목을 확인하고 적절한 View 구성요소를 호출한다.

즉, 요청을 받아 적절한 컨트롤러에 요청하고, 반환되는 View를 보여주도록 명령하는 것이다.
위에서 봤다시피 Servlet은 동적 웹페이지를 생성하는 서버측 프로그램/사양일 뿐이다.

Spring WebFlux

레퍼런스 : https://reflectoring.io/getting-started-with-spring-webflux/

간단하게 요약하면

  • 시스템에서 Stream이 들어올때 변경되는 데이터에 반응해 멀티스레드 환경에서 처리하는 방법이다.

예를 들자면

  • Function이 1~1000까지 있다고 가정
  • 이때, 랜덤한 function , 랜덤한 시간에 function 변수의 변화가 있음
  • MVC의 경우 하나의 변수 처리를 할때 다른 함수를 처리하지 못한다.
  • 하지만 비동기/Non-Blocking일때는 원래의 흐름은 처리를 하면서 이벤트 루프를 통해 변수 처리를 병렬적으로 가능

오해하면 안되는 것이

  • WebFlux는 가볍지 않다
  • 멀티스레드 환경을 통해 처리 리소스를 최대한 활용할수 있는것에 초점을 둔다
  • 병렬 처리에 집중하는 만큼 동시작업이 많이 필요한 App에 적합하다.
  • MVC와 함께 사용할 수 있다. MVC를 쓸때 WebFlux를 못쓰는게 아니다.
  • 가볍고 작은 미니 프로젝트에서는 안쓰는것이 좋을 수 있다. 기껏해야 하루 10명남짓하는 사이트에 WebFlux를 돌리는건 굳이?

XML

레퍼런스1 : https://aws.amazon.com/ko/what-is/xml/
레퍼런스2 : https://www.geeksforgeeks.org/xml-based-injection-in-spring/
위에서 한번 다뤘던 주제이다.
SOAP의 설명에서

  • SOAP는 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.

라는 대목이 있다.
그리고 SOPA 이외에도 여러가지 계약이나 여러가지에 쓰인다.
AWS에 따르면, XML은 공유 가능한 방식으로 데이터를 정의하고 저장할 수 있습니다. 라고 나온다.
좀 더 정확하게 설명하자면 XML은 데이터를 정의하는 규칙을 제공하는 마크업 언어이다.

즉, 어떠한 정의된 규칙을 사용하여 데이터를 전송하기 편하다는 것이다.
실제로 XML을 보면 < [정의된 언어] > 형태를 취하고 있다.

이를 왜 찾아보게 되었냐면, Spring에서도 여러 XML 파일이 있다.
Spring은 이러한 .xml 파일들을 통해서 Spring Bean을 정의하고, 종속성을 주입할 수 있다.

우리의 프로그래머들은 이러한 주입 방식이 마음에 들지 않았고, 다른 방식으로 사용하도록 발전시켰다.
그래서 SpringBoot에서 @Configuration , @Bean 등으로 주입할 수 있게 되었다.

물론 .xml 파일을 못쓰는건 아니고 피한다.

Spring 삼각형

레퍼런스 : https://ko.wikipedia.org/wiki/Plain_Old_Java_Object
레퍼런스 : https://springframework.net/doc-latest/reference/html/psa-intro.html

Spring에서 객체들이 어떻게 관리되는지를 알려면 Spring 삼각형에 대해서 알아야 한다.
하지만 이를 이해하는것이 상당히 까다로운데, 그 이유는 POJO라는 개념을 포함하는 개념을 포함하는 개념이 나오기 때문이다. 이해가 잘 안되더라도 일단 한번 알아보면서 생각해 보자.

위에 나오는 각각의 요소를 정리해 보자면 다음과 같다.

POJO

  • 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용된다. - wiki

POJO가 중요한 이유는 Spring은 객체지향형 프레임워크이고, 이 객체들에 의존성을 주입하여 추상화를 짜기 때문이다. 이 POJO를 가지고 Beans를 만들어 객체를 관리하게 된다.

IoC/DI
DI는 의존성 주입이니 넘어가도록 하겠다.

  • inversion of control (IoC) is a design principle in which custom-written portions of a computer program receive the flow of control from external source - wiki

위를 해석해 보자면 '사용자 정의 코드 부분이 외부 소스로부터 제어 흐름을 받는 설계 원칙' 이라는건데 얼핏보면 이해가 되지 않는다.

public class Tesla{
	~~
	private Car Tire;
	private Car Motor;
    private Owner ElonMusk;
    ~~
}

위의 객체를 보면 private에서 객체를 만드는 것이 아니라 어딘가에서 객체를 받아오는것을 볼 수 있다. 이때 이 객체들은 상위 객체에서 가져오는 것이다.

이처럼 객체를 직접 만드는 것이 아니라 어딘가에 있는 객체를 가져오는 것이 IoC의 핵심 개념이다.

AOP
관계 중심적 프로그래밍 이라는 말이다.(Aspect oriented programming)
AOP는 횡단 관심사(cross-cutting concern)의 분리를 허용함으로써 모듈성을 증가시키는 것이 목적인 프로그래밍 패러다임이다. - wiki

간단하게, 정말 간단하게 설명하면

  • 로그인 할때 Token 확인을 하는 객체를 생각해보자.
  • 이 Token을 확인하는 객체는 여러 상황에서 쓸 수 있다.
  • 예를 들면 글을 쓸때, 로그인 할때, 서버에 정보 갱신을 요청할때 등등이다.

위와 같은 상황일때, Token을 확인하는 로직은 하나의 '모듈'로써 쓰인다는 말이다.
즉, Token을 검사할때 쓰이는 객체가 된 것이다.

이처럼 객체의 관계를 중심으로 프로그래밍하는 방법이다.

PSA

  • 기존 코드 중심 접근 방식과 비교하여 객체를 배포하는 방법에 대한 기술적 세부 사항을 개발 프로세스에서 훨씬 나중에 결정할 수 있다.

즉, 어떠한 일을 하겠다는 '추상화'를 잘 만들면 나중에 코드를 고칠때 수월해진다는 것이다.

예를 들어보면

  • 특정 일을 하겠다는 추상화를 만듬
  • 그 일만 하는 객체들을 잘 만들어 놓음
  • 로직의 변경이 있어도 추상화대로 만들었기 때문에 전체 코드에 문제가 별로 발생하지 않음.
  • 예로 들면 Token 확인하는 코드가 일을 잘한다 가정
  • 이 코드는 Token을 확인한다는 일을 정확하게 하고 있음.
  • 따라서 Token을 확인하는 방법이 약간 변경되더라도 전체 프로그램에 큰 영향이 없다.

즉, 추상화 처음에 잘짜라는 말이다.

Bean lifecycle

레퍼런스 : https://www.geeksforgeeks.org/bean-life-cycle-in-java-spring/

위에서도 나왔다시피 Bean은 IoC Container와 밀접한 관련이 있다.
위에서 보이는 과정은 다음과 같다.

  • IoC 컨테이너 시작
  • Bean의 인스턴스 실행
  • DI
  • 커스텀 init()
  • 커스텀 메서드
  • 커스텀 destroy()

즉, IoC 컨테이너에서 Bean Factory를 통해 Bean이 만들어지고,
종속성을 주입한 후 자기 할일을 하는것일 뿐이다.

JPA , ORM

레퍼런스 : https://www.geeksforgeeks.org/spring-boot-spring-data-jpa/

ORM

  • 모든 Java 객체를 데이터베이스 테이블에 직접 유지하는 프로세스

JPA

  • Hibernate는 ORM의 한 예.
  • JPA는 인터페이스이고 Hibernate는 구현.

자세한 사용 방식은 지금 적지 않음.

끝으로

레퍼런스 찾는게 정말 힘든거 같다.
블로그 글은 많다. 진짜 많긴 하다. 하지만 디테일이 상당히 떨어지는 글도 많았고
내가 알고싶은 글도 별로 없었으며 무엇보다 공신력이 없는 글이 많았다.
블로그 글을 쓰시는분들이 틀린 정보를 적는다는 의미는 아니고, 잘못 적었을때 피드백을 받기 상대적으로 어려우니
정보의 객관성이 떨어진다는 말이다.

또한 MVC / WebFlux 및 Spring 기본정보/WAS / Web APP Service 등등
프레임워크의 구조가 어떤지 알아보는 과정에서 진짜 정신이 나가는줄 알았다.
내가 원하는 정보는 없고, TomCat과 Servlet Container의 관계에 대한 직접적인 정보도 없어서
다 찾아보고 아 이게 AppServer구나 하고 역검색을 해서 TomCat을 찾는 경우도 있었다.

그냥 돈 몇만원 주고 책을 사버릴까 싶기도 했지만
거기에 내가 원하는 정보가 있는지도 불확실하고, 정확한 정보를 주는 사이트를 찾는것도 힘들었다.

물론 내가 레퍼런스로 넣은 링크들이 100퍼센트 맞는 정보만 전달한다고는 생각하지 않는다.
예를 들어서 servlet -> mvc 패턴 설명할때, Jsp Model2는 관습상으로 MVC2라고 불리긴 하지만
기존에 있던 MVC 패턴과는 엄연하게 다른 구조이다.
geeksforgeeks 또한 깊게 들어갔을때 잘못된 정보가 있을수 있다.

하지만 이러한 오점을 방지하기 위해 위키와 여러 레퍼런스들을 교차검증 했다는걸 알아줬으면 한다.
(그래도 100프로 맞다고 확신할수 없는게 너무슬프다)

그래서 더 힘들었던거 같다.
어떻게든 위키 뒤지고 여러 레퍼런스 뒤지면서 이게 진짜 맞는가 아닌가 검증하는데 시간을 다 보낸거 같다.

이후 더 알아보고 싶은것

  • BeanFactory vs Application Context
  • SpEL
profile
김태성
닭이 되고싶은 병아리
이전 포스트

Java 이해하기

다음 포스트

중간 점검

0개의 댓글