스프링 강의 내용 정리

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술스프링 부트가 제공하는 Welcome Page 기능 \- static/index.html 을 올려두면 Welcome page 기능을 제공한다. 공식 사이트 링크(https://docs.

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술1\. 웹 브라우저에서 url을 입력하면 내장 톰켓 서버에서 요청을 받는다.2\. 톰켓 서버는 스프링에게 요청을 넘긴다.3\. 스프링은 controller 쪽에서 hello-static이 있는지 먼

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술데이터: 회원ID, 이름기능: 회원 등록, 조회아직 데이터 저장소가 선정되지 않음(가상의 시나리오)컨트롤러: 웹 MVC의 컨트롤러 역할서비스: 핵심 비즈니스 로직 구현리포지토리: 데이터베이스에 접근

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술컴포넌트 스캔과 자동 의존관계 설정자바 코드로 직접 스프링 빈 등록하기컨트롤러가 서비스를 통해서 기능을 동작하는 것을 의존관계가 있다고 표현한다. ( 컨트롤러가 서비스를 의존한다.)해당 코드 실행시

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술다음과 같이 HomeController 클래스를 생성한다.그리고 다음과 같이 코드를 작성한다.위에 코드는 @GetMapping("/") 에서 볼 수 있듯이 "/" 경로로 들어올 경우 호출 된다.즉,

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술반복 개발해온 기본 CRUD 기능도 스프링 데이터JPA가 모두 제공함개발자는 핵심 비즈니스 로직을 개발하는데, 집중할 수 있다.먼저 repository/SpringDataJpaMemberReposi

스프링 핵심 원리 - 기본편핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타웹 기술: 스프링 MVC, 스프링 WebFlux데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원기술 통합: 캐시, 이메일, 원격접근, 스케줄링테스트: 스프링 기반 테스

스프링 핵심 원리 - 기본편• SRP: 단일 책임 원칙(single responsibility principle)• OCP: 개방-폐쇄 원칙 (Open/closed principle)• LSP: 리스코프 치환 원칙 (Liskov substitution principle

스프링 핵심 원리 - 기본편기획자로부터 아래의 요구사항을 듣게 된다. 1) 회원회원을 가입하고 조회할 수 있다.회원은 일반과 VIP 두 가지 등급이 있다.회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)2) 주문과 할인 정책회원은

스프링 핵심 원리 - 기본편1) 기획자가 새로운 할인 정책을 요청한다. 기획자: "서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 정률% 할인으로 변경하고 싶어요."순진 개발자(우리들): "제가 처음부터 고정 금액 할인은 아니라고 했잖아요."악덕 기

스프링 핵심 원리 - 기본편현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안보인다.AppConfig 에서 아래 그림의 모든 요소를 드러나도록 바꾸자. 그림과 같이 메서드 명을 보면 역할 마다의 구현이 모두 드러나있다. 애플리케이션의 구성이 한 눈에

스프링 핵심 원리 - 기본편1) 기존 프로그램 : 구현 객체가 스스로 제어 흐름을 조종기존 프로그램은 구현 객체가 스스로 필요한 객체를 생성하고, 연결하고, 실행했다. 2) AppConfig가 외부에서 프로그램 동작 방식을 제어반면에 AppConfig를 도입한 후에는

스프링 핵심 원리 - 기본편ApplicationContext는 스프링 컨테이너다. ApplicationContext 는 인터페이스인데, 그것을 구현한 클래스가AnnotationConfigApplicationContext다. 스프링 컨테이너를 생성하는 방법에는 XML 기

스프링 핵심 원리 - 기본편임시로 MemberRepository 타입 빈이 2개 있는 SameBeanConfig.class 설정 파일을 만들었다. 여기서 MemberRepository.class 타입의 빈을 가져올 것이다. 아래는 코드이다.아래와 같은 NoUniqueB

스프링 핵심 원리 - 기본편스프링 컨테이너는 다양한 설정 형식을 지원한다. 아래 사진과 같이 자바 코드, XML, Groovy 등등.. 지금까지 애노테이션 기반 자바 코드로 설정(팩토리 빈으로 설정)하는 법을 배웠다.AppConfig라는 팩토리 빈에서 @Bean 애노테

스프링 핵심 원리 - 기본편웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 고객 요청이 올 때마다 AppConfig가 객체를 새로 만들면게 된다면, 요청이 올 때마다 아래 그림과 같이 인스턴스가 새로 생성된다.만약 1000개의 요청이 서버에 들어오게 된다면 1

스프링 핵심 원리 - 기본편(https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8아래는

스프링 핵심 원리 - 기본편지금까지 애노테이션 기반 자바 설정 정보로 스프링 빈을 생성했다. 하지만 귀찮다는 단점이 있다.그래서 스프링은 설정 정보 파일이 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공한다. 먼저 기존 AppConfig.java는 과거

스프링 핵심 원리 - 기본편애노테이션 2개를 만드는데, '포함'한다는 의미로 MyIncludeComponent 라고 이름붙인다.애노테이션 MyExcludeComponent 는 제외의 용도로 만든다. 클래스 2개를 만들고 각각 다른 애노테이션을 붙인다.BeanA 클래스에

스프링 핵심 원리 - 기본편이름 그대로 생성자를 통해 의존 관계를 주입 받는 방법이다. 지금까지 해온 생성자에 @Autowired 를 붙이는 방식이다. 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용한다. 스프링 빈의 생성자가 1개인

스프링 핵심 원리 - 기본편최근에는 스프링을 포함한 DI 컨테이너들은 생성자 주입을 권장한다. 그 이유는 다음과 같다. 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용한다. 애플리케이션을 종료할 때 까지 의존관계를 변경할 일이 있을까?

스프링 핵심 원리 - 기본편@Autowired 는 타입으로 빈을 조회한다.인터페이스 DiscountPolicy의 구현체 2개가 있다. RateDiscountPolicy와 FixDiscountPolicy 는 타입이 같다.@Autowired 는 가장 먼저 스프링 빈의 타입

스프링 핵심 원리 - 기본편지난 시간에 @Qualifier에 @Qualifier("mainDiscountPolicy") 이름을 지정해서 사용했었다. 여기서 문제점은 사용자의 문자 실수는 컴파일 타임에 잡을 수 없다는 것이다.해당 문제를 @Qualifier 용도로 쓸 @

스프링 핵심 원리 - 기본편데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.실제 네트워크에 연결하는 건 아니고

스프링 핵심 원리 - 기본편스프링 빈은 기본적으로 싱글톤 스코프로 생성된다.스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.프로토타입: 스프링 컨테이너는 프로토타입

스프링 핵심 원리 - 기본편웹 스코프는 웹 환경에서만 동작한다.웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 시작부터 종료시점까지 관리한다. \- 따라서 종료 메서드가 호출된다.request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프,

스프링 핵심 원리 - 기본편학기중에 강의를 듣기도했고 방학중에는 연구실 활동이 바빠서 생각보다 오래걸리긴 했으나 열심히 들었던 것 같다.스프링을 이용해서 유튜브 클론 프로젝트를 진행해본 경험이있는데, 해당 프로젝트를 할때는 스프링에 대한 이해가 부족해서 따라가기 급급했

클라이언트가 직접 데이터베이스에 접근하지 않고, 애플리케이션 서버를 거쳐 DB의 데이터를 받아오게 된다.애플리케이션 서버는 DB서버와 연결을 해두고, SQL과 같은 DB 구문을 통해 요청을 한 데이터를 받아오게 된다.과거의 수많은 DB들은 모두 사용법이 달랐고 애플리케

딱봐도 과정이 굉장히 복잡하다.이런 문제를 해결하기 위한 방법이 미리 커넥션을 생성해 두고, 이를 재사용하는 것이 커넥션 풀이다. 서비스 시작 시점에 필요한 개수의 커넥션을 생성해 풀에 보관한다.클라이언트의 요청이 들어오면 서비스 로직은 이제 커넥션 풀에서 커넥션을 객

모든 작업이 성공해서 데이터베이스에 정상 반영하는 것을 커밋( Commit )이라 한다.작업 중 하나라도 실패해서 거래 이전으로 되돌리는 것을 롤백( Rollback )이라 한다.데이터베이스에서 데이터에 대한 하나의 논리적 실행단계를 트랜잭션이라고 한다. 예를 들어,

실제 애플리케이션에서 DB 트랜잭션을 사용해서 계좌이체 같이 원자성이 중요한 비즈니스 로직을 어떻게 구현하는지 알아보자. 먼저 트랜잭션 없이 단순하게 계좌이체 비즈니스 로직만 구현해보자보는 것과 같이 트랜잭션 없이 단순하게 구현한 코드이다. 즉, 오토 커밋모드를 이용한

클라이언트의 진입점으로 UI와 관련된 처리 한다.클라이언트의 요청을 검증하고 응답한다.주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC비즈니스 로직을 담당한다.특정 프레임워크 기술에 종속적이지 않아야 프레젠테이션과 데이터 계층의 기술 변경에도 코드가 유지

해당 게시물은 인프런 "스프링 DB 1편 - 데이터 접근 핵심 원리" 강의를 참고하여 작성한 글 입니다. 1. 예외 계층 >- Object : 예외도 객체이다. 모든 객체의 최상위 부모는 Object 이므로 예외의 최상위 부모도 Object 이다. Throwable

이번에는 서비스 코드의 예외 의존성을, 런타임 예외로 전환하여 제거해보자.인터페이스의 메서드 선언부에서도 throw 예외를 선언해 주어야하기 때문이다.이러한 문제 때문에 향후 JDBC가 아닌 다른 기술로 변경한다면 인터페이스 자체를 변경해야 한다.즉, 인터페이스가 특정

스프링 DB 1편 강의를 성공적으로 마무리하였다. 강의를 듣는 동안 모든 내용을 이해했다고 생각했지만, 내용을 다시 정리하면서 더 많은 것을 배울 수 있었다. 특히, 트랜잭션 AOP를 계속 사용해왔지만, 왜 이를 사용해야 하는지에 대한 근본적인 이해가 부족했다. 하지만

개발자는 SQL만 작성하면 해당 SQL의 결과를 객체로 편리하게 매핑해줌JDBC를 직접 사용할 때 발생하는 중복 제거, 기타 개발자에게 편리한 여러 기능 제공JdbcTemplate , Mybatis기본적인 SQL은 JPA가 대신 작성하고 처리. 개발자는 저장하고 싶은

이런 규칙들을 간단히 실천할 수 있지만, 지키지 않으면 개발이 더 어려워질 수 있다. 이 내용을 명심하고 앞으로 주의하며 프로그래밍할 것이다.

결국, 객체지향적인 코드 작성은 더 나은 소프트웨어 엔지니어가 되는 여정의 일부라고 생각한다.

인터페이스 분리 원칙과 의존관계 역전 원칙을 포함한 SOLID 원칙들은 코드의 결합도를 낮추고, 의존성을 관리하는 데 중점을 둔다. 이를 통해, 변경에 유연하게 대응할 수 있는 소프트웨어를 만들 수 있으며, 이는 장기적으로 프로젝트의 성공을 좌우하는 결정적 요소가 된다

이번 리팩토링 과정을 통해, 의존성 추상화의 중요성과 그로 인해 얻을 수 있는 이점들을 명확히 확인할 수 있었다. 의존성을 추상화함으로써, 우리는 변화에 더욱 민첩하게 대응할 수 있는 코드를 작성할 수 있게 되었고, 테스트 작성의 어려움을 크게 줄일 수 있었다. 이러한

테스트는 단순히 문제를 찾아내는 과정이 아니라, 우리의 코드가 더 견고하고 신뢰할 수 있도록 만드는 과정이다. 테스트를 통해 코드의 내구성을 높이고, 유지보수를 단순화할 수 있다. 테스트 루틴이 없는 코드는 레거시한 코드라고 생각한다.