DevBoi

before advice는 생각 보다 단순하다. 해당 과 같이 생성하고, xml 파일에서 빈을 불러와서 로드한다. 단순히 클래스에 대한 빈등록을 하고, 해당 인터셉터 리스트에 추가해준다. 참고로 beforeAdvice는, MethodBeforeAdvice를 구현한다. AfterReturningAdvice, returnValue로, 해당 파라미터에 대한 사용도 가능하다 추가로 예외에 대한 핸들러도 등록이 가능하다. 강제로 쓰로우를 시키고 해당 쓰로우때, 빈을 등록하면, 해당 쓰로우 이후에는, 해당 인터셉터가 돈다 advice_throwing이라는 것을 볼수 있다. 여러가지의 advice를 활용하여 인터셉터를 구현해봤다. beforeAdvice,afterReturning,afterThrowing,around..

AOP 관련된 지식에 대해서 공부해보자 주 업무 비즈니스 로직의 전, 후, 전+후에 필요한 개발자 관점, 운영자 관점에서 필요한 업무가 있다 (로깅, 사용자 체크 등등) 해당 비즈니스 로직에 대한 처리 이후에 이런 공통된 작업을 해주는 것을 하는 행위를 AOP라고 한다. 이제 스프링 관련 AOP의 소스코딩을 해보자 우선 스프링 AOP를 사용하지 않았을때의 코딩 방법이다. 결과를 출력해주기 전에, 해당 과같이 작업을 해준다고 생각해보자 아니면 클래스 내에서 해당 소스를 나눴다고 생각해보자, 해당 AOP는 좋은 예로, 테스트에 대한 수행시간이다. 해당 과 같이 AOP적인 로직을 수행한다고 하면 모든 함수에, 작성해야한다. 소스를 나눈다고해도, 시점, 범위에 대한 일일히 설정하는 건 운영자로써 말도안되는 짓이..

여태까지 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 작업도 진행을 하게 된다. 간단히 개념만 하는 포스팅이라 ㅋ.