📚 참고자료

  • 유튜브 채널 [우아한 Tect] - 10분 테코톡 피카의 TDD와 단위 테스트

https://www.youtube.com/watch?v=3LMmPXoGI9Q 

 


 

🤔 TDD란?

 

프로그램을 작성하기 전에 테스트를 먼저 하라!

- 켄트 백 Kent Beck -

 

  • TDD (Test-Driven Development)
  • 테스트 코드를 먼저 만들고, 실제 프로덕션 코드를 나중에 만드는 개발 방법을 말합니다.

 

 

 

기존 프로세스

 

 

TDD 방식 프로세스

 

 

 

🤔 TDD를 사용하는 이유는?

  • 변화에 대한 두려움을 줄여준다. (리팩터링이 편하다)
  • 디버깅 시간을 줄여준다.
  • 동작하는 문서 역할을 한다.

 

 

 

😀 TDD의 장점

  • TDD를 하면 자연스레 테스트 커버리지가 높아진다.
  • 오버 엔지니어링을 방지할 수 있다.
    • TDD를 하면서 요구사항에 맞춰 개발 코드를 구현
    • 미래에 필요할 것 같은 구현을 지레짐작하여 불필요한 코드를 작성하는 소요가 줄어든다.
  • 설계에 대한 피드백이 빠르다.
    • 설계를 처음부터 잘한다면 좋겠지만 잘못 설계했다면, 변경이 일어나거나 사용하기 어려울 때 깨달을 수 있다.
      반면에 TDD는 설계에 대한 피드백을 빠르게 해 줄 수 있다.
    • 설계가 복잡해지면 테스트 코드를 작성하기 점점 더 어려워진다.

 

 

😅 TDD의 오해

  • TDD는 실제 방법론이다?
    • TDD는 높은 응집을 유도하지 않는다.
    • TDD는 단일 책임 원칙과 인터페이스 분리 원칙 위배에 어떤 신호도 주지 않는다.
    • TDD는 인터페이스 일관성을 도출하지 않는다.
    • TDD의 리팩터링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다.

 

 

 

😥 TDD를 실패하는 이유

  • 코드가 이루고자 하는 가치나 기능을 테스트하기보다 그 기능을 어떻게 구현하고 있는지를 테스트한다.
  • 결국 테스트 케이스들이 구현체와 결합도가 높아진다.
  • 구현체들을 리팩터링 하면 결합되어있는 테스트 케이스들이 모두 깨져버린다.

 

 

 

 

📏 테스트의 범위

 

  • 통합 테스트: 여러 작업 단위가 연계된 워크플로우를 테스트하기
    위한 수단(객체 간, 시스템 간)
  • 기능 테스트: 공개된 API의 가장 바깥쪽에 해당하는 코드 검사
    (Controller 호출, Security, http)
  • 부하 테스트: 주어진 단위 시간 동안 애플리케이션이 얼마나 많은
    요청을 처리할 수 있는지 검사
  • 인수 테스트: 고객 또는 대리인이 정의된 모든 목적에 부합되는지
    확인해보고자 하는 검사

 

 

 

 

 

👍 좋은 단위 테스트

 

F.I.R.S.T 법칙

F - Fast(빠르게)

I - Independent(독립적으로)

R - Repeatable(반복 가능하게)

S - Self-Validating(자가 검증하는)

T - Timely(적시에)

 

 

 


느낀점

  • 설계를 테스트로 검증 한다는 점이 설계에 대한 신뢰성을 더욱 올려줄 것 같습니다.
  • TDD의 장점과 정의는 많지만 어떻게 해야 하는지 아직 감이 안잡히고 있습니다.
    • 이건 TDD 수업을 해주는 교육기관에서 수업을 받아야 할 것 같습니다.
  • TDD는 아니더라도 테스트 코드를 성실하게 작성할 예정입니다.
    • 서비스단 메서드 하나에 하나의 테스트를 작성할 수 있도록 진행

 

 

 

반응형

 

 

📚 참고자료

  • 블로그 [망나니개발자] - [Spring] 설정 자동화와 설정의 변경, @EnableWebMvc와 WebMvcConfigurer => 링크
  • 블로그 [끝이 없는 배움의 끝] - Spring Boot로 CORS 해결하기 => 링크
  • 블로그 [개발하는 펭군이] - [Spring Boot] CORS 설정하기 => 링크

 

 

