기존 Express 서버를 지속적으로 개발해가면서 스프링부트에도 많은 관심을 갖고 있었다. 코딩테스트에서만 사용하던 자바, 스프링에서 사용되는 언어의 불친절함(Bean, IoC, Container, 여러 annotation...) 으로 인해 API 서버는 노드로 선택했
다양한 패턴들 중 처음으로 작성할 포스팅은 싱글톤 패턴에 관해서이다. 스프링을 주제로 삼고 있지만, 객체지양언어에서 아키텍처와 패턴은 빼놓을 수 없기에 고민 끝에 여기에 작성해보고자 한다. 싱글톤 패턴은 가장 유명한 패턴들 중 하나로, 디자인 패턴을 따로 공부하지 않
참조
앞선 포스팅에서 언급한바와 같이 스프링은 Tomcat 웹 서버를 내장하고 있다.Tomcat 은 서블릿 컨테이너 역할도 함께 사용하고 있고, 우리는 비즈니스 로직에 좀 더 집중한 설계를 할 수 있게 된다. 스프링 부트는 스프링을 한번 더 감싼 것으로 언급이 많이 되어
원래 처음 소개했어야 하는데 토비의 스프링 도서를 늦게 완독한 관계로 6번째에서 소개한다.스프링의 정의는 자바 엔터프라이즈 개발을 편하게 해주는 오픈 소스 경량급 애플리케이션 프레임워크이다. 따라서 스프링 프레임워크(Spring Framework)가 더 정확한 표현이다
MVC 패턴은 Model, View, Controller로 구성되어 역할들을 분리하여 개발이 용이하도록 하는 디자인 패턴이라고 설명하였었다.스프링(Spring) 또한 웹 애플리케이션을 개발할 때 기본적으로 MVC 패턴을 바탕으로 개발한다. 어떻게 보면 Model, Vi
앞선 포스팅에서 빈을 @configure에서 등록해서 스프링컨테이너(어플리케이션 컨테이너) 에서 싱글톤으로 관리한다는 것을 소개했다. 스프링 컨테이너에 빈을 등록하면 스프링 컨테이너가 알아서 의존관계를 맺어준다. 그런데 의존관계를 맺어줄 때 해당하는 타입의 빈이 2개
서론 지난 포스팅에서 인터페이스 구체화 클래스들의 명시적 사용에 대해서 알아보았다. 만일 이 모든 구현체들을 전부 사용해야 할 때는 어떻게 활용하면 좋을지 이번 포스팅에서 기록해보고자 한다. 결론적으로 Map, List와 같은 1급 컬렉션 클래스 처럼 활용하는 방법이
스프링 컨테이너에 빈(Bean)을 등록하면 기본적으로 싱글톤 패턴으로 빈을 관리하게 된다. 따라서 해당 빈을 요청하게 되면 항상 동일한 빈을 반환해주는 것을 확인할 수 있다.물론 기본 빈 등록 방식이(IoC / DI) 싱글톤 방식이라는 의미이며, 요청할 때마다 새로운
앞선 포스팅들에서 스프링 프레임워크는 컨테이너 내부에서 빈들을 관리해주는 것을 배웠다. 스프링 컨테이너에서 다양한 빈들을 관리해줌으로써 애플리케이션을 개발할 때 굉장히 편리하게 개발할 수 있는 장점이 있다.스프링 빈의 생명주기는 다음과 같다.스프링 컨테이너 생성 ->
클라이언트에서 서버로 요청 데이터를 전달할 때는 주로 다음과 같은 방법을 통해 전달한다.GET + 쿼리 파라미터POST - HTML FormHTTP Message Body반대로 서버에서 클라이언트에 응답 데이터를 전달할 때는 다음과 같다.정적/동적 HTMLHTTP Me
지금까지 포스팅을 통해서 스프링의 동작방식에 대한 이해와 스프링부트를 이용한 조작방법에 대해서 간단하게 소개해봤다. 예를 들어 로그인 서비스를 위한 서버를 만든다고 가정해보자. 당연하게도 다음 페이지에 넘어가기 전에 로그인 검증부터 진행해야 할 것이다. 이를 위해 ap
스프링에는 스프링 트라이앵글이라고 해서 3가지 중요성을 강조한다.IoC / DIPSAAOP이번 포스팅에서는 이 중 하나의 축을 담당하고 있는 AOP 에 대해서 정리하고자 한다.AOP는 Aspect-Oriented Programming의 약자로써 그대로 번역하면 관점-지
객체지향언어에서 활용할 수 있는 전략패턴에 대해서 포스팅 하고자 한다. 사실 디자인 패턴이라는 시리즈를 따로 팔까 고민했었다. 고민 끝에 토비에 스프링에서 OCP와 관련해서 소개한 패턴인 만큼, 스프링 시리즈에서 소개하는게 맞다고 생각해서 여기에 기록을 남긴다.전략 패
지난 포스팅에 이어서 두번째 패턴 정리이다. 팩토리 패턴은 스프링에서 Bean Context(Application Context) 에서 상속받은 빈 팩토리와 연관되어 있는 만큼 알아 두는 것이 좋다고 판단해서 기록하고자 한다.팩토리 패턴은 생성패턴이다.생성 패턴은 인스
이번 포스팅도 마찬가지로 토비의 스프링 1권에서 소개하는 패턴 중 하나인 템플릿 패턴이다. 이는 3장 전체를 설명해주는 핵심 개념으로 JDBC 커넥션을 리팩토링하기 위해 소개하는 패턴이다. 상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법. 변하지
이번장과 다음장에서는 AOP에서 활용되는 데코레이터, 프록시 패턴에 대해서 소개하고자 한다. 마찬가지로 토비의 스프링 6장에서 소개하는 내용을 정리하고자 기록한다.데코레이터 패턴은 기본 객체에 추가적인 기능을 동적으로 유연하게 첨가하는 패턴이다.AOP에서 Aspect를
데코레이터 패턴과 함께 사용하는 프록시 패턴이다. 프록시는 네트워크 통신에서도 사용되는 언어지만 디자인 패턴에서 프록시란 대리 수행자 의 역할을 한다.구체적으로 인터페이스를 사용하고 실제 기능을 하는 타겟 클래스 대신 이를 대신할 프록시 클래스를 만들고 프록시 클래스가
현재 계좌개설 서버 토이 프로젝트를 진행중에 있다. request에서 헤더값으로 유저의 ID가 들어온다는 가정하에 확인작업을 먼저하고, 이후 프로세스를 진행하는 API 로 구성되어 있다. 모든 컨트롤러마다 헤더값에 값이 있는지 확인하려면 어떻게 해야할까? 물론 FILT
앞선 포스팅의 경우 개인적으로 개념적인 부분을 따로 쪼개서 추가한 자료들이다. 이번 포스팅 부터는 토비의 스프링 책을 읽고 정리해서 TIL을 남기고자 한다. 혹시 문제가 된다면 lshn1007@hanyang.ac.kr 로 메일 주면 삭제하겠습니다.개발자가 작성한 코드를
이번장에선 TDD와 스프링에 대해서 요약해보고자 한다. 앞선 포스팅에서 처럼 토비의 스프링을 읽고 요약한 자료이다.문제가 있을 시 lshn1007@hanyang.ac.kr 로 메일 주시면 삭제하겠습니다.보통 테스트를 한다고 하면 애플리케이션에 필요한 기능을 대충이라도
이번장도 역시 토비의 스프링을 보고 요약한 포스팅이다. 이번 포스팅에 관련해서는 디자인패턴이랑 항목으로 이전에 정리한 내용이 많기 때문에 함께 참고해서 읽으면 좋을것으로 보인다.문제가 있을 시 lshn1007@hanyang.ac.kr 로 메일주시면 삭제하겠습니다.코드에
토비의 스프링을 보고 개인적으로 요약한 자료이다. 이번 포스팅에서는 예외에 관해서 적고자 한다.문제가 있을 시, lshn1007@hanyang.ac.kr 로 메일주시면 삭제하겠습니다.1\. 예외를 잡고는 아무것도 하지 않을 때2\. 예외를 잡고는 콘솔에 출력만 하는 행
토비의 스프링을 보고 정리한 내용이다. 서비스 추상화에 대해서 포스팅 하고자 한다.문제가 있을 시, lshn1007@hanyant.ac.kr 로 메일 바랍니다.트랜잭션은 더이상 나눌 수 없는 단위 작업을 말한다. (ex. 계좌 이체)중간에 SQL 작업이 실패한 경우,
토비의 스프링을 보고 정리한 자료입니다. 문제가 있을 시, lshn1007@hanyang.ac.kr 로 메일주시면 삭제하겠습니다.IoC/DI, PSA(서비스 추상화) 와 더북어 스프링의 3대 기반 기술대표적인 선언적 트랜젝션 기능에 사용한다.특정 비지니스 로직 사이에
토비의 스프링을 읽고 정리한 내용이다. 이번 포스팅에서는 스프링 핵심 기술의 응용을 정리하고자 한다.문제가 있을 시, lshn1007@hanyang.ac.kr 로 메일 주시면 삭제하겠습니다.스프링의 3대 핵심 기술인 IoC/DI + PSA + AOP 기술을 활용해서 새