Spring 강의 30

springMVC 기본 - (9) 빈스코프

[스코프] - 빈이 존재할 수 있는 범위 프로토타입 스코프 - 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다. 반면에 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환 [싱글톤 스코프] 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환 1. 싱글톤 스코프의 빈(memberService)을 스프링 컨테이너에 요청 2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환 3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환 [프로토타입 스코프] 스프링 컨테이너가 항상 새로운 인스턴스 생성해서 반환 1.프로토타입 스코프의 빈(protorypeBean)을 스프링 컨테이너에 요..

springMVC 기본 - (8) 빈 생명주기 콜백

[빈 생명주기 콜백] 객체의 초기화와 종료 작업 필요. NetworkClient 는 애플리케이션 시작 시점에 connect() 를 호출해서 연결을 맺어두어야 하고, 애플리케이션이 종료되면 disConnect() 를 호출해서 연결을 끊어야됨 public class NetworkClient { private String url; public NetworkClient() { System.out.println("생성자 호출, url = " + url); //2.호출됨 connect(); call("초기화 연결 메시지"); } public void setUrl(String url) { this.url = url; } //서비스 시작시 호출 public void connect() { System.out.printl..

sprongMVC 기본 - (7) 의존관계 자동 주입

[의존관계 주입 방법] 1. 생성자 주입 - 생성자 호출 시점에 딱 한번 호출이 보장돼 불변, 필수 의존관계에 사용, 생성자를 통해 의존관계 주입 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 @Component public class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRep..

springMVC 기본 - (6) 컴포넌트 스캔

[컴포넌트 스캔] 스프링 빈을 자동으로 끌어올려, @Component어노테이션 붙은 클래스를 다 찾아서 자동으로 스프링 빈 등록 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열. 등록해야 할 스프링 빈이 수십, 수백개가 되면 귀찮. 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공, 의존관계도 자동으로 주입하는 @Autowired 라는 기능도 제공 (AppConfig랑 똑같은 건데 그냥 공부용으로 남겨놔) @Configuration @ComponentScan( excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class)) //자동..

springMVC 기본 - (5) 싱글톤 컨테인너

[웹 애플리케이션과 싱글톤] 싱글톤 : 객체가 나의 JVM에 하나만 존재. - 스프링없는 DI컨테이너 public class SingletonTest { @Test @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer() { AppConfig appConfig = new AppConfig(); //1. 조회: 호출할 때 마다 객체를 생성 MemberService memberService1 = appConfig.memberService(); //2. 조회: 호출할 때 마다 객체를 생성 MemberService memberService2 = appConfig.memberService(); //참조값이 다른 것을 확인 System.out.println("memberS..

springMVC 기본 - (4) 스프링 컨테이너와 빈

[스프링 컨테이너 생성] ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); Config를 파라미터로 넘기면서 applicationContext(=스프링 컨테이너이고 인터페이스다)반환. 다형성 적용 : applicationContext를 구현한 것중에 하나가 AnnotationConfigApplicationContext. 1.new AnnotationConfigApplicationContext 하면서 AppConfig정보를 주면 스프링 컨테이너가 만들어짐 스프링 컨테이너 안에는 스프링 빈 저장소가 있어서 스프링컨테이너 생성시엔 구성정보를 지정해줘야됨 2.스프링 컨테이너가 AppConf..

springMVC 기본 - (3) 객체 지향 원리 적용

[정리] 클라이언트가 주문서비스에 주문 생성하고 그 주문서비스가 회원조회, 할인 적용해서 결과물을 클라이언트에 반환. [할인 정책 추가&테스트] public class RateDiscountPolicy implements DiscountPolicy { private int discountPercent = 10; //10% 할인 @Override public int discount(Member member, int price) { if (member.getGrade() == Grade.VIP) { return price * discountPercent / 100; } else { return 0; } } } - RateDiscountPolicy가 10%할인 되는 지 테스트 class RateDiscount..

springMVC - IoC, DI, 컨테이너

제어의 역전 : 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것 사용자가 호출하는게 아닌 프레임워크가 대신 호출.제어권의 뒤바뀜 이전에는 memerservice구현체가 직접 memoryrepository 생성연결... 어떤 MemberServiecImpl을 쓸지 AppConfig에서 결정. appConfig등장하고 프로그램에 대한 제어 흐름짐에 대한 권한은 모두 AppConfig가 가짐 의존관계 주입 : 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것 실제 어떤 구현 객체가 사용될 지 몰라. 정적인 클래스 의존관계는 변경하지 않고 동적인 객체 인스턴스 의존관계 변경. OrderService..

springMVC 기본 - (2) 회원 도메인

[도메인 설계] 1. 도메인 협력 관계 : 기획자들도 볼 수 있음. 2. 클래스 다이어그램 : 도메인 협력 관계를 바탕으로 개발자들이 구체화해서 클래스 다이어그램을 만듦. 실제 서버를 실행하지 않고 클래스들만 분석해서 볼 수 있음.근데 DB뭘 넣을 지는 서버가 뜰때 결정되는 동적. 3. 객체 다이어그램 : 서버가 떠서 클라이언트가 실제로 사용하는 인스턴스끼리의 참조. [회원 도메인 개발] public enum Grade{ BASIC, VIP } public class Member{ private Long idl private String name; private Grade grade; public member(Long id, Strong name, Grade grade){ this.id = id; thi..

springMVC 기본 - (1) 좋은 객체 지향 설계와 스프링

[객체지향] spring은 좋은 객체 지향 애플리케이션 개발이 가능하게 도와주는 프레임워크 객체 지향은 무엇인가? 객체들의 모임.협력, 유연하고 변경 용이(컴포넌트를 쉽고 유연하게 변경->다형성) 다형성 : 역할+구현으로 분리 자바는 역할(인터페이스)+구현(인터페이스 구현한 클래스 혹은 구현 객체) 역할의 인터페이스를 따라서 구현했기때문에 역할에만 의존 -> 무한히 확장 가능(확장 가능한 설계), 클라이언트에 영향을 주지 않고 새로운 기능 제공 클라이언트는 내부 구조 몰라도 인터페이스만 알면됨. 역할=인터페이스, 구현=인터페이스를 구현한 클래스설계 역할이 더 중요해!! (역할, 인터페이스가 변하면 모두 영향을 받으아 인터페이스를 잘 설계한는게 중요해 ) 클라이언트 변경 없이 서버의 변경 구현을 유연하게 ..

1 2 3