DevBoi

여태까지 Config파일을 등록해서 bean을 등록 하고, 해당 config에 빈을 등록한걸 사용도 해보고 했다. 근데 결정적으로 왜? 왜 빈을 사용할까? ioc에 들어가서 관리의 대상이 되는건 알겠는데.... 굳이 왜쓰지? class로 쓰면 되는거 아닌가? 싶다 그래서 좀더 딥한 개념의 이유와 사용목적에 대해서 공부를 해보자. 우선 해당 개념을 이해하기 위해서는 자바빈 vs 스프링 빈에 대한 차이를 알아야 한다. 자바빈은 DTO,VO와 같이 getter,setter로만 접근이 가능한 자바 파일을 의미한다. 반면 스프링 빈은 IOC컨테이너가 관리하는 JAVA 객체를 의미한다. 쉽게 말하면, Bean, Component등을 등록하면 IOC 컨테이너에서 관리가 된다는 의미이다. 그러면 스프링에 제어권을 넘긴..

기존에는 xml에서 특정 빈에 대한 설정을 하고, 해당 설정을 통해서 관리가 되었다. 해당 xml에서 빈을 생성하고, set으로 특정 빈을 넣고, 그리고 리스트 형식으로 넣기도하고 등등 이방식에서 어노테이션 방식으로 편하게 변화했기 때문에 해당 내용으로 변경해보자 쉽게 말하면 , config 파일을 xml 파일이 아닌, 자바 파일로 설정하는 것이다. 이런식으로 하면, 우선 빈이 생성된다. 단 주의 점이, @Bean에서의 생성자는 예를 들면 exam() exam이 bean id가 되는 것이다. 쉽게 말하면 bean어노테이션으로 붙으면 메소드 명이 bean id 가 되고, 명사형이 아니다. 우선 config 파일을 바꿨다. 기본 생성자가 아닌, console에서는 exam이 필요하기 때문에 해당 autowi..

이전에는 이렇게 특정 빈을 만들고, 해당 빈을 사용할수 있도록, context:annotation-config를 통해서 autowired에서 자동으로 빈에 대한 탐지를 할수 있도록 해줬다 그래서 Autowired를 붙이면 변수명이 같거나, 해당 관련 구현체에 대한 것을 가져오거나 Quailifier를 통해서 빈을 선별해서 가져왔다. 그런데 빈에 대한 생성을 어노테이션을 하고, 스프링에다가 스캔방식으로 찾아라~ 라고 한다면? 위와 같이 찾거나 해당 Exam도, 빈으로 생성해서, GridConsole에서 Autowird하는 부분에서 가져올수 있도록 설정 할수있다. 컴포넌트 스캔에 대한 경로 지정은 특정 하위로 다 지정할수도있다. 근데 빈에 대한 초기값을 굳이 저렇게 해야할까?? 요로케 하면, 특정 값에 대한..

이전의 xml에서 설정을 해서 빈을 바꿔주었다. 그런데 이건 예전 방식이고, 어노테이션으로 DI로 많이 사용한다. 우선 property 를 사용해서, 특정 빈에서 다른 빈으로 DI를 하는 방식을 어노테이션으로 바꿔보자 저번의 set함수에서 오토와이얼드를 사용해서 주입을 하고, xml의 프로퍼티를 삭제 하였다. 추가로, xml에 context를 추가하여, 해당 어플리케이션에서는 @autowired어노테이션을 찾아줘라는 설정을 이렇게 한다. 근데 자동으로 주입해주는 빈의 기준은 뭘까?? 왜냐면, 별도로 빈 id를 지정하지 않았기 때문에, 빈이 여러개라면 어떤 빈으로 주입이 될까? 우선 bean의 아디기준으로 바인딩 되는게 아니라, class 타입 기준으로 바인딩이 된다. 그러면 만약에 동일 빈이 아래와 같이..

특정 빈에 상수값 세팅 하는 방법 생성자에 대한 값을 넣어서 빈을 주입 하는 방법 특정 빈에, 해당 값을 가지는데, 여러가지 생성이 필요하여, 네임스페이스를 사용하는 경우 컬렉션 타입으로 빈을 생성 및 사용방법 두가지 방법이 있다. 한가지는 빈과 생성자를 통해서 컬렉션 안의 타입 빈을 선언 하는 것이고 하나는 util을 추가해서 해당 유틸을 사용하는 것이다. 사용 방법은 같다. 실제로 값을 확인하면 정상적으로 확인이 가능하다.

