일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- 스프링
- 프레임워크
- @Controller
- 메이븐
- Lombok
- select
- SQL
- @RestController
- MVC2
- 김영한
- toUpperCase
- 코테
- 프로그래머스
- JSP
- STS
- MVC
- 뉴렉처
- 코딩테스트
- 롬복
- 인텔리제이
- Model2
- 서브쿼리
- AOP
- 인프런
- Model1
- 기술 대비
- 자바
- Join
- DDL
- 서블릿
- Today
- Total
목록개발(~국비)/Spring (29)
Heestory

서블릿 이용 @WebServlet(name = "memberFormServlet", urlPatterns = "/servlet/members/new-form") public class MemberFormServlet extends HttpServlet { private MemberRepository memberRepository = MemberRepository.getInstance(); @Override protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); response.se..

@WebServlet : 서블릿 애노테이션 name : 서블릿 이름 urlPatterns : URL 매핑 HTTP 응답에서 Content-length는 웹 애플리케이션 서버가 자동으로 생성해준다. HttpServletRequest,HttpServletResponse 역할 : HTTP 요청 메시지를 편리하게 사용하도록 도와주는 객체 HTTP 요청 메시지 START LINE - HTTP 메소드 - URL - 쿼리 스트링 - 스키마, 프로토콜 헤더 - 헤더 조회 바디 - form 파라미터 형식 조회 - message bodt 데이터 직접 조회 임시 저장소 :해더 HTTP 요청이 시작부터 끝날 때 까지 유지되지 임시 저장소 기능 저장 : request.setAttribute(name, value) 조회 : re..
스코프 종류 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프 웹 관련 스코프 - request : 웹 요청이 들어오고 나갈 때까지 유지되는 스코프 - session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프 - application : 웹이 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 프로토타입 스코프 :스프링 컨테이너에 조회하면(빈 요청 시점에) 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환 스프링 컨테이너는 프로토타입 빈을 생성,의존관계주입,초기화까지만 처리 이후 클라이언트가 프로토타입을 관리 할 책임을 가지..
빈 생명주기 콜백 시작 스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 → 사용 → 소멸전 콜백 → 스프링 종료 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출 소멸전 콜백 : 빈이 소멸되기 직전에 호출 객체의 생성과 초기화를 분리하자 객체의 생성 : 생성자는 필수정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다 초기화 : 이렇게 생성된 값들을 활용해서 외부 커넥션을 연락하는 무거운 동작 수행 → 유지 보수 관점에서 좋으며 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우는 생성자에서 한번에 처리하는 것이 더 나을 수 있다 빈 생명 주기 콜백 지원 하는 방법 인터페이스(Initializin..
다양한 의존 관계 주입 방법 생성자 주입 수정자 주입(setter) 주입 필드 주입 일반 메서드 주입 생성자 주입 생성자 호출 시점에 딱 1번만 호출되는 것이 보장 불변,필수 의존관계에 사용 - 불변 : setter를 사용하기 되면 매개변수에 의해 값이 변경 될 수 있음 - 필수 : 필드 값에 final을 넣기 때문에 무조건 값이 있어야 하며, 생성자에 들어오는 값이 있어야 한다 → 생성자가 필수 값이기 때문에 빈 + 의존관계가 동시에 진행된다. 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다.(스프링 빈 내에서만) 생성자 주입에서만 final 키워드를 쓸 수 있다 → 컴파일 오류를 찾아준다 수정자 주입(setter 주입) setter 라 불리는 필드의 값을 변경하는 수정자 메서..
컴포넌트 스캔과 의존 관계 자동 주입 시작하기 @ComponentScan(컴포넌트 스캔) : 설정 정보가 없어도 자동으로 스프링 빈을 등록 @Component 애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록 → 클래스에 @Component @Configuration 또한 컴포넌트 스캔 대상인데, 소스 코드 열어보면 @Component 애노테이션 붙어있음 스프링 빈의 기본 이름은 클래스 명으로 사용하되 맨 앞글자만 소문자로 쓴다 ex.MemberServiceImpl 클래스 → memberServiceImpl 직접 지정 시 옆에 이름 부여하면 된다. ex.@Component("memberService2") @Autowired : 의존관계 자동 주입, 여러 의존관계도 한번에 주입받을 수 있다. 스프링 ..

서론) 스프링이 없는 순수한 DI 컨테이너는 AppConfig에서 요청을 할 때마다 객체를 새로 생성 → 고객 그래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸 → 메모리 낭비가 심하다 → 해당 객체가 딱 1개만 설생되고, 공유하도록 설계한다 → 싱글톤 패턴 싱글톤 패턴 :글래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다 이미 만들어진 객체를 공유해서 효율적으로 사용할 수 있다. public class SingletonService { //1.static 영역에 객체를 딱 1개만 생성한다 private static final SingletonService instance = ne..
스프링 컨테이너 생성 AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); - ApplicationContext : 스프링 컨테이너, 인터페이스 스프링 컨테이너 : XML 기반, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다(스프링이 유연하게 설정가능) - AnnotationConfigApplicationContext(AppConfig.class); : ApplicationContext 인터페이스 구현체 구성 정보를 AppConfig.class에 지정 @Test @DisplayName("애플리케이션 빈 출력하기") void findApplicationBean(){ String[] ..
순수한 자바 코드에 테스트 하는 것은 효율성이 떨어진다 EX. main 메소드에 System.out.println() 와 같은 .. → Junit 을 이용하자 Junit : given , when, then 형태로 진행한다 @Test void join(){ //given Member member = new Member(1L,"memberA",Grade.VIP); //when memberService.join(member); Member findMember = memberService.findMember(1L); //then Assertions.assertThat(member).isEqualTo(findMember); //결과적으로 join 후 find를 했다면 넣고 찾는게 제대로 되고 있다는 뜻 } 역할..
스프링 자바 언어 기반의 프레임워크 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크 좋은 객체 지향 애플리케이션을 개발할 수 있도록 도와 주는 프레임워크 다형성 + OCP,DIP를 가능하기 지원 클라이언트 코드의 변경 없이 기능 확장 쉽게 부품을 교체하듯이 개발 예 ) 애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계이다. (변경 범위가 작고 유연해짐) 모든 설계에 인터페이스를 부여해놓으면 어떤 DB를 사용할지 정해지지 않아도 구현 선택 범위가 넓어질 수 있다. > 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팻토링해서 인터페이스를 도입하자 #.서론 객체 지향 프로그래밍 중..