Spring

탄생 배경2000년대 초 EJB(Enterprise Java Beans)의 문제점이 많았음2002년 로드 존슨의 책을 통해 EJB 없이도 고품질의 Application을 만들 수 있다는 것을 보여줌책 출간 후 유겐 휠러, 얀 카로프는 로드 존슨에게 오픈소스 프로젝트 제

UsernamePasswordAuthenticationFilter Id와 paswword를 사용하는 form 기반 인증 Spring에서는 Post 기반 /login 으로 요청오면 이 filter가 실행 되도록 defult 처리 되어있음 AuthenticationMa

기존의 방식하나의 서블릿이나 JSP 만으로 비즈니스 로직, 뷰 렌더링과 같은 기능을 모두 처리.SO,유지보서성의 어려움 ( ex) 한 HTML파일에 수천 줄의 자바 코드 ㅠ)코드 수정 시, 해당 사항이 없는 부분도 같이 수정해야할 수도 있음. 즉, View나 비즈니스

1\. @RestController Annotation활용@Controller와 다른 점?@Controller는 반환 값이 String이면 뷰 이름으로 인식하고 뷰로 렌더링!반면, @RestController는 반환 값으로 HTTP MESSAGE BODY에 바로 입력2

Member를 등록하는 Controller가 있다고 생각 해 봅시다.Member를 등록하고 나서 등록된 Member를 Model에 담습니다.다른 View로 Forward!코드를 먼저 보시져가정된 상황과 똑같은 형태라고 보시면 될 것 같습니다!!MemberServiceC

서버 사이드 렌더링을 위해 (Server Side Randering)백엔드 서버에서 HTML을 동적응로 렌더링 하는 용도Natural TemplateHTML을 최대한 유지 가능. 웹 브라우저에 동적으로 렌더링 된 HTML 파일을 직접 열어보면 HTML태그들만 존재.반면

웹 페이지의 화면을 구성 할 때는 공통 영역이 많을 것.그렇다면, 여기서 생각을 해보자!공통적인 부분에서의 수정이 필요하다면 ??? 여러 HTML 파일들을 다 수정해야 된다는 이야기혹시라도 HTML파일이 수 백개라면?? 생각만 해도 끔찍!그래서, Thymeleaf는 공

메시지화면에 보이는 문구를 수정해야하는 상황을 생각 해 봅시다.물론, 화면이 별로 없거나 바꿔야할 부분이 공통딘 부분이 많이 없다면?? 별로 어려운 이야기는 아닐 것 입니다.하지만, 화면이 막 수백 개 되어 버리는데 바꿔야 할 공통 부분이 화면마다 다 있으면?? 이야말

HTTP는 무상태(stateless) 프로토콜( protocol)수 만명의 회원 정보를 연결 상태를 유지 한다면 엄청난 과부화가 걸릴 것입니다. 그리하여 서버가 응답을 보낸 후 Client와 Server의 연결을 끊게 됩니다. 물론 무수히 많은 요청을 처리할 수 있기에

Servlet Filter 보다는 Spring Interceptor에 무게를 더 두겠습니다!특정한 페이지 말고는 로그인을 한 사용자만 페이지를 볼 수 있는 권한이 있다고 가정생각 가능한 시나리오컨트롤러들 마다 로그인 여부를 체크 : 굉장히 번거롭고, 로직을 수정해야할

회원 가입의 경우를 생각 해 봅시다.나이를 문자로 작성을 하거나 형식에 맞지 않는 데이터를 입력시, 바로 그냥 오류 페이지가 나오거나 예외 페이지로 이동 해 버린다면 어떨까요??사용자는 '아 씨, 이거 뭐야' 이럴 것입니다.그리하여 저희가 제공하는 웹 서비스는 저러한

Validation이 왜 필요하고 무엇인지 아시고 싶으신 분은??? 이쪽으로 ㅎvalidation을 만들기 위해서 매번 코드를 작성하고, 메시지 코드를 만들고 이러기엔 번거로움이 따를 것 입니다.생각해 보면 validation 처리를 할 때, 뭐 NUll이면 안된다든지

웹 어플리케이션에서의 예외웹 어플리케이션은 사용자 요청별 별도의 쓰레드가 할당 되며, 서블릿 컨테이너 안에서 실행.예외가 발생하게 되면??웹 어플리케이션 내에서의 별도의 처리가 없다면, 서블릿 밖으로 까지 예외가 전달즉, Controller에서 발생한 예외가 톰캣 같은

🎯 API 예외 처리 예외 처리와 오류페이지가 궁금하시다면! 🙋‍♀️ 단순히 에러 및 오류가 났을 때는 BasicErrorController가 제공하는 기능을 사용하여 사용자에게 해당 번호대 오류 페이지를 보여주기만 하면 되었습니다. 하지만 API의 경우 사용자

스프링은 자바를 기반으로 한 기술!자바에서 가장 중요하게 가치를 두는 것은 객체지향So, 스프링이 가장 관심을 많이 두는 대상은 오브젝트 입니다.스프링을 이해하려면 먼저 오브젝트에 깊은 관심을 가져야 하며, 애플리케이션에서 오브젝트가 생성되고다른 오브젝트와 관계를 맺고

Version 1. 에서의 코드를 보시면 한 가지 클래스내에 데이터베이스에 접근하는 메소드와 데이터베이스를 이용하여 비즈니스 로직을 담당하고 있는 메소드가 있습니다.이 둘의 관심사를 repository 와 service로 분리시켜 봅시다.어떻게 할까요??!상속을 통한

인터페이스의 도입두 개의 클래스가 서로 긴밀하게 연결되어 있지 않도록 자바가 추상화를 위해 제공하는 가장 유용한 도구오브젝트를 만드려면 구체적인 클래스 하나를 선택해야겠지만 접근하는 쪽에서는 오브젝트를 만들 때 사용할 클래스가 무엇인지 몰라도 됨.인터페이스는 어떤 일을

코드를 개선해온 결과를 객체지향 기술의 여러 가지 이론을 통해 알아봅시다.개방 폐쇄 원칙 (OCP, Open-Closed Principle)'클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.'service에서 repository의 기능은 언제든지

스프링의 핵심을 담당하는 것은 빈 팩토리 또는 애플리케이션 컨텍스트라고 불리는 것입니다. 한번 알아보죠~!스프링 빈스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈이라고 부릅니다. 또한, 스프링 컨테이너가 생성과 관계설정, 사용들을 제어해

자바에서는 두 개의 오브젝트가 완전히 같은 동일한 오브젝트라 말하는 것과, 동일한 정보를 담고있는 오브젝트라고 말하는 것은 분명한 차이가 있습니다.전자는 동일성비교라고 하고, 후자를 동등성 비교라고 합니다.동일성두 개의 오브젝트가 동일하다면 사실은 하나의 오브젝트만 존

의존관계란 무엇일까요??두 개의 클래스 또는 모듈이 의존관계에 있다고 말할 때는 항상 방향성을 부여해야합니다.즉, 누가 누구에게 의존하는 관계에 있다는 식이어야 합니다.ex) A 클래스 -> B 클래스 라는 의존관계가 있다고 생각해봅시다.여기서는 B가 변하면 A에게 영

JUnit의 기능보다는 테스트 주도 개발 방법론에 초점을 맞추겠습니다.service가 repository를 의존하고 있는 형태의 코드를 활용하여 설명 하겠습니다.service와 repository의 코드는 밑과 같습니다.User.javaUserRepository.ja

📌 먼저, 다음의 코드를 기반으로 점차적으로 발전시켜 나가보겠습니다. User.Java(Domain)UserDao.javaUserDaoImpl.javaUserService.javaUserServiceImpl.javaAppConfig.java먼저, UserService