CORS가 무엇인가에 대한 것은 아래의 링크를 참고 부탁드립니다.

https://antstudy.tistory.com/259

 

CORS란?

참고자료 [MDN Web Docs] 교차 출처 리소스 공유(CORS) 블로그 [Evans Library] => CORS는 왜 이렇게 우리를 힘들게 하는 걸까? 우아한Tech 테코톡 => 나봄의 CORS # SOP SOP는 Same Origin Policy의 줄임말 다른..

antstudy.tistory.com

 


구글에 검색해보니, 다양한 방법으로 CORS를 설정하는 방법이 있었습니다.

 

저는 WebMvcConfigurer를 Implements 해서 addCorsMappings 메소드(함수)를 오버라이딩하는 방식을 사용했습니다.

 

 

✅ config 폴더에 MvcConfig 자바 파일 만들기

 

 

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
    	// addMapping: CORS를 적용할 URL패턴을 정의할 수 있습니다.
        registry.addMapping("/**")
        		// allowedOrigins: 자원 공유를 허락할 Origin을 지정할 수 있습니다.
                // - 아래와 같이 한번에 여러 Origin을 설정할 수 있습니다.
                .allowedOrigins("http://localhost:3000",
                        "http://localhost:8080",
                        "https://kauth.kakao.com/oauth/authorize/**",
                        "https://accounts.kakao.com/**")
                // allowedMethods: 허용할 HTTP method를 지정할 수 있습니다.
                // - 아래처럼 "*" 를 이용하여 모든 method를 허용할 수 있습니다.
                .allowedMethods("*")
                .allowedHeaders("*")
                .exposedHeaders(HttpHeaders.AUTHORIZATION);
    }
}

위 코드를 config 폴더 안에 있는 MvcConfig 파일과 코드를 추가해줍니다.

그러면 끝입니다.

* 꼭 config 폴더가 아니어도 괜찮습니다.

 

 

 

 

근데 여기서 드는 궁금한 점이 생겼습니다.

  • WebMvcConfigurer 무엇인지?
  • 왜 addCorsMappings 메소드를 override 해서 Origin을 설정하면 CORS 설정이 끝나는지?

그래서 WebMvcConfigurer에 대해 더 찾아봤습니다.

 


❓ WebMvcConfigurer 란?

  • WebMvcConfigurer는 자동 구성된 스프링 MVC 구성에 Formatter, MessageConverter 등을 추가 등록할 수 있다.
  • @EnableWebMvc가 자동적으로 세팅해주는 설정에 개발자가 원하는 설정을 추가할 수 있게 된다.

 

 

그러면 @EnableWebMvc 애노테이션이란?

  • SpringMVC에서 필요한 빈들을 등록하기 위해 @EnableWebMvc 애노테이션을 사용합니다.
  • @EnableWebMvc는 애노테이션 기반의 SpringMvc를 구성할 때 필요한 Bean 설정들을
    자동으로 해주는 애노테이션입니다.
  • 기본적으로 등록해주는 Bean들 이외에 추가적으로 개발자가 필요로 하는 Bean 등의
    등록을 손쉽게 할 수 있도록 도와줍니다.

 

 

 

 

 

반응형

 

 

 

📚 참고자료

  • 블로그 [호형] - Springboot에서 API Docs (Springdoc) 사용하는 방법 (1) => 링크
  • 블로그 [호형] - Springboot에서 API Docs (Springdoc) 사용하는 방법 (2) => 링크
  • 블로그 [soyeon207.log] - Swagger 란 ? (이론 + Spring boot 적용) => 링크
  • SpringDoc 공식 문서 => 링크

 

 

 

Spring2.6 버전 이상에서 springfox-boot-starter:3.0.0를 dependencies에 추가한 후,

애플리케이션을 Run 하면 아래와 같은에러가 떴습니다.

rg.springframework.context.ApplicationContextException: Failed to start bean 'documentationPluginsBootstrapper'; nested exception is java.lang.NullPointerException: Cannot invoke "org.springframework.web.servlet.mvc.condition.PatternsRequestCondition.getPatterns()" because "this.condition" is null

 

검색해본 결과, Spring 2.6 버전과 springfox-boot-starter3.0.0 이 호환성 문제라는걸 알게되었습니다

 

 

 

