개발 썸네일형 리스트형 IoC - Component, 컴포넌트 스캔 어노테이션 - 스프링 3.1 부터 도입 - basePackage 가 가장 중요한 것(?) basePackage - 가장 중요한 설정 - 원래는 문자열 값 - 문자열은 Type safe 하지 않는다. - basePackageClasses 값을 이용하면 Type safe 하게 사용 할 수 있다. - basePackageClasses 값에 전달된 값 을 시작하여 컴포넌트 스캔을 한다. 등록해야하는 bean 이 많은 경우에 컴포넌트스캔(@ComponentScan)의 단점 - 빈 등록은 초기 구동시 생성 많은 경우는 초기 구동 시간이 오래 걸릴 수 있다. ** 구동 후에는 또 다른 빈을 만들어내거나 하는 경우가 없다. 평션 사용한 빈 등록 - 스프링 5부터 - 리플렉션이나 프로시기법을 사용하지 않기 때문에 성능에.. 더보기 IoC - Autowire(오토와이어) @Autowired - 의존성 주입을 위한 어노테이션 - required : 기본값은 true 이다. 못 찾으면 애플리케이션이 안뜬다. - 사용하는 위치 : 생성자(스프링4.3부터는 생략 가능), Setter, Field 1. 생성자 ** 기본 : 어노테이션으로 각각 bean 설정 생성자에 Autowired 어노테이션으로 의존성 주입을 한다. *** 여기에 BookRepository에 빈 설정이 되어 있지 않다면 안된다. 2. Setter 3. 필드 Autowire 의 사용 될 경우의 수! 1. 해당 타입의 빈이 없을 때 사용하던 BookRepository의 빈 설정을 해제 한후 해당 클래스를 의존성 주입을 해본다. ** 어노테이션 제거 ** 실행 해당 타입의 Bean 을 찾을 수 없다는 에러가 나온다... 더보기 IoC - ComponentScan 1. application.xml 에 오토스캐닝 등록 1) application.xml 설정 2) 어노테이션으로 Bean 등록 - BookRepository @Repository, @Service 모두 컴포넌트를 상속한 어노테이션 3) bookRepository 를 bookService 에서 사용 할 수 있도록 의존성 주입 4) 확인! application.xml 에 설정된 스캐닝에 따라 패키지 하단의 모든 어노테이션을 확인하여 빈 등록과 의존성 주입을 한다. 스프링 2.5부터 가능한 기능 2. 자바 설정파일로 설정 2-1. 자바 설정 파일에 빈 선언 1) 자바 파일에 빈 설정 ApplicationConfig.java 생성 ** BookService와 BookRepository에 있던 어노테이션을 모두 .. 더보기 IoC - application.xml 로 빈 설정 1. application.xml 파일 이용 하여 Bean 설정 1) application.xml 파일 생성 2) bean 설정 scope - prototype : 매번 - request : 요청할때마다 새로운 객체 만들기 - session : http 세션당 새로운 객체 생성 - singleton : 싱글턴(default) 빈 선언한 모습 의존성 주입 - bookService에서 bookRepository를 사용할 수 있도록 주입! ref > 레퍼런스로 다른 빈을 참조한다. 다른 빈으로 설정된 것을 사용 확인! 더보기 spring-boot-starter-web pom.xml .... org.springframework.boot spring-boot-starter-web .... .... spring-boot-starter-web만 의존성에 추가해도 스프링 프로젝트에 필요한 대부분의 라이브러리가 추가된다. 더보기 IoC 컨테이너란 IoC - Inversion of Control : 의존 관계 주입(Dependency Injection)이라고도 하며, 어떤 객체가 사용하는 의존 객체를 직접 만들어 사용하는게 아니라(new class), 주입 받아 사용하는 방법을 말함. 스프링 IoC 컨테이너 - BeanFactory - 애플리케이션 컴포넌트의 중앙저장소 - 빈 설정 소스로부터 빈 정의를 읽어들이고, 빈을 구성하고 제공한다. 빈(Bean) : 컨테이너 안에 있는 객체 즉, IoC 컨테이너가 관리하는 객체 public class Book{ } >> 빈이 아니다. @Repository public class BookRepository{ public Book save(Book book){ return null; } } >> 어노테이션으로 .. 더보기 3. 페러다임 개요 1. 구조적 프로그래밍 최초로 적용된 패러다임(최초로 만들어진건 아님) 1968년 에츠허르 비버 데이크스트라(Edsger Wybe Dijkstra)가 발견 무분별한 goto 문은 프로그램 구조에 해롭다는 사실을 제시하면서 이러한 것들을 if then else와 do while until의 구조로 대체함. >> 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 2. 객체지향 프로그래밍 두 번째로 도입. 구조적 프로그래밍보다 2년 앞서 등장 요한달(Ole Johan Dahl), 크리스텐 니가드(Kristen Nygaard)에 의해 등장 >> 객체지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 3. 함수형 프로그래밍 세 번재로 가장 최근 도입되기 시작 했지만, 가장 먼저.. 더보기 2. 두가지 가치 - 행위(요구사항) vs 아키텍처 행위(요구사항) 프로그램으로 해야할 것! 개발자로서 행위가 가장 중요한걸까? 아키텍처 프로그램으로 해야할 것을 아키텍처에 적용 시켜야한다. 근데 아키텍처에 적용 할 수없다면 ? 비용은 크게 증가할 수 밖에 없다. 결국 아키텍터는 형태에 독집적이야 한다. > 새로운 기능, 새로운 요구사항을 유연하게 받아들이기 위해 > 독립적이지 않으면 개발 비용이 증가 할 수 밖에 없다. 아이젠하워 매트릭스 *깨알 지식 - 아이젠하워 매트릭스는 드와이드 D. 아이젠하워 미국 대통령이 고안한 중요성과 긴급성으로 일의 업무 순서를 정하는 매트릭스! 소프트웨어의 행위는 긴급하지만 매번 중요하지 않고, 아키텍처는 중요하지만 긴급한 경우는 없다! 1. 긴급하고 중요한 2. 긴급하지는 않지만 중요한 3. 긴급하지만 중요하지 않은 4.. 더보기 이전 1 ··· 6 7 8 9 10 11 12 ··· 17 다음