웹 프로그래밍 (63) 썸네일형 리스트형 HTTP HTTP -모든것이 HTTP(HyperText Transfer Protocol) -HTTP 메시지에 모든 것을 전송(HTML, 영상, 모든형태의 데이터) -TCP: HTTP/1.1(중요한 핵심 버전), HTTP/2(성능개선) -UDP: HTTP/3 HTTP 특징 -클라이언트 서버구조 -무상태 프로토콜(stateless), 비연결성 -HTTP메시지 -단순함,확장가능 클라이언트 서버 구조 -Reqeust Response 구조 -클라이언트는 서버에 요청을 보내고 응답을 대기 -서버가 요청에 대한 결과를 만들어서 응답 -서버는 비지니스 로직과 데이터, 클라이언트는 UI와 사용성에 집중하여 각각 독립적으로 발전 가능 무상태 프로토콜(Stateless) -서버가 클라이언트의 상태를 보존 X -장점: 서버 확장성 높.. URI와 웹 브라우저 URI -Uniform: 리소스 식별하는 통일된 방식 -Resource: 자원, URI로 식별할수 있는 모든것(제한 없음) -Identifier: 다른항목과 구분하는데 필요한 정보 URI URL(Resource Locater:리소스가 있는 위치지정) URN(Resource Name:리소스에 이름 부여) e.g. URL(foo://example.com:8042/oveer/there?name=ferret#nose) URN(urn:example:animal:ferret:nose): 거의 안씀 분석 https://www.google.com/search?q=hello&hl=ko scheme://[userinfo@]host[:port][/path][?query][#fragment] scheme -주로 프로토콜 사용.. 인터넷 네트워크 인터넷 통신 -복잡한 인터넷 망? -> IP(인터넷 프로토콜) 주소 부여 e.g. 클라이언트(100.100.100.1) 서버(200.200.200.2) -역할 -지정한 IP 주소에 데이터 전달 -패킷(Packet)이라는 통신 단위로 데이터 전달 -패킷정보 (출발지IP, 목적지IP,기타, 전송데이터) IP 프로토콜의 한계 -비연결성(패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송됨) -비신뢰성 -중간에 패킷이 사라지면(패킷 손실)? -패킷이 순서대로 안오면(World Hello,)? -프로그램 구분(같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘이상이면?) 통신 과정 인터넷 프로토콜 스택의 4계층 애플리케이션 계층(HTTP,FTP) 전송 계층(TCP,UDP) 인터넷 계층(IP) 네트워크.. 빈 스코프 스코프는 빈이 존재할수 있는 범위 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 프로토타입: 빈의 생성과 의존관계 주입(초기화 메서드포함)까지만 관여하고 클라이언트에 넘겨주고 더이상 관리하지 않음 프로토타입 스코프 -싱글톤은 스프링 컨테이너 생성시점에 스프링 빈을 등록하여 항상 같은 인스턴스의 스프링 빈을 반환 프로토타입은 요청마다 항상 새로운 인스턴스를 생성해서 반환 -> 관리 책임이 클라이언트로 넘어감 -> @PreDestory 같은 종료 메서드는 호출되지 않음 -싱글톤 빈과 함께 사용시에 의도대로 동작하지 않음 -싱글톤 빈에서 프로토타입 빈 사용하면 싱글톤 생성시점에 프로토타입이 주입되어 더이상 생성되지 않음 해결법 ObjectProvider 필요할때마다.. 빈 생명주기(라이프사이클) 콜백 의존관계 주입이 끝나야 초기화를 할수 있을텐데 그 시점을 어떻게 알수 있을까? -스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려줌(종료도 마찬가지) 스프링 빈의 이벤트 라이프사이클(싱글톤) -스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료 스프링의 콜백 방법 -인터페이스 IntializionBean, DisposableBean (거의 사용하지 않음) -단점: 스프링 전용 인터페이스에 의존, 코드 수정이 불가한 외부 라이브러리에 적용불가 -빈 등록할때 초기화,소멸 메서드 지정( @Bean(initMethod = "init", destroyMethod = "close") -장점: 설정정보에.. 스프링 빈 가져올때 팁 조회 대상 빈이 2개 이상일때 1.@Autowired 필드 명 매칭 -타입 매칭 -타입 매칭 결과가 2개 이상일때는 필드명, 파라미터명(첫소문자 주의) 으로 빈 이름 매칭 2.@Quilifier -> @Quilifier 이름끼리 매칭(추가 구분자), 단 모든 선언앞에 @Quilifier을 붙여 주어야함 3.@Primary 사용: 여러 빈 매칭되면 @Primary가 우선권을 가짐 @Quilifier가 @Primary보다 우선순위가 높음(구체적) 조회한 빈이 모두 필요할때 List, Map 사용 자동,수동의 올바른 기준 -트렌드는 자동을 선호 -업무 로직 빈(자동) -컨트롤러, 핵심 비지니스 로직, 데이터 계층의 로직을 처리하는 리포지토리등, 비지니스 요구사항을 개발할때 추가 및 변경 -단 다형성을 적극활용.. 의존관계 자동 주입 다양한 의존관계 주입 방법 생성자 주입 -생성자 호출시점에 1번만 호출되는것이 보장 -불변, 필수(private final) 수정자 주입 -setter 주입 -선택 e.g. @Autowired(require = false) -변경 가능성이 있는 의존관계에 사용 필드 주입 -필드앞 에다가 @Autowired 를 직접함 -안티 패턴: 외부에서 변경이 불가능해서 테스트 어려움(쓰지 말것) 일반 메서드 주입 - 일반 메서드를 통해서 주입(setter와 유사) - 잘사용하지 않음 @Autowired는 스프링 컨테이너에 등록된 스프링 빈만 가능한 기능임 컴포넌트 스캔 컴포넌트 스캔 설정정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능 제공 @ComponentScan이 붙은 Config클래스를 통해 @Component가 붙은 클래스를 스프링 빈 객체로 등록(이름은 첫글자가 소문자가됨) 의존관계도 자동으로 주입하는 @Autowired와 함께 쓰임(타입으로 찾아서 주입) 탐색위치와 기본 스캔 대상 basePackeage로 컴포넌트 스캔할 시작위치 지정(하위 포함) 지정하지 않으면 @ComponentScan이 붙은 클래스의 패키지를 시작위치 지정(디폴트가 관례) 이전 1 ··· 4 5 6 7 8 다음