Spring

객체지향의 원칙알고 보면 좋다. 스프링의 역할 완벽한 OCP, DIP를 수행하기는 쉽지 않다. 수업을 따라오면서 지금까지 작성한 코드는 다음과 같다. 서비스 = Member, Order, Grade 도메인 = MemberServiceImpl, OrderServic

지금까지 계속 사용하던 방법이다 생성자를 통해서 주입받는다. 생성자 호출시점에 1회 호출되는것을 보장한다따라서 불변하는 것들에 많이 사용된다. 특징선택 변경 가능성이 있는필드에 사용 가능 주입동작이 없어서 Autowired를 작동하게 하려면 Autowired(requi

autowired는 처음에 타입 매칭을 시도하고, 이 때 빈이 여러 개 있다면 필드 이름, 파라미터 이름으로 빈을 추가 매칭한다. 따라서 이름을 바꿔서 구분해주면 해결된다.@Qualifier를 통해서 구분을 해준다.클래스빈에 특별한 이름을 부여해주고 인수에 넣어주면 이

대부분의 스프링 어플리케이션은 웹 어플리케이션이다. 그 밖에것도 가능하다. 웹 어플리케이션에서는 보통 여러 고객이 동시에 요청을 한다. 예를 들어, A B C 고객이 동시에 memberService를 요청한다고 하자. 그러면 DI컨테이너 (AppConfig)는 new

기존의 AppConfig에서 Bean 등록을 할때는 Bean Annotation을 붙여서 해결했다. 만약 이 빈이 5만개 있다면, 그걸 하나씩 다 등록하기에는 너무 귀찮고 관리도 어려울것이다.그래서 나온게 컴포넌트 스캔이다.자동으로 Component라는 Annotati

객체를 전부 생성 -> 의존관계 주입 물론 생성자 주입은 예외적으로 만들때 관계가 같이 들어온다 스프링 컨테이너 생성 -> 스프링 빈 생성(생성자의 경우 이단계에서 의존관계도 주입) -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료 생

스프링 컨테이너 생성 동시에 빈이 생성되고 스프링 컨테이너 종료까지 그 생명을 유지한다. 싱글톤 : 기본 스코프. 컨테이너와 수명을 공유하는 가장 긴 스코프.프로토타입 : 프로토타입 빈의 생성과 DI까지만 관계하고, 그 뒤는 더 이상 관리하지 않는다. 웹 관련 스코프

서블릿이란 자바를 사용하여 웹을 만들때 사용하는 기술이다. 쉽게 말하면 클라이언트의 request에 대한 response를 전달해주는것이다. Request가 ServletContainer로 이동시킨다컨테이너가 HttpServletRequest, Response를 생성한

하나의 서블릿이나 JSP만으로 비즈니스 로직, 뷰, 렌더링까지 전부 처리하게 되면 너무 많은 역할이 주어지게 되고, 유지보수가 어려워진다. 따라서 이를 해결하기위해 MVC패턴을 사용한다.이미지 출처(https://ko.wikipedia.org/wiki/%EB%

단계별로 MVC를 발달시켜서 왜 현 스프링 MVC가 만들어졌는지 이해해보겠다.이전글에서도 봤지만, 공통로직 (response, request 처리)같은 경우 모든 Controller에 전부 들어가게 되었다. 따라서 이를 공통적으로 처리해줄 컨트롤러가 요구되게 되었고,

지금까지 만든 버전은 설계적으로는 훌륭한 프레임워크지만, 사용이 불편하다는 단점이 있다. 만들때마다 모델뷰를 만들고 넘기고 하는 불편함이 있다.이를 개선하는 버전이 필요하다기존버전에서 Model을 만들어서 넘겼던것과 다르게, 이번 버전에서는 Model을 그냥 인자로 만

이전 글들에서 MVC를 손수 만들었었는데, 이는 결국 스프링 내장 MVC와 매우 유사한 구조이다. 간단한 구조 비교 DispatchServlet DispatchServlet은 부모클래스 FrameworkServlet(HttpServlet)을 상속해서 사용한다. 스프

가장 기본적인 컨트롤러 매핑이다.이런식으로 어노테이션을 사용하면 GET, POST로 메서드가 왔을때만 돌리게 설정할 수 있다. 이런식으로 데이터, 미디어 타입을 따로 지정해줄수도 있다. URL 매핑 예시 위와 같은 API가 있다고 하자. 이를 매핑하는 예시는 다음과 같

예) 웹 브라우저에 정적인 HTML, css, js을 제공할 때는, 정적 리소스를 사용한다.예) 웹 브라우저에 동적인 HTML을 제공할 때는 뷰 템플릿을 사용한다.HTTP API를 제공하는 경우에는 HTML이 아니라 데이터를 전달해야 하므로, HTTP 메시지 바디에