DI 관련 그리고 스프링 설정 관련, ApplicationContext 인터페이스를 구현한 구현체들이 여럿 있다 각각은 해당 context를 구현한 위치에 따른 정보 전달에 따라서 다르게 사용한다 (FIleSystem은 컴퓨터 절대 경로, xmlWeb은 특정 Url을 통해서 해당 config 파일을 받아옴 등등) 무튼 기본 java project로 생성 했던 프로젝트를 프로젝트 오른쪽 버튼 configuration > convert to Maven project를 하게되면 기본 자바 프로젝트 > 메이븐 프로젝트로 변경이 된다. 변경이 되면, Maven 방식의 pom.xml이 생성이 되고 이런 프로젝트 구조에서 pom.xml에서 디펜던시를 추가한다. (add로 maven 관련 검색이 안되면, show vi..

저번 포스팅에서 DI에 대한 작업은 Spring. 에서 DI 컨테이너가 지원해준다고 했다. 좀 더 상세히, 그리고 내가 구현해서 한번 어떻게 동작하는 지 살펴보자 우선 Program이란 클래스가 있다. 해당 클래스에서는 Exam,ExamConsole이라는 인터페이스를 구현하고 있는 구현체를 사용하여, 간략하게 테스트 코드를 작성한다. 이런식으로 사용한다. ExamConsole은 두가지의 구현체를 가진다. 인라인과 그리드 물론 둘다 출력은 잘 된다. ExamConsole exam이라는 녀석에 대한 사용을 중간에 exam = Grid 로 바꿔도 잘 동작한다. 그러면 결국은 이 구현체를 바꿀때마다 소스코드 작업이 이뤄져야 한다는 것이다. 예를 들면 어떤 소스던 어떤 로직이던 특정 부분에서 구현체에 대한 변경을..

스프링에서는 여러가지 부품들에 대한 명세를 개발자가 하고 이를 구현하고 제어를 하는 IOC 컨테이너가 있다. IOC에서는 부품들끼리(class)의 DI 작업을 진행해주고 각 class에 대한 생성 과 삭제 등을 제어한다.(생명주기 관리) IOC는 제어의 역전 즉 이 컨테이너가 각 객체에 대한 생명주기 관리 및 결합을 진행해주기 때문에, 개발자 입장에서는 굉장히 편리하게 개발을 도와주는 프레임 워크라고 느낄수 있는 강력한 요소 중에 하나이다. 결국 이 IOC 컨테이너에서 Spring DI 작업도 진행을 하게 된다. 간단히 개념만 하는 포스팅이라 ㅋ.

DI : 의존성 주입, 종속성 주입 해당 케이스에서는 B는 A의 부품이라고 얘기를 한다.(B는 A에 종속된다.) 해당 DI작업은 부품을 injection하는 작업이 번거롭다는 단점이 있다.(하지만 이 Injection 작업은 스프링이 해준다. 별도 간단하게 명시만 하면 스프링이 알아서 결과물을 알려준다.) DI를 하는이유) Store에서 pencil을 정의 하여, 사용한다. 만약에 Store에서 pencil이 아니라 지우개나 다른 상품을 사고싶다고 하면? 그렇게 되는 경우, pencil을 바꿔야한다. Store의 변경은, 해당 판매 상품을 바꾸고자 할때마다 발생하게 된다. 이러한 경우를 유연성이 떨어지고, 결합도가 높은 관계를 가진다고 이해하면된다. 이러한 문제를 해결하기 위해서는 다형성이라는 개념으로 ..

특정 서비스에 대한 수정이 발생한다고 생각해보자 소스코드에서 가장 큰 고려사항은, 결합력에 관련된 내용인데, 결합력이 어떤 것이냐.... 결합도가 높은 소스코드의 경우 A.class, B.class라고 예를 들어보겠다. A.class가 변경이 발생되면, B.class도 무조건 수정이 되어야 한다. 하지만 결합도가 낮은경우, A.class가 변경이 발생했다고 한들, B.class에 영향도 없고 변경도 필요없다. 이러한 개념에서 나온것이 인터페이스라는 것이다. 결합도가 높은 시스템 A a = new A(); a.setX(); 결합도가 낮은 시스템 X x = 외부파일.class x.setX(); X는 특정 공통 소스들을 구현하기 위한 인터페이스이고, A는 그냥 객체라고 생각하면 된다. 결합도가 높을 경우, A..