스프링 마스터🌱

사실 원래대로라면 굉장히 까다로운 부분일텐데다행히도 이번 학기 캡스톤에서 스프링을 써서 관련 환경설정이 쉬웠다.https://start.spring.io여기서 스프링 프로젝트를 만들었다. 편하고 좋더라는스프링 프로젝트에서 static/index.html 파일을

예전에 캡스톤 하면서 controller랑 service랑 domain이랑 뭐가 뭔지 모르지만 그냥 눈치껏 썼던 기억이 난다.이제 제대로 알아보자!일반적인 웹 애플리케이션 계층 구조는 다음과 같다.컨트롤러: 컨트롤러 혹은 API도메인: 주로 데이터베이스에 저장하고 관리

Spring container에서 Spring bean이 관리된다.ex. 스프링이 뜰 때 @Controller 어노테이션을 보고 컨트롤러 객체를 만들어서 스프링 컨테이너에 넣는다.(스프링이 관리) 즉, 스프링 빈으로 등록된다. @Autowired가 memberServi

DB는 commit 하기 전에는 반영이 안된다. 따라서 테스트 끝나고 rollback 해버리면 디비에는 반영이 안된다. test 끝나고 rollback 해주는 어노테이션이 @Transactional 이다. @AfterEach 로 지워주지 않아도 테스트 반복해서 실행이

AOP란 무엇인지 알아보기 전에 언제 필요한지를 생각해보자.만약 프로젝트의 모든 메소드의 호출 시간을 측정하려면 어떻게 해야할까? 모든 메소드 앞뒤에다가 시간을 측정하는 로직을 찍기도 애매.. 메소드 1000개씩 되면 이제 큰일나는 것이다. 개발자들이 제일 눈뜨고 못

스프링의 핵심은 무엇일까?스프링은 자바 언어 기반의 프레임워크다. 따라서 객체 지향 언어라는 자바의 가장 큰 특징을 살려낸다.즉, 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크다.객체 지향 프로그래밍은 컴퓨터 프로그램을 객체들의 모임으로 파

강의를 들으면서 만들었던 예제 중에 다시 짚어볼만 한 것 위주로 정리해보려고 한다.비지니스 요구사항에서 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수도 있다. 아직 확정이 되지 않았기에, interface를 만들어서 구현체는 언제든지 갈아끼울 수

이전 포스트에서 말했듯이 앞선 코드의 문제점은 클라이언트 코드에서 new로 구체 클래스에 의존하고 있기 때문에, 결국 구현와 역할 모두에 의존하는 것이었다.그래서 변경을 할 때 다음과 같은 문제가 생긴다.우리는 클라이언트(OrderServiceImpl) 코드 변경 없이

상당히 중요한 파트 같다.AppConfig 등장 이후 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 AppConfig가 다 가져가게 된다.프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한

지금까지는 순수한 자바 코드로 DI를 적용해왔는데, 스프링을 이용하는 방식으로 바꾸면 다음과 같다.📍 @Configuration 어노테이션을 붙여준다: AppConfig에 설정을 구성한다는 의미.📍 각 메서드에 @Bean 어노테이션 붙여준다. 이러면 스프링 빈으로

지금까지는 AppConfig 파일에 직접 @Bean을 통해서 스프링 빈을 등록했었다. 지금부터는 자동으로 스프링 빈을 등록해주는 컴포넌트 스캔에 대해 알아봅시다.컴포넌트 스캔을 사용하려면 @ComponentScan 어노테이션을 붙여준다. 컴포넌트 스캔은 말 그대로 @C

의존관계 주입은 다양한 방법이 있다.생성자 주입수정자 주입(setter 주입)필드 주입일반 메서드 주입말 그대로 생성자를 통해 주입하는 것이다.이렇게 생성자를 통해서 의존관계를 주입 받는다. 만약 생성자가 하나라면 @Autowired를 생략해도 자동으로 주입을 해준다.

롬복을 사용하면 위처럼 생성자로 의존관계 주입을 간단하게 쓸 수 있다.뭔가 야무진 친구 같은데 우선 강의에서는 이 정도 언급했다. 이럴 줄 알았다면 앞에 게시글에 붙여서 쓸걸...

우리가 @Autowired를 써서 주입할 때, type으로 빈을 찾게 된다. ac.getBean(DiscountPolicy.class) 와 유사하게 동작하는 것이다. 그렇다면 타입으로 조회했을 때 빈이 2개 이상이면 문제가 발생한다.NoUniqueBeanDefiniti

전 포스트에서 @Qualifier("mainDiscountPolicy")를 알아봤다. 하지만 이 경우는 직접 "mainDiscountPolicy" 문자를 적어주기 때문에 컴파일 시 타입체크가 안된다. 컴파일 에러는 세상에서 제일 좋은 오류....이럴 때는 어노테이션을

조회한 빈이 모두 필요한 경우가 있다. ex) 클라이언트가 할인의 종류를 직접 선택할 수 있는 경우Map<String, 타입> : key는 스프링 빈 이름, value는 타입으로 조회한 스프링 빈이 담긴다.List<타입> : 타입으로 조회한 모든 빈을 담아준

스프링 빈의 라이프사이클은 다음과 같다.📍 객체 생성 ➡️ 의존관계 주입우선 스프링 빈 객체를 생성하고, 의존관계 주입이 다 끝나야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 그렇다면 개발자가 언제 의존관계 주입이 완료되었는지 알 수 있을까?스프링은 의존관계

웹에서는 모든 것이 HTTP를 기반으로 이루어진다HTTP 메시지에 모든 것을 전송 가능(HTML, TEXT, 파일, 사진 등)웹 서버(Web Server)http 기반으로 동작정적 리소스 제공클라이언트가 서버로 http 요청을 보내면 서버가 정적 리소스를 http 응답

웹 애플리케이션 서버를 직접 구현한다고 하면, 의미있는 비지니스 로직을 수행하는 것뿐만 아니라 http 요청을 해석하고 http 응답 메시지를 작성하는 등의 과정도 필요하다.서블릿을 지원하는 WAS를 사용하게 되면 자동으로 http 요청이나 응답 메시지 관련 로직은 수