GET 으로 상품등록 Form을 가져옴등록버튼을 누르면 POST로 저장이 되고, 상품 상세 뷰가 호출된다. 웹브라우저 입장에서는 내가 마지막에 POST ADD를 요청한것이 되는것이다. 이 때, 새로고침을 누르면, 마지막에 내가 요청한 POST가 다시 호출되고, 등록이

이 두 어노테이션은 스프링에서 아주 자주 사용되는 어노테이션들이다. 한번 정리하고 넘어가자. @RequestParam 리퀘스트 파람 어노테이션은,

TimeLeap이 아니라 Thymeleaf이다. 타임리프 특징 서버사이드에서 HTML을 동적으로 렌더링하는 용도로 사용되는데, 서버사이드 랜더링 기술중 하나이다. 네추럴 템플릿 타임리프틑 순수 HTML을 최대한 유지한다. 타임리프로 작성한 파일은 HTML을 유지하기

프로젝트에서 다양한 언어를 지원하려고 하면 어떤 방식을 취해야할까?가장 간단하게 생각하면 HTML에 있는 메시지들을 전부 영어나 다른 언어로 고치는것을 생각해볼 수 도 있다. 하지만 이건 매우 비효율적이고 오류발생 가능성도 높다. 따라서 이를 통합 관리하는 messag

Validation은 엄청 중요한 기능중의 하나이다. 예를 들어, 가격 수량에 문자가 들어오면 안되는데 들어온다던가, 상품명이 지원하지 않는 포멧을 가지고 있다던가 글자수 제한을 넘긴다던가 하는 validation이 존재할 것이고 이를 지켜야 사이트 오류를 막을 수 있

Bean Validation이란? 기존의 검증방법은 사실 코드를 일일히 작성해야하는 불편함 이 있었다. 하지만 대부분의 검증은 해당 값이 비어있다거나, 타입이 다르다거나, 범위설정의 문제이다. 따라서 이를 편하게 해결해주기 위해 어노테이션으로 검증을 처리하는 bean

로그인 화면로그인 성공 전용 화면로그인 된 사용자만이 수정 가능웹 기술이 바뀌더라도, 도메인은 살아있어도록 설계를 해야한다. 따라서 웹은 도메인에 의존해도, 도메인은 웹에 의존하지 않도록 설계를 해야한다. 멤버 객체나 맴버 리포지토리는 구현되어 있다는 가정 하에 진행하

세션을 직접 만들어보고 사용하는것으로 세션을 이해할 수 있을것이다.세션의 주요기능은 다음과 같다.세션 생성sessionId 생성 (임의의 추정 불가능한 랜덤 값)세션 저장소에 sessionId와 보관할 값 저장sessionId로 응답 쿠키를 생성해서 클라이언트에 전달세

로그인 상태에서만 처리할 수 있는 기능들의 컨트롤러에는 전부 로그인 체크 여부를 집어넣어야한다. 하지만 이런 방식은 실수가 생길 가능성도 높아지며, 유지보수가 어려워진다. 이런 모든 컨트롤러가 관심을 가져야하는 사항을 공통 관심사라고 한다.이런 공통관심사는 AOP를 통

웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 만약, 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까?WAS까지 예외가 올라온 경우, WAS가 어떤 방식으로 처리하는지 알아봐야한다

API오류는 각 오류상황에 맞는 응답스펙을 정하고, JSON 데이터를 내주어야한다. 이러한 코드에서는 기존에 설정해둔 ErrorPage정보때문에 html이 반환이 된다. 따라서 Controller에서 JSON을 반환할 수 있도록 처리해야한다. 이런식으로 API오류를 보

RestController를 개발하다보면, 종종 method 반환을 responseEntity<>로 하는 코드들을 볼 수 있다. Spring Framework에서는 HttpEntity라는 클래스를 제공한다. 이 zmffotmsms HttpHeader, HttpBo

문자의 변환 URL경로는 항상 문자이다. parameter로 data=10이 들어온다면, 이는 String형태이고, 이를 숫자로 받으려면 유저가 내부에서 변환을 해야한다. 혹은 RequestParam으로 변환할 수도 있다. 이는 스프링이 컨버터 기능을 지원해서 자