DevBoi

도메인은 우선 기본적으로 크게 4가지로 잡았다. User - 사용자 Post - 게시물 master PostContent -게시물 요청자 PostComment - 게시물 작업자 Asset - 자산 자산은 이력성으로 쌓고, 게시물도 이력성으로 쌓을 것이다. 그이유는 스케줄러나 배치로 주기적으로 회원들 정보를 갱신해주는것도 좋지만 그렇게 많은 사람들의 작업이 있지않는 이상,이를 굳이... 뭐 나중에 데이터가 점점 쌓이면 등급에 대한건 그떄 고민해보자 스케줄러던 배치던 무튼 이렇게 4개에 대한 도메인을 설계했고, 해당 관련 개발까지 머리속으로 설계는 끝냈다. 사실 개발하는것 자체보다 설계에 시간을 많이 쓰긴했다. 이 모델 기반으로 JPA를 설계할 것이고 개발해 나갈 것이다. mybatis를 쓸까 고민도 하긴했..

기존에는 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란, 예를 들어 특정 A라는 클래스에서, B라는 클래스의 인스턴스를 사용하는 경우, 가져오는 경우이다. 전통적인 방법으로는 Foo가 new 연산자를 사용해 인스턴스를 생성하거나, 팩토리를 이용해 인스턴스를 가져온다. 하지만 Ioc 접근 방식을 통하면, 런타임 시점에 Foo에게 제공된다. 이런 런타임 시점에 의존 관계에 대해서 주입을 하는건 DI라는 이름으로 바뀐다. DI : 자바빈과 인터페이스를 근간으로 한다. 스프링 DI 제공자로 사용하면 애플리케이션 내에서 여러가지 방식으로 의존성 설정을 유연하게 설정할수 있다. (외부 xml 파일, 스프링 사바 설정 파일, 어노테이션 등등) ..

우선, MVC 패턴을 만들기 위해, 컨트롤러 생성 해준다. date.blog 에는 @SpringApplication 이 있다.(프로젝트 생성시 기본으로 설치되는 class) 여기 이 친구 하위에 controller를 만들어준다. 이유는 간단하다. @SpringBootApplication 상세 선언 화면이다. 좀 상세히 보면, 해당 경로 하위의 것들을 ComponentScan 후에, 메모리에 올려놓는다. 즉 초기에 구동할때, 어떤 것들을 new하고, 어떤것들을 heap에 두어서 관리를 할지 결정한다. 이는 IOC에 해당하는 중요한 스프링 핵심 개념이다. 즉 Class를 사용자 별도로 new하지말고, Spring 이 관리 해주어, 쉽게 메모리 관리를 하게 도와준다고 보면 된다. 간단하게, 테스트 용 Rest..