※ 목차
1. 강의 소개
2. 프로젝트 환경설정
View 환경설정
- 스프링은 방대하기 때문에 필요한 것만 찾는 능력이 중요
- ex) spring.io -> projects -> Spring Boot -> LEARN -> Reference Doc.
Spring Boot Reference Documentation
The reference documentation consists of the following sections: Legal Legal information. Getting Help Resources for getting help. Documentation Overview About the Documentation, First Steps, and more. Getting Started Introducing Spring Boot, System Require
docs.spring.io
- index.html은 정적페이지다. 파일을 그냥 웹서버가 웹 브라우저에 넘겨주는 것. 프로그래밍이 아닌 것이다. 파일을 그대로 던져준 것.
- 템플릿 엔진을 쓰면 원하는 대로 루프를 넣거나 해서 모양을 바꿀 수 있따.
- WebApplication에서 첫번째 진입점이 Controller
3. 스프링 웹 개발 기초
정적 컨텐츠
- 그냥 파일을 그대로 고객(웹 브라우저)에게 전달해주는 것
- PDF 자료 - 정적 컨텐츠 이미지 외울 것
- 첫번째는 컨트롤러를 먼저 찾는다.
- 컨트롤러가 없는 경우 static 폴더의 html을 찾는다.
MVC와 템플릿 엔진
- 서버에서 html을 약간 변형해서 내려주는 것.(jsp, php 등)
- 과거에는 Controller - View 가 분리되어 있지 않았다.
- View에 모든 것을 다했다. jsp 에 모든 것을 다한 것 처럼.(모델1방식)
- 기겁했던 프로젝트, 한 사람이 유지보수, jsp가 수천 라인..
- jsp에서 DB 접근하고 비지니스 로직도 아 있고 그랬어요.
- 내가 유지보수 할까봐 정말 걱정이었습니다.
- 이런 문제 때문에 Controller - View 분리한 것
- 요즘에는 Controller - View 쪼개는게 기본이에요.
- Controller 는 뒷단, View는 앞단만 전문으로 맡아서 하는 것.
- thymeleaf 장점
- html을 그대로 쓰고 서버없이 열어도 껍데기를 볼 수 있어요.
- <p></p> 안의 내용을 치환해서 보여준다.
API
- 만약에 여러분이 안드로이드,아이폰 클라이언트랑 개발해야해요.
- 그러면 서버 입장에서는 요즘에는 html이런 걸 내리는 게 아니라 JSON 데이터 구조 포맷으로 전달해줘요.
- vue나 리액트 이런 것들을 쓸 때도 API 로 데이터만 내려주면 화면은 클라이언트가 알아서 그리는 것.
- @ResponseBody
- HTML을 그 body 태그를 얘기하는게 아니라 HTTP에서 header , body부가 있는데 이 body부에 이 데이터를 직접 넣어주겠다는 뜻입니다.
- return String 하면 view 이런게 없어요. 소스보기해도 html 태그 같은 거 하나도 없죠?
- 그냥 무식하게 문자 그대로 내려집니다.
- 이전 템플릿 엔진은 화면을 뭔가 가지고 view라는 템플릿이 있는 상황에서 조작하는 방식이고
- 이건 그냥 데이터 그대로 내려줍니다.
- 뭐 하려면 할 수 있겠죠. return "<html> hello </html>"
- 이렇게 할 순 있는데 비효율 적이겠죠.
- 진짜는 지금부터입니다.
- 만약에 데이터를 내놓으라고 해요.
- 이것때문에 API 방식을 많이 쓰는데요.
- Hello라는 객체를 하나 만들겠습니다.
- static class Hello
- 이렇게 static로 만들면 이 class 안에서 class를 또 쓸 수 있습니다.
- 자바에서 정식으로 지원하는 문법입니다.
- getter, setter로 만들겠습니다.
- return Hello
- 문자가 아닌 객체를 넘겨 보겠습니다.
- {"name":"spring!!!"}
- 소스보기해도 똑같습니다.
- Json 이라는 방식 검색해보세요.
- key, value로 이뤄진 구조에요.
- 굉장히 단순합니다.
- 요즘에는.. 과거에는 xml 이라는 방식도 많이 쓰였어요.
- 지금 html 태그가 사실 xml 방식으로 쓴거죠.
- 그런데 xml방식은 좀 무겁고.. 열고 닫고 2번 써야하잖아요..
- Json은 name은 value 바로 나오잖아요. 심플해요.
- 예전에는 xml , json 두개가 격돌했어요.
- 근데 요즘에는 거의다 Json 써요. 그래서 여러분도 Json으로 사용하시면 돼요.
- Spring도 객체 반환하고 @ResponseBody라고 하면 Json으로 반환하는게 default로 설정되어 있어요.
- @ResponseBody 동작 방식
- http요청 -> 내장 톰캣 서버 -> Spring -> Contoller -> @ResponseBody -> HttpMessageConverter -> JsonConverter(객체) or StringConverter(문자)
- JsonConverter : 객체면 동작, 객체를 Json 스타일로 바꿔요
- StringConverter : 문자면 동작
- Jackson or Gson : 객체를 Json으로 바꿔주는 유명한 라이브러리
4. 회원 관리 예제 - 백엔드 개발
비즈니스 요구사항 정리
- 일반적인 웹 애플리케이션 계층 구조
- 컨트롤러 : 앞에서 봤던 웹 MVC의 컨트롤러 역할, API 만들 때 컨트롤러 역할
- 서비스 : 이 서비스 클래스의 핵심 비즈니스 로직이 들어가 있는 거예요
- ex ) 회원은 중복가입이 안 된다거나 이런 것들에 대한 로직들
- 리포지토리 : 도메인 객체를 가지고 핵심 비즈니스 로직이 동작하도록 구현한 계층
- 도메인 : 회원, 주문, 쿠폰처럼 DB에 주로 저장되고 관리되는 그 비즈니스 도메인 객체
- 클래스 의존 관계
- interface 사용 이유 나중에 다시 알아보기
- (어떤 DB 사용할지 안 정해졌다는 가정이므로 우선 개발은 해야되니까 메모리 구현체를 사용한다고 함.)
- 나중에 DB가 정해지면 바꿔낄 것. 그러기 위해선 Interface가 필요
회원 도메인과 리포지토리 만들기
// Optional : 자바 8, null 일 수 있는데 이 걸 감싸는 방법[ 람다 ]
루프로 돌면서 찾을 때까지 돈다.
equals = 같은 경우에만 filtering 된다.
findAny로 하나 찾으면 반환,
끝까지 돌렸는데 없으면 Optional에 null로 반환- MemberRepository - interface
- MemoryMemberRepository - implements
회원 리포지토리 테스트 케이스 작성
/*
테스트 순서는 랜덤. 서로 의존적으로 설계하면 안 됩니다.
테스트가 끝나면 repository 지워주는 코드 넣어주죠.
테스트가 실행되고 끝날 때마다 저장소를 다 지워요.
그러면 순서와 상관이 없어지겠죠. 중요한 내용입니다.
(흠 근데 순서 정하는거 나는 해봤는데.. 나중에 찾아보자.)
*/- 테스트만해도 깊은 내용입니다.
- 개발 후 그 다음 테스트 코드 작성
- 이걸 뒤집어서 테스트 코드를 작성하고 개발을 할 수도 있어요.
- 뭘 만들 때 별 모양 작품 만들 때 미리 별 틀을 만들고
- 작품 만들 때 이게 꽂히는지 안꽂히는지 확인하는 거예요.
- 이걸 테스트 주도 개발이라고 합니다.(=TDD)
- 테스트없이 개발하는 건 불가능, 정말 문제가 많이 생깁니다. 깊이 공부하세요.
회원 서비스 개발
- 회원 repository, domain 을 활용해서 실제 비지니스 로직을 작성한는 쪽
- Optional.ifPresent
- Optional.orElseGet
- 뭔가 findByName 으로 로직이 쭉 나오죠, 이런 경우에는 메소드로 뽑는게 좋습니다.
- repository는 save, findById 처럼 뭔가 단순히 저장소에 넣어다 뺐다 하는 느낌이 들죠.
- 근데 Service는 join, findMembers 뭔가 느낌이 비즈니스에 가깝죠.
- 보통 Service 는 비즈니스에서 갖고온 용어를 써야해요.
- 그래야 개발자,기획자든 갑자기 "기획자가 회원 가입쪽 이상해요" 라고하면
- "ok join쪽 살펴보자"라고 매핑이 돼요.
회원 서비스 테스트
- 회원 서비스를 테스트해보겠습니다.
- 테스트는 사실 과감하게 한글로 바꾸셔도 됩니다.
- 뭔가 프로덕션 코드가 나가는 거는 실제 테스트 코드가 아닌 나머지 코드는 한글로 적는게 애매한데 테스트는 영어권 사람들과 일하는 게 아니면 한글로도 많이 적습니다.
- 빌드 될 때 테스트 코드는 실제 코드에 포함되지 않아요.
- given, when, then 패턴을 사용해라.
- given : 이런 상황이 주어졌는데
- when : 이걸 실행했을 때
- then : 결과가 이렇게 나와야돼.
- 대부분 테스트는 이렇게 구분돼요.
- 테스트가 작을 땐 잘 몰라도 테스트가 길 때는 이렇게 구분되었을 때 직관적으로 알 수 있어요.
- 물론 상황에 따라서 안 맞는 경우도 맞지만 기본으로 사용하면 좋습니다.
- 테스트는 정상 플로우도 중요하지만 예외 플로우가 훨씬 중요합니다.
- ex) 회원 가입 같은 경우 중복 회원 검증 로직을 잘타서 예외가 터지는 것을 확인해야 합니다.
- assertThrows 사용
- try catch 문법도 좋지만 번거롭습니다.
assertThrows(IllegalStateException.class, () -> memberService.join(member2));- 해석 => MemberService.join(member2) 로직을 태울 때
- IllegalStateException.class 이 예외가 터져야 돼.
- isEqualsTo 사용해서 메세지 검증도 가능합니다.
- 첫번째 테스트가 두번째 테스트에 영향이 있으면 안 됩니다.
- 모든 테스트는 독립적이 되어야 해요
- 메모리 DB에 누적되는 것을 막아야 해요.
- Clear를 해줘야 합니다.
- public void afterEach(){ memberRepository.clearStore(); }
- 그런데 여러분 조금 애매한게 있어요
- MemberService에 있는 MemberRepository는 new로 만든 다른 객체입니다.
- Test 도 new 로 만든 다른 객체에요.
- 좀.. 이거를 두개를 쓸 이유가 없잖아요. 같은 걸 쓰는 게 낫겠죠.
- static으로 되어 있어서 지금 크게 상관 없는데
- new로 다른 인스턴스가 생성되면 내용물이 달라질 수 있죠.
- 바꾸시는 게 좋습니다.
//DI 방식 이전에 사용했던 소스
// private final MemberRepository memberRepository = new MemoryMemberRepository();
//DI 방식으로 변경 후 사용하는 소스
private final MemberRepository memberRepository;
//외부에서 주입하는 방식
// @Autowired
public MemberService(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}- 이것이 바로 DI입니다.
5. 스프링 빈과 의존관계
컴포넌트 스캔과 자동 의존관계 설정
- 스프링 빈을 등록하고 의존 관계를 어떻게 설정하는지 알아보겠습니다.
- 컨트롤러는 서비스를 통해 회원 가입하고 데이터를 조회할 수 있어야 한다.
- = 의존관계가 있다. = 컨트롤러가 서비스를 의존한다.
- @Controller
- 스프링 처음 뜰 때 스프링 컨테이너라는 통이 생깁니다.
- 거기에 이 컨트롤러 객체를 생성해서 스프링에 넣고 관리합니다.
- = 스프링 컨테이너에서 빈(Bean)이 관리된다.
- @Autowired, @Service, @Repository
- new MemberService() 이렇게 선언할 수도 있지만 문제가 있습니다.
- 스프링이 관리하면 다 컨테이너에 등록하고 받아서 쓰도록 바꿔야 해요.
- 여러 컨트롤러 (주문 컨트롤러 등)에서 사용할 때 이 별 기능도 없는 걸 여러번 생성할 필요가 없어요.
- 그냥 하나만 생성해서 공유해서 쓰면 되거든요.
- 컨테이너에 등록하고 쓰면 부가적인 기능도 많이 쓸 수 있어요.
- 생성사를 생성하고 @Autowired를 선언합니다.
- 컨트롤러가 스프링 컨테이너가 뜰 때 생성한다고 했잖아요
- 그러면 생성자도 호출을 하거든요
- Autowired는 서비스를 스프링이 스프링 컨테이너에 있는 서비스를 가져다 연결해줍니다.
- 그런데 잘 실행이 안 되는 것 같죠.
- Error : required a bean of type '~Service' that could not be found
- 서비스에 가보시면 순수 java class 입니다.
- 스프링이 얘를 알 수 있는 방법이 없습니다.
- 즉 서비스에 @Service 를 선언해주어야 합니다.
- 스프링이 올라올 때 서비스를 등록해줍니다.
- 리포지토리에도 @Repository로 선언을 합니다.
- new MemberService() 이렇게 선언할 수도 있지만 문제가 있습니다.
- 컨트롤러 생성이 될 때 스프링에 등록되어있는 서비스 객체를 가져다 넣어줍니다.
- 이것이 바로 DI(=Dependency Injection)!!!
- 컴포넌트 스캔 방식 ( = @Cotroller, @Service, @Repository 등)
- 컨트롤러가 스프링 빈으로 자동 등록된 이유도 컴포넌트 스캔 때문이다.
- @Service 안으로 들어가면 @Component라고 붙어있다.
- 스프링이 딱 오라올 때 컴포넌트 관련 어노테이션이 있으면 객체를 하나씩 생성해서스프링 컨테이너에 등록을 해요
- 자동 의존관계 설정
- @Autowired는 컨테이너에 등록된 객체들의 연관관계를 연결 해줍니다.
- 이것을 자동 의존관계 설정이라고 합니다.
- 자바 코드로 직접 스프링 빈 등록하기
- 좀 이따 설명드릴게요.
- 아무데나 @ 선언하면 되나요? -> 안됩니다.
- HelloSpringAppication 이 포함된 패키지 하위에서만 적용됩니다.
- 스프링은 스프링 컨테이너에 스프링 빈을 등록할 때, 기본으로 싱글톤으로 등록한다.(유일하게 하나만 등록해서 공유한다.) 따라서 같은 스프링 빈이면 모두 같은 인스턴스다. 설정으로 싱글톤이 아니게 설정할 수 있지만 특별한 경우를 제외하면 대부분 싱글톤을 사용한다.
- ex) 오더 서비스에서 Autowired로 Member 리포지토리 내놓으라고 하면 똑같은 인스턴스를 넣어줍니다.
- 그럼 메모리도 절약되고 좋겠죠.
자바 코드로 직접 스프링 빈 등록하기
- 제가 하나하나 직접 스프링한테 등록하는 방법을 알려드릴게요.
- 스프링아 너는 이제부터 이걸 스프링 빈에 등록해줘
- @Configuration
- 스프링 설정 파일임을 선언
- @Bean
- 스프링 빈을 등록할거야
- @Controller는 스프링이 관리하는 거기 때문에 그냥 냅둬라.
- 어노테이션 통한 자동 등록 or 직접 스프링 빈 등록 장단점
- 1. 과거엔 xml 문서로 설정
- 지금은 거의 자바 코드에서 설정, 이건 생략
- 2. DI
- 생성자 주입
- 요즘 권장하는 스타일
- 처음 조립되는 시점에 한번 들어오고 끝난다.
- 생성하는 시점에 넣고 변경을 못하도록 막아버릴 수 있다.
- 필드 주입
- 별로 안 좋다, 중간에 바꿀 수 있는 방법이 없다.
- setter 주입
- =setxxxx, 누군가 호출했을 때 public으로 열려 있어야 한다.
- 잘못 바꾸면 문제가 생기겠죠, 한번 세팅되면 잘 바꿀 일이 없어요
- 아무 개발자나 호출할 수 있게 열려있는 거예요.
- 결론은 생성자 주입을 쓰는 게 좋습니다.
- (뭐지 생성자도 public인데 setter랑 다른 건가? 나중에 알아보자.)
- 생성자 주입
- 3. 실무에선 주로 정형화된 컨트롤러 서비스, 리포지토리 같은 코드는 컴포넌트 스캔을 사용
- 정형화 되지 않거나 상황에 따라 구현 클래스를 변경해야 하면 설정을 통해 스프링 빈으로 등록한다.
- ex) 지금 우리가 하는 db가 정해지지 않았다는 가정하에 메모리를 만들고 교체
- 다른 리포지토리로 바꿔치기 할 거예요. 기존의 운영중인 코드를 하나도 손대지 않고 바꿀 수 있어요.
- 구현체를 바꿔야 겠죠, 그러면 상황에 따라 구현 클래스를 바꿔야 하는 경우가 맞죠
- 컴포넌트 스캔을 사용하면 막 여러코드를 바꿔야 합니다.
- 얘는 그렇게 할 필요 없어요. 설정 파일만 바꾸면 됩니다.
- 정형화 되지 않거나 상황에 따라 구현 클래스를 변경해야 하면 설정을 통해 스프링 빈으로 등록한다.
- 4. @Autowired를 통한 DI는 helloController, MemberService 등과 같이 스프링이 관리하는 객체에서만 동작한다.
- 스프링 빈으로 등록하지 않고 내가 직접 생성한 객체에서는 동작하지 않는다.
- 스프링 컨테이너, DI 관련된 자세한 내용은 스프링 핵심 원리 강의에서 설명한다.
- 1. 과거엔 xml 문서로 설정
6. 회원 관리 예제 - 웹 MVC 개발
회원 웹 기능 - 홈 화면 추가
- 회원관리 예제를 웹 MVC로 개발해보겠습니다.
- 아주 단순한 회원 등록하고 조회할 수 있는 버튼(링크)이 있는 사이트를 만들어 보겠습니다.
- 정적 컨텐츠 설명할 때 뭘 얘기한건데 먼저 요청이 오면 스프링 컨테이너에 매핑된 컨트롤러를 찾고 없으면 static 파일을 찾습니다.
- 매핑된 컨트롤러가 있다면 static 파일은 무시됩니다.
- HomeController, home.html 작성
회원 웹 기능 - 등록
- 회원 웹 기능 등록을 해볼게요.
- createMemberForm.html 작성
- 작동 원리
- 회원 가입을 들어갑니다.
- members/new로 들어가서 url에 치면 get방식이라 하는데 그냥 이렇게 들어옵니다.
- 그리고 아무것도 하는 거 없이 createMemberForm으로 이동합니다.
- return하면 templates에서 찾는다고 했죠. viewResolver가 html을 실행시킵니다.
- 그냥 지금은 html이 뿌려집니다.
- 여기서 뿌려질 때 Form이라는 tag가 있죠, 얘는 값을 입력할 수 있는 tag에요.
- 여기서 method post로 되어 있고, input tag가 있죠
- 등록 버튼을 누르면 무슨 일이 생기냐
- form action 으로 넘어갑니다.
- PostMapping 은 보통 데이터를 뭔가 Form 같으네 넣어서 전달할 때 쓰고요
- 보통 데이터를 등록할 땐 Post를 씁니다. 조회할 떈 Get을 씁니다.
- 여기서 재밌는 건 MemberForm이 있죠, 여기 name이 있죠, 이 name에 아까 input tag name에 넣어준 값이 들어갑니다.
- 스프링이 SetXXXX를 통해서 값을 넣어주는 것입니다.
- 회원 가입을 들어갑니다.
회원 웹 기능 - 조회
회원 웹 기능 조회를 만들어보겠습니다.
7. 스프링 DB 접근 기술
H2 데이터베이스 설치
- 가볍고 심플한 H2 데이터베이스를 설치해보겠습니다.
- test.mv.db 파일 있는지 확인
- H2접속, create, select, insert 쿼리 실행
- java에선 Long, DB에선 Bigint
- SQL : generated by default as identity
- 값을 세팅하지 않고(=null) insert하면 db가 자동으로 값을 채워준다.
순수 JDBC
- 이제 진짜 DB에 연동을 해서 DB에 쿼리를 날려서 넣고 빼는 걸 해보겠습니다.
- 그것도 고대 20년전 방식으로 해보겠습니다.
- 여러분들 정신 건강을 위해 이번 강의는 편하게 들으세요.
- build.gradle에 jdbc, H2 데이터베이스 관련 라이브러리 추가
- spring-boot-starter-jdbc : DB와 붙을 때 꼭 필요한 jdbc 드라이버
- h2database:h2 : H2 클라이언트
- DB 접속 정보
- 옛날에는 개발자가 어렵게 설정했습니다
- 지금은 스프링 부트가 다 넣어줍니다.
- application.properties에 작성
- 구현체 JdbcMemberRepository 클래스 생성
- DataSource : Spring한테 주입 받고 getConnection()하면 DB connection을 얻을 수 있어요. 간단하죠?
- 하지만 코딩이 어마어마 합니다.
- RETURN_GENERATER_KEYS, pstmsm.getGeneratedKeys();
- 컬럼에 generated by default as identity 옵션 걸면 자동 AutoIncrement 기능 사용할 수 있다.
- connection을 해주면 항상 close를 해주어야 합니다.
- 복잡한데 역순으로 resultset close 하고 pstmtm close 하고 conn close하고 해야합니다.
- 복잡하구나 정도만 알고 넘어가시면 됩니다.
- Configuration 수정
- 지금부터 기가 막힌 걸 보여드리겠습니다.
- 전 아무것도 손대지 않았어요. JDBCMemberRepository클래스를 만들고 인터페이스를 구현체를 만들어서 확장하고
- Spring이 제공하는 Configuraion만 딱 손댔어요.
- 중요한 얘기는 이 얘기에요.
- 우리가 스프링을 왜 쓰냐. 이것때문이에요.
- 객체 지향 설계가 왜 좋냐면. 이걸 다형성이라고 하거든요.
- 스프링은 이걸 편리하게 하도록 쓸 수 있는 거예요.
- 과거엔 MemberService 코드를 수정해야 한다.
- 인터페이스가 있으면 Config만 수정하면 됩니다.
- SOLID 검색해보세요.
- 개방 폐쇄 원칙 : OCP (Open-Closed Principle)
- 확장에는 열려 있고 변경에는 닫혀 있다
- (기능을 변경해도) (코드를 수정할 필요 없다.)
스프링 통합 테스트
- 이번에는 테스트도 DB까지 실제 연결해서 동작하는 통합테스트를 한번 보여드리겠습니다.
- 예전에 짰던 테스트 코드는 순수 자바 코드로 짠 것.
- 지금부터는 순수 자바 코드로 짤 수가 없다. 왜냐하면 DB 접속 정보도 스프링 부트가 들고 있고 그러니까.
- 그래서 이제부터는 테스트를 스프링이랑 엮어서 해보겠습니다.
- 지금 MemberServiceTest는 엄청 빨리 실행되죠? 이건 메모리 자바 JVM안에서 끝나는 거예요.
- 자 그럼 이제 DB까지 연결하는 테스트를 만들어 볼게요.
- @SpringBootTest, @Transactional
- 이제는 컨테이너한테 멤버 서비스, 멤버 리포지토리 내놔 해야돼요.
- 테스트는 제일 끝단에 있는 거니까 제일 편한 방법으로 하시면 됩니다.
- @Autowired 를 많이 씁니다.
- DB 데이터를 지운 상태에서 해줘야 합니다.
- 보통 테스트 전용 DB를 구축합니다.
- 테스트는 반복할 수 있어야 합니다.
- 또 BeforeEach 해서 deleteAll 이런거 만들어서 지워야 하냐? 번거롭죠.
- 이제 스프링이 기가 막힌 걸 제공합니다.
- DB는 기본적으로 트랜잭션이란게 있어요.
- DB는 원래 commit이라는 걸 해줘야 반영이 돼요. autoCommit이란 것도 있고.
- 테스트 끝나고 rollBack해버리면?
- 방법이 바로 있습니다. @Transactional
- 이걸 테스트 케이스에 달면 테스트 실행 전 트랜잭션을 실행하고
- DB데이터를 다 한다음에 테스트 끝나면 rollBack을 해줘요.
- 그래서 DB에 있는 데이터가 반영이 안되고 다 지워집니다.
- 그러므로 다음 테스트에 영향을 주지 않습니다.
- @SpringBootTest : 스프링 컨테이너와 테스트를 함께 실행한다.
- 엇 그럼 순수 자바로된 테스트는 필요 없지 않나요?
- 아닙니다. 단위 테스트로 사용이 되요. 정말 빠릅니다.
- 통합 테스트는 느려요. (테스트 케이스가 많아지면 차이가 심합니다.)
- 가능하면 순수한 단위 테스트가 훨씬 좋을 수 있는 확률이 높습니다.
- 단위 단위로 쪼개서 테스트를 잘 할 수 있도록 하고
- 스프링 컨테이너 없이 테스트 하도록 훈련해야 해요.
- 컨테이너까지 어쩔 수 없이 올려야 되는 상황이면 테스트 설계가
- 잘못됐을 가능성이 있어요. 물론 살다보면 통합 테스트도 할 일이 있어요.
스프링 JdbcTemplate
- 네, 이번 시간에는 스프링 JdbcTemplate에 대해 알아보겠습니다.
- 우선 설정은 저희 스프링 기존에 우리 보면 s
- JdbcTemplate, MyBatis 같은 라이브러리는 JDBC API에서 어떤 반복적인 코드를 제거해준다.
- ResultSet 커넥션 얻고 이런 것들
후기
면접 과정에서 스프링 기초가 부족하다는 것을 느껴 강의를 찾고 있었다.
마침 인프런에서 김영한님의 스프링 입문 강의가 무료라서 들어봤다.
기간은 3.30일부터 틈틈히 들었고 3주 정도 걸렸다.
한 영상당 3~5회는 봤다.
1회는 그냥 보기, 2회는 코드 작성하며 보기, 3회는 블로그 정리하며 보기.
이해 안 되는 곳은 다시 볼려보기.
말씀하시는 한 단어도 놓치지 않기 위해 봤다.
말씀해주시는 설명이나 예시들이 초보자들이 쉽게 이해할 수 있도록 설명해주셔서
나중에 내가 다른 사람에게 알려줄 때 유용할 것으로 생각된다.
인터넷 강의를 끝까지 집중해서 본적이 별로 없는데 이번 강의는 완강했다.
인프런 강의의 좋은 점이 목차별로 강의를 나눠서 강의 시간이 짧아
필요한 부분을 다시 찾아보는 것이 편리하다는 점이다.
그리고 강의 하나 하나가 금방 끝나니 성취감도 높다.
앞으로 인프런 강의나 김영한님 강의는 유료, 무료 상관없이 꾸준히 찾아서 들을 것 같다.
끝으로 귀한 영상을 무료로 제공해준 인프런과 김영한님께 감사드립니다.