여기서 해결책은

  1. Spring Boot 를 2.5x 버전대로 내리기
  2.  application.yml 혹은 application.properties에 설정 추가
  3. SpringDoc 을 사용하기(아래에 정리한 코드)

 

 

저는 2.5x 버전으로 내리거나 무언가(설정)을 추가하는 방식이 아닌 세번째 SpringDoc을 사용하는걸 선택했습니다.

 

 


1️⃣ build.gradle 의존성 추가

implementation "org.springdoc:springdoc-openapi-ui:1.5.9"

위 코드를 build.gradle안에 있는 dependencies에 추가해줍니다.

 

 

2️⃣ SwaggerConfig

@OpenAPIDefinition(
        info = @Info(title = "MatDi API",
                description = "MatDi API 명세서.",
                version = "v1"))
@Configuration
@RequiredArgsConstructor
public class SwaggerConfig {

    @Bean
    public GroupedOpenApi customTestOpenAPi() {
        // /test 로 시작하는 API 들을 테스트 관련 API 로 그룹핑
        // member 로 시작하는 API 를 그룹핑 하고 싶다 라고 하면 메소드 이름을 변경하고 하나 더 만들어서 설정하면 됨

        String[] paths = {"/test/**"};

        return GroupedOpenApi
                .builder()
                .group("MatDi API")
                .pathsToMatch(paths)
                .addOpenApiCustomiser(buildSecurityOpenApi()).build();
    }

    public OpenApiCustomiser buildSecurityOpenApi() {
        // jwt token 을 한번 설정하면 header 에 값을 넣어주는 코드, 자세한건 아래에 추가적으로 설명할 예정

        return OpenApi -> OpenApi.addSecurityItem(new SecurityRequirement().addList("jwt token"))
                .getComponents().addSecuritySchemes("jwt token", new SecurityScheme()
                        .name("Authorization")
                        .type(SecurityScheme.Type.HTTP)
                        .in(SecurityScheme.In.HEADER)
                        .bearerFormat("JWT")
                        .scheme("bearer"));
    }

}

Swagger를 설정 및 jwt token을 추가하는 코드입니다.

 

 

 

3️⃣ application.properties

springdoc.default-consumes-media-type= application/json
springdoc.default-produces-media-type= application/json
springdoc.swagger-ui.path= /swagger-ui.html
springdoc.swagger-ui.disable-swagger-default-url= true
springdoc.swagger-ui.display-query-params-without-oauth2= true

application.properties에 위에 해당하는 설정을 추가해줍니다.

 

 

4️⃣ Swagger 접속 URL

 

3.x : http://localhost:8080/swagger-ui/index.html

 

로컬 환경에서 애플리케이션을 Run 한다음에 위 url로 접속하면 됩니다.

 

 

 

 

 

 

반응형

항해99(부트캠프) 실전프로젝트

 

 

😄 JaCoCo를 이용한 Instruction Coverage 확인

 

- 총 25,289개의 라인 중 15,553개의 라인의 코드 커버리지(61%)를 달성했습니다.

- 코드의 안정성을 높이기 위해 최대한 커버리지를 높이려고 노력했습니다.

- 코드 커버리지를 높임으로써 코드 수정 시 버그 발견이 수월해졌습니다.

- 테스트 코드를 작성 하면서 총 서비스 로직에서 3개의 버그를 발견하고 수정했습니다.

 

 

 

😆 소셜로그인 API 제외 시 72% 달성

 

- 소셜로그인 API를 Mock으로 처리하려고 찾아봤지만 자료가 너무 적고 방법을 찾지 못했습니다.

- 결국 소셜로그인 API를 JaCoCo(코드 분석 도구)에서 제외 하는 방법을 찾아 적용했습니다.

 

 

 

 

반응형

 

 

 

🤔 팀프로젝트 중 문제점 발견

  • 로컬 혹은 테스트 환경에서 AWS S3에 이미지 파일을 업로드 기능을 테스트가 필요한 상황이였습니다.
    그런데 이 때마다 AWS S3 버킷에 이미지 파일이 업로드는 문제가 발생했습니다.
    => 테스트마다 AWS S3 버킷에 이미지 업로드 시 비용 발생 위험
    => 더미 이미지 파일이 업로드 되는 문제 발생해서 해당 파일을 삭제 할 때 번거로움 발생

 

 

이 문제를 개선하기 위해 찾아본 결과 S3를 Mock 해주는 방법을 발견하게 되었습니다.

  • 로컬에 인메모리 형태로 S3 Mock 서버를 띄우기
  • 파일을 업로드 할 때 영속성이 없는 휘발성 개념

 

 

 

😁 해결 과정

 

1. build.gradle 외부 의존성(dependencies) 추가

 

 

 

 

 

 

2. S3MockConfig.java

 

 

 

 

 

3. 실제 테스트 코드에서 S3MockConfig @Import 어노테이션 추가

  • 위와 같이 4번째 줄에 있는 @Import(S3MockConfig.class)를 추가해 주면 됩니다.
  • Mock이미지 파일을 업로드 하는 테스트 클래스에 추가를 해주시면, 실제 AWS S3에 이미지가 업로드가 안됩니다.

 

 

 

 

참고한 링크들

 

 

 

 

반응형

 

 

 

참고자료

  • 유튜브 채널 [백기선] => 링크
  • 토비의 스프링 3.1(저자 이일민) 

https://book.naver.com/bookdb/book_detail.nhn?bid=7006516 

 

토비의 스프링 3.1 세트

『토비의 스프링 3.1』은 스프링을 처음 접하거나 스프링을 경험했지만 스프링이 어렵게 느껴지는 개발자부터 스프링을 활용한 아키텍처를 설계하고 프레임워크를 개발하려고 하는 아키텍트에

book.naver.com


 

https://www.youtube.com/watch?v=97lYN9YW03Q 

 

위의 영상을 기반으로 작성 했습니다.

 

토비의 스프링을 공부 하다가 어떻게 해야 효율적으로 공부 할 수 있을까 고민하게 되었습니다.

이전까지는 단순히 해당 내용을 최대한 간추려서 전부 적을려고 했는데 많이 비효율적이라고 생각했습니다.

그래서 자주 보는 백기선님의 유튜브 채널에 잘 나와 있어서 보고 정리해봤습니다.

 

 

 스프링 학습 로드맵은 없다. 

  • 시중에 나와있는 책들이 로드맵을 제공 한다고 할 수 있다.
    => 하지만 저자가 중요하다고 생각하는 것을 정리해서 나온것(저자가 추측)
    => 모든 사람에게 그 로드맵이 정답이라고 할 수없음
  • 학습 로드맵은 자기 자신에게 달려있다.
    => 자기 자신이 원하는게 무엇인지?
    => 자신이 얼마나 스프링을 알고 싶은지가 중요하고 각 단계마다 공부법이 다르다.
    (대충 알아도 되는 단계, 좀 더 궁금한 단계, 깊게 알고 싶은 단계, 다 알고싶다 등..)
  • 너무 깊게 공부하는 단계는 가성비가 안나온다.
    => 내가 학습하는 비용에 비해서 개발에 얼마나 도움이 되는지?
    => 깊게 공부하면 언젠가는 도움이 되지만, 실제 만들 때 가성비가 좋지 않음

 

 

 

 대충 알아도 되는 단계 

  • 스프링의 "스"자도 몰랐을 때
  • 스프링의 코드를 보고 익히는게 좋다.
    => DI의 개념을 먼저 공부하는게 아니라 코드를 보고 "객체를 이렇게 받아올 수 있구나" 정도
    => AOP는 예제코드를 타이핑 해보는 정도까지만 하고 끝내기
  • 스프링이 무엇을 해주는지 감을 잡는 단계
  • 이정도 공부 하는데 어렵지는 않다.
    => 하지만 코딩을 직접 해보지 않기 때문에 1 ~ 2달이면 까먹을 수 있다.
    => 직접 타이핑 해야 훨씬 기억에 많이 남는다.

 

 

 좀 더 궁금한 단계 

  • 스프링을 직접 사용해서 개발을 해야 하는 단계
  • 볼려는 레퍼런스가 너무 방대하다 싶으면 그것을 전부 다 보는 것은 가성비가 안나온다.
    => 토비의 스프링을 전부 정독하는 것
  • 핵심을 파악할 것
    => IoC 컨테이너, AOP, 추상화 계층(MVC, JDBC, Resource, O/X M, O/J M 등등)
    => 예제 코드 하나씩은 직접 짜볼 것
    => 이거 이해하고 짜보는데 그 두꺼운 책이나 레퍼런스를 다 읽을 필요가 없다.
  • 취업이 목표라면 이정도 단계여도 하는데 문제는 없다.
  • 토비의 스프링을 전부 보는게 아니라 필요한 부분만 보는 것
    => Controller의 계층구조는 상속구조로 만드는 내용 같은건 스킵 하는게 좋다.
  • 이정도까지 공부하면 누구한테도 설명이 가능한 정도

 

 

 스프링에 사랑에 빠진 단계 

  • 전부 다 공부하는 것은 가성비가 안나온다.
  • 이렇게 공부하는건 언젠가는 도움은 되지만, 그 시간에 다른 것을 공부 할 수 있다.
  • 회사에 입사하고 업무에서 사용을 스프링을 안쓸수도 있다.
    => 스프링을 깊게 공부 했는데 이직을 해서 사용을 안한 경우도 있음.
    => 이 단계에서는 취미로 스프링 공부를 꾸준히 할 수도 있음.
  • 스프링 부트는 그나마 짧아서 괜찮지만 스프링은 너무 방대하다.
반응형

 

참고자료

  • 토비의 스프링 3.1(저자 이일민) 53 ~ 54P

https://book.naver.com/bookdb/book_detail.nhn?bid=7006516 

 

토비의 스프링 3.1 세트

『토비의 스프링 3.1』은 스프링을 처음 접하거나 스프링을 경험했지만 스프링이 어렵게 느껴지는 개발자부터 스프링을 활용한 아키텍처를 설계하고 프레임워크를 개발하려고 하는 아키텍트에

book.naver.com


 

1️⃣ 스프링은 자바를 기반으로 한 기술이다.

  • 자바는 객체지향 프로그래밍이 가능한 언어
  • 자바 엔터프라이즈 기술의 혼란 속에서 잃어버렸던 객체지향 기술의 진정한 가치를 회복시키고,
    그로부터 객체지향 프로그래밍이 제공하는 폭 넓은 혜택을 누릴 수 있도록 기본으로 돌아가자는 것이 바로
    스프링의 핵심 철학이다.

 

 

2️⃣ 스프링을 이해하려면 오브젝트에 깊은 관심을 가져야 한다.

  • 스프링이 가장 관심을 많이 두는 대상은 오브젝트다.
  • 애플리케이션에서 오브젝트가 생성되고 다른 오브젝트와 관계를 맺고, 사용되고, 소멸하기까지의
    전  과정을 진지하게 생각해볼 필요가 있다.
    더 나아가서 오브젝트는 어떻게 설계돼야 하는지, 어떤 단위로 만들어지며 어떤 과정을 통해
    자신의 존재를 드러내고 등장해야 하는지에 대해서도 살펴봐야 한다.

 

 

3️⃣ 오브젝트에 대한 관심 ➡ 오브젝트 설계

  • 객체지향 설계(Object Oriented Design)의 기초와 원칙
  • 다양한 목적을 위해 재활용 가능한 설계 방법인 디자인 패턴
  • 좀 더 깔끔한 구조가 되도록 지속적으로 개선해나가는 작업인 리팩토링
  • 오브젝트가 기대한 대로 동작하고 있는지를 효과적으로 검증하는 데 쓰이는 단위 테스트

 

3️⃣ 스프링은 객체지향 설계, 구현을 강요하지 않는다.

  • 하지만 오브젝트를 어떻게 효과적으로 설계하고 구현, 사용, 이를 개선해나갈 것인가에 대한 명쾌한 기준 마련
  • 객체지향 기술과 설계, 구현에 관한 실용적인 전략과 검증된 베스트 프랙티스를 평범한 개발자도 자연스럽고
    손쉽게 적용할 수 있도록 프레임워크 형태로 제공한다.

 

 

 

반응형

 

참고자료

  • 토비의 스프링 3.1(저자 이일민) 43 ~ 45P

 

 

토비의 스프링 책에 나오는 스프링을 효과적으로 학습하는 세 가지 단계를 정리해봤습니다.

 

 

 

1️⃣ 스프링의 핵심 가치와 원리에 대한 이해

  • 스프링의 핵심 가치를 이해하고, 스프링 스스로가 그 가치를 어떻게 적용해서 만들어져 있는지 이해한다.
  • 스프링에는 가장 중요한 핵심 가치와 그것이 가능하도록 도와주는 세 가지 핵심 기술이 있다.
    • IoC / DI
      - 오브젝트의 생명주기와 의존관계에 대한 프로그래밍 모델.
      - 객체지향 설계 원칙과 디자인 패턴의 핵심 원리를 담고 있으며 프레임워크의 근간으로 삼고 있다.
      - 스프링이 직접 제공하는 모든 기술과 API, 심지어 컨테이너도 IoC/DI 방식으로 작성되어 있다.
    • 서비스 추상화
      - 이식성이 뛰어나다(서버, 특정 기술에 종속 되지 않는다.)
    • AOP
      - 애플리케이션 코드에 산재해서 나타나는 부가적인 기능을 독립적으로 모듈화 하는 프로그래밍 모델

 

 

2️⃣ 스프링의 기술에 대한 지식과 선택 기준 정립

  • 스프링의 본 원리를 확실하게 이해 후 이를 다양한 방법으로 확장하고 적용했는지 살펴볼 차례이다.
  • 스프링은 매우 범용적이고 애플리케이션의 모든 레이어를 폭 넓게 다루고 있다.
    => 그 중에서 어떤 것을 선택할지는 개발자의 몫이다.
  • 스프링이 제공하는 방법과 연동하는 프레임워크와 스타일을 사용할 것인지는 개발자에게 큰 고민이다.
    => 이런 고민을 피하고 남들이 만들어놓은 예제를 가져다가 생각없이 사용하는 일은 피해야 한다.
  • 두 번째 단계는 바로 이 다양한 선택의 문제를 각 기술영역별로 효과적으로 다루는 법을 배우는 것이다.
    => 먼저 스프링이 제공하는 기술의 종류와 접근 방법에는 어떤 것이 있는지 충분히 살펴보고,
    선택의 기준을 마련해서 그때그때 상황에 맞는 최선의 기술과 접근 방법을 선택 할 수 있어야 한다.

 

 

3️⃣ 스프링의 적용과 확장

  • 스프링의 다양한 기술을 어떻게 실제 애플리케이션 개발에 어떤 식으로 적용해야 하는지를 공부해야 한다.
    => 스프링은 특정 아키텍처에 제한되는 프레임워크가 아니다.
  • 스프링은 이전에는 기술적인 문제로 쉽게 적용하지 못했던 아키텍처도 마음껏 활용할 수 있게 도와준다.
    => 또한 스프링에 제공하는 기능을 그대로 사용하는 것 외에도 그것을 확장하거나 추상화해서 사용하는 방법을 알아야 한다.
    * 스프링을 효과적으로 사용하는 기업과 개발팀에서는 스프링을 기반으로 프레임워크를 만들어서 사용한다.
  • 스프링을 효과적으로 사용할 수 있도록 주어진 환경과 현재 프로젝트에 맞는 방식의 사용 기준을 마련하고, 이를
    틀(프레임워크)의 형태로 만들어서 개발자들이 이용할 수 있게 해주는 것이다.
    스프링의 자유도를 줄이고 각 현장의 상황에 맞는 접근 방법을 정립해주는 작업이라고도 볼 수 있다.
    때로는 스프링이 직접 지원 하지 않는 기술을 접목해서 사용하는 경우를 위해서 해당 기술을 스프링에 맞게 통합하는 작업도 포함된다.

 

 

 

반응형

 

참고자료

  • 토비의 스프링 3.1(저자 이일민)

 

스프링이란 무엇인가?

  • 자바 엔터프라이즈 애플리케이션 개발에 사용되는 애플리케이션 프레임워크다.
  • 애플리케이션 개발을 빠르고 효율적으로 할 수 있도록 애플리케이션의 바탕이 되는
    틀과 공통 프로그래밍 모델, 기술 API 등을 제공해준다.

 

 

1️⃣ 애플리케이션의 기본 틀 - 스프링 컨테이너

  • 스프링은 스프링 컨테이너 또는 애플리케이션 컨텍스트라고 불리는 스프링 런타임 엔진을 제공한다.
    - 스프링 컨테이너는 설정정보를 참고로 해서 애플리케이션을 구성하는 오브젝트를 생성 및 관리
    - 스프링 컨테이너는 독립적으로 동작할 수도 있지만 보통 웹 모듈에서 동작하는 서비스나 서블릿으로
      등록해서 사용

* 스프링을 사용하려면 먼저 스프링 컨테이너를 다루는 방법과 스프링 컨테이너가 애플리케이션 오브젝트를 이용할 수 있도록 설정정보를 작성하는 방법을 알아야 한다.

 

 

 

 

2️⃣ 공통 프로그래밍 모델 - IoC/DI, 서비스 추상화, AOP

프로그래밍 모델이란?

프레임워크가 애플리케이션을 구성하는 오브젝트가 생성되고 동작하는 방식에 대한 틀을 제공해주고,
애플리케이션 코드가 어떻게 작성돼야 하는지에 대한 기준을 제시해준다.

이런 틀을 프로그래밍 모델이라고 한다.

 

 

스프링이 제공하는 핵심 세 가지 프로그래밍 모델

 

  1. IoC/DI
    - 오브젝트의 생명주기와 의존관계에 대한 프로그래밍 모델
    - 스프링은 유연하고 확장성이 뛰어난 코드를 만들 수 있게 도와주는 객체지향 설계 원칙과 디자인 패턴의 핵심 원리를 담고 있는 IoC / DI를 프레임워크의 근간으로 삼고 있다.
    - IoC / DI 방식을 따라서 작성돼야 스프링이 제공하는 가치를 제대로 누릴 수 있다.
    - 스프링이 직접 제공하는 모든 기술과 API, 심지어 컨테이너도 IoC / DI 방식으로 작성되어 있다.
      스프링을 바르게 이해하고 효율적으로 사용하는 데 기본이 되며 가장 중요한 기술이다.

  2. 서비스 추상화
    - 스프링이 사용하면 환경이나 서버, 특정 기술에 종속되지 않고 이식성이 뛰어나며 유연한 애플리케이션을 만들 수 있는데, 이를 가능하게 해주는 것이 바로 서비스 추상화다.
    - 구체적인 기술과 환경에 종속되지 않도록 유연한 추상 계층을 두는 방법이다.
  3. AOP
    - 애플리케이션 코드에 산재해서 나타나는 부가적인 기능을 독립적으로 모듈화하는 프로그래밍 모델이다.
    - 스프링은 AOP를 이용해서, 다양한 엔터프라이즈 서비스를 적용하고도 깔끔한 코드를 유지할 수 있게 해준다.|

 

 

3️⃣ 기술 API

  • 스프링은 엔터프라이즈 애플리케이션 개발의 다양한 역영에 바로 활용할 수 있는 방대한 양의 기술 API를 제공한다.
    - UI 작성은 물론이고 웹 프레젠테이션 계층, 비즈니스 서비스 계층, 기반 서비스 계층, 도메인 계층, 데이터 액세스 계층 등에서 필요한 주요 기술을 스프링에서 일관된 방식으로 사용할 수 있도록 지원해주는 기능과 전략 클래스 등을 제공한다.
  • 스프링이 제공하는 API와 지원 기술은 모두 스프링의 프로그래밍 모델에 따라 작성되어 있기 때문에, 이를 가져다 쓰는 것만으로도 스프링의 프로그래밍 모델을 코드에 자연스럽게 적용 할 수 있다.
  • 스프링의 모든 기술은 표준 자바 엔터프라이즈 플랫폼 (JavaEE)에 기반을 두고 있다.
    => 표준 기술과 더불어 유명 오픈소스 기술과 주요 상용 기술에 대한 지원 기능도 다양하게 제공된다.

 

 

 

프링을 사용한다는 것은 이 세 가지 요소를 적극적을 활용해서 애플리케이션을 개발한다는 뜻이다.

  • 클래스는 스프링 컨테이너 위에서 오브젝트로 만들어져 동작하게 만든다.
  • 코드는 스프링의 프로그래밍 모델을 따라서 작성한다.
  • 엔터프라이즈 기술을 사용할 때는 스프링이 제공하는 기술 API와 서비스를 활용하도록 한다.

 

반응형

 

 

 

참고자료

 

 

# 영속성

  • 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성을 말한다.
  • 영속성을 갖지 않는 데이터는 메모리에서만 존재하기 때문에 프로그램을 종료하면 사라진다.

 

 

영구적인 객체(Object Persistence)

  • 메모리 상의 데이터를 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용하여 영구적으로 저장하여 영속성을 부여한다.
  • 데이터를 데이터베이스에 저장하는 3가지 방법
    1. JDBC
    2. Spring JDBC (Ex. JDBC Template)
    3. Persistence Framework (Ex. Hibernate, Mybatis 등)

Persistence Framework

  • JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터베이스와 연동되는 시스템을 빠르게 개발할 수 있으며 안정적인 구동을 보장한다.
  • Persistence Framework는 SQL Mapper와 ORM으로 나눌 수 있다. Ex) JPA, Hibernate, Mybatis 등

 

 

# ORM이란?

  • Object-Relational Mapping 객체-관계 매핑
    • 객체 지향 프로그래밍은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용한다.
    • 객체 모델과 관계형 모델 간에 불일치가 존재한다.
    • ORM을 통해 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하여 불일치를 해결한다.
  • 데이터베이스 데이터 ←—매핑—→ Object 필드
    • 객체를 통해 간접적으로 데이터베이스 데이터를 다룬다.
  • Persistant API라고도 할 수 있다.
    • Ex) JPA, Hibernate 등

 

 

# Hibernate(하이버네이트)

  • 자바 환경에서의 객체-관계 모델 매핑 솔루션.
  • ORM이라 불리우는 객체-관계-매핑은 어플리케이션레벨의 도메인 객체를 관계형 데이터베이스 테이블의 형태로 혹은 역으로 매핑시켜주는 프로그래밍 기술.
  • JPA의 구현체로, JPA 인터페이스를 구현하며, 내부적으로 JDBC API를 사용

 

 

 

# JPA(Java Persistence API)란?

  • 자바 퍼시스턴스 API 또는 자바 지속성 API 로 불린다.
  • 자바 플랫폼 SE자바 플랫폼 EE를 사용하는 응용프로그램에서 관계형 DB의 관리를 표현하는 자바 API
  • 기존에 EJB에서 제공되던 엔터티 빈(Entity Bean)을 대체하는 기술이다.
  • 현재 자바 진영의 ORM 기술 표준으로, 인터페이스의 모음
    - 실제로 동작하는 것이 아니다.
    - JPA 인터페이스를 구현한 대표적인 오픈소스가 Hibernate라고 할 수 있다.

 

 

# EJB란?(더보기 클릭)

더보기
  • Java EE의 API 중 하나이고, 주로 웹 시스템에서 JSP로 화면을 구성하고 EJB는 비즈니스 로직을 처리한다.
  • EJB는 기업환경의 시스템을 구현하기 위해 위 스펙에 따라 비즈니스 로직을 처리하는 서버 어플리케이션이다.

 

단점

  • 객체 지향적이지 않ㄴ다.
  • 복잡한 프로그래밍 모델
  • 특정 환경, 기술에 종속적인 코드

개발 생산성을 위해 등장했으나 실제론 개발 생산성이 떨어지고 이동성이 부족하다.

 

 

 

 

 

 

 

 

 

# JPA의 동작 과정

  • JPA는 어플리케이션과 JDBC 사이에서 동작한다.
  • JPA 내부에서 JDBC API를 사용하여 SQL을 호출하여 DB와 통신한다.
  • 개발자가 ORM 프레임워크에 저장하면 적절한 INSERT SQL을 생성해 DB에 저장해주고,
    검색을 하면 SELECT SQL을 생성해 결과를 객체에 매핑하고 전달해준다.

 

 

 

# JPA를 사용해야 하는 이유

생산성

  • JPA를 자바 컬렉션에 객체를 저장하듯 JPA에게 저장할 객체를 전달.
  • INSERT SQL을 작성하고 JDBC API 사용하는 지루하고 반복적인 일을 JPA가 대신 처리해준다.
  • CREATE TABLE같은 DDL문 자동 생성
  • 데이터베이스 설계 중심의 패러다임을 객체 설계 중심으로 역전

유지보수

  • 엔티티에 필드 추가시 등록, 수정, 조회 관련 코드 모두 변경
  • JPA를 사용하면 이런 과정을 JPA가 대신 처리
  • 개발자가 작성해야 할 SQL과 JDBC API 코드를 JPA가 대신 처리해줌으로 유지보수해야 하는 코드 수가 줄어든다.
반응형

+ Recent posts