Spring ?
- 2004년 3월 오픈소스로 처음 등장.
- 규모가 큰 애플리케이션을 자바로 만들 때 필요한 프레임 워크.
- 중복 코드의 사용률을 줄여주고 비즈니스 로직을 더 간단하게 해줌.
- 의존 주입(Dependency Injection) 지원
- AOP(Aspect-Iriented Programming)지원
- MVC웹 프레임워크제공.
- JDBC, JPA연동, 선언적 트랜잭션 처리등 DB 연동 지원.
▶ 필수 라이브러리 (둘중 하나 선택)
스프링 프레임워크(Spring Framework)
스프링 부트(Spring Boot) : 애플리케이션 개발
▶ 서브 라이브러리
스프링 웹플로(Spring Web Flow) : 화면 전환,흐름을 관리
스프링 시큐리티(Spring Security) : 인증/허가 처리 관리
스프링 배치(Spring Batch) : 일괄처리용
스프링 클라우드(Spring Cloud) : 분산 시스템제공
스프링 데이터(Spring Data) || 스프링 JPA(Spring JPA) : DB 연동
스프링 Rest Docs(Spring Rest Docs) : API 문서 도구
스프링 세션(Spring Session) : 세션 기술
스프링의 특징
1. IoC(Inversion of Control) = "제어의 역행"
: 객체의 인스턴스 생성부터 소멸까지 생명주기 관리를 개발자 대신 해줌.
→ 객체가 자신이 사용할 객체를 생성하거나 선택하지 않음
→ 객체는 자신이 어떻게 생성되고 사용되는지 알 수 없음.
→ 모든 객체는 IoC Container에 의해 만들어지고 사용됨.
스프링의 경우 Spring Container에서 객체를 생성하고 공급하는 역할을 담당.
→ Bean : Spring Bean Container에 존재하고 Spring IoC Container가 관리(인스턴스화, 생성)하는 스프링 객체. 애너테이션을 통해 설정.
→ Bean의 조건
1) 기본 생성자가 존재해야함.
2) 모든 멤버 변수는 private
3) 멤버 변수 마다 getter, setter가 존재해야함.(boolean의 경우 is를 붙임.)
4) 외부에서는 메소드를 통해서만 멈버 변수에 접근이 가능.
5) Serializable(직렬화)가 가능해야함.
==> 시스템 내부에서 사용하는 객체 또는 데이터를 외부의 시스템에서도 사용할 수 있도록 변화시켜 주는것
= RMI(Remote Method Inovation)
→ Bean 사용법
① 메인 실행 메소드가 있는 클래스에서 선언.
=> static ApplicationContect 스프링이름 = null;
② main 메소드에서 재정의
=> 스프링이름 = new AnnotationConfigApplicationContext(스프링설정클래스이름.class);
③ 각 메소드 마다 필요한 빈에 해당하는 클래스를 재정의 해놓은 변수를 통해 호출해서 사용.
=> 빈타입 변수 = 스프링이름.getBean("빈이름", 빈타입.class);
=> 해당 타입의 빈이 하나 뿐이라면 타입만 명시해 주어도됨.
④ 빈을 저장한 변수를 이용해 메소드 실행.
=> 변수.메소드이름();
Spring Container의 종류
1) BeanFactory
: 스프링 컨테이너의 최상위 인터페이스. 객체를 생성하고, 객체 사이의 런타임 의존 관계를 맺어줌.
2) ApplicationContext = Spring Container
: BeanFactory를 포함한 여러 인터페이스들을 상속받은 인터페이스 (BeanFactory의 확장 버전)
==> ResourcePatternResolver, EnvironmentCapable, MessageSource, ApplicationEventPublisher
: BeanFactory의 역할 뿐만 아니라 메시지 다국화, 환경변수등 다양한 기능을 추가로 제공.
==> BeanFoctory는 빈을 생성하고 관계를 설정하는 IoC의 기본 기능에 초점을 맞춘것이고,
ApplicationContext는 별도의 정보를 참고해서 빈의 생성, 관계설정 등의 제어를 총괄하는것에 초점을 맞춘것.
: XML 기반 또는 Annotation기반의 자바설정 클래스로 만들 수 있음.
2. DI(Dependency Injection) = "의존성 주입"
: 의존하는 객체를 직접 생성하지 않고 전달받아 사용하는 개념.
: 구성요소간의 의존관계가 소스코드 내부가 아닌 외부의 설정 파일을 통해 정의 되는 방식.
: 코드 재사용률을 높여 소스코드를 다양한 곳에 사용가능. → 모듈간 결합도 ↓
: 필요할 때마다 기능을 넣었다 뺏다 하면서 적절한 상황에 유동적으로 사용가능.
: 꼭 스프링 빈객체가 아니더라도 주입은 가능하지만 스프링컨테이너에서 관리가되지 않음.
3. POJO(Plain Old Java Object) : '오래된' 방식의 '순수한' 자바객체
: Java EE를 사용하면서 해당 플랫폼에 종속되어 있는 무거운객체들을 만드는것에 반발하여 나타난 용어.
: 인터페이스를 직접 구현하거나 상속받을 필요가 없어 기존 라이브러리를 지원하기 용이하며 가볍다. ==> 구조가 단순.
: 스프링에서 정한 표준 인터페이스 "JPA(Java Persistence API)" 아래에서 구현되고 실행됨.
: 자동화된 테스트 코드 작성이 편리함.
4. AOP(Aspect Object Programming) = "관점 지향 프로그래밍"
: 여러 모듈에서 공통적으로 사용하는 기능을 분리하여 관리 할 수 있음. → 재사용성 ↑
: OOP(Object Oriented Programming 객체지향프로그래밍)를 더욱 발전시키기 위한 개념으로 각 기능별로 모듈화 해서 분리 시킴.
→ OOP로 프로그래밍된 각 서비스가 공통적으로 갖는 모듈을 분리시켜서 해당 소스 코드가 외부의 다른 클래스에 존재하도록 하는것.
- 장점
1) 각 비즈니스 로직마다 복붙을 통해 생겨난 중복 코드가 사라짐.
2) 개발자는 자기 자신의 비즈니스 코드에만 집중할 수 있음. → 코드가 간결해지고 유지보수가 쉬움.
3) 재활용성 ↑
OOP(Object Oriented Programming)
: 모든 데이터를 현실에 빗대어 객체로 다루는 프로그래밍 기법
OOP의 5가지 특징
① 캡슐화 (Encapsulation) : 데이터와함수를 하나로 묶음
==> 데이터 변경으로 인한 에러가 줄고 코드가 단순해짐. 재사용이 용이.
② 정보은닉 (Information Hiding) : private로 선언한 데이터는 자기 자신을 통해서만 접근 가능.(setter, getter)
==> 각객체의 수정이 다른 객체에게 미치는 영향을 최소화. 외부 객체의 접근을 막아 프로젝트 확장시 오류 최소화.
③ 추상화 (Abstraction) : 불필요한 부분은 생략하고 중요한 것에만 초점을 맞춰 모델로 만듬.
==> 시스템 구조를 시각적으로 표현. 완전하지 않더라고 대략적으로 모델을 만들어 테스트 및 보완이 가능.
④ 상속성 (Inheritance) : 부모클래스에 정의된 모든것을 상속 받음.
==> 재정의 불필요. 프로젝트 확장시 오류 최소화. 자식 클래스에서 부모클래스의 메소드 재정의(Overriding)가능. 클래스 재사용 용이.
⑤ 다형성 (Polymorphism) : 호출객체에 따라 다른동작 수행.
==>오버라이딩을 통해 이름은 같지만 동작이 다른 여러개의 메소드를 가지므로 어떤 파라미터를 통해 호출되는지에 따라 각각 다른 메소드가 실행.
==>가독성이 좋음.
OOP 설계 5가지 원칙 S.O.L.I.D
① S : Single Responsibility Principle (단일 책임의 원칙) = 모든 메서드 또는 클래스는 단 하나의 책임을 가짐.
② O : Open/Closed Principle (개방 /폐쇄의 원칙) = 소프트웨어의 Entity(클래스, 모듈, 메서드)들의 확장은 권장하되 기존 모듈의 변경을 권장하지 않음.
③ L : Liskov Substitution Principle (리스코브 치환 원칙) = 부모클래스를 상속한 자식 클래스는 부모클래스의 역할을 정확히 해내야함.
④ I : Interface Segregation Principle (인터페이스 분리의 원칙) = 인터페이스를 구체적이고 작은 단위들로 분리시켜 꼭 필요한 인터페이만 상속.
⑤ D : Dependency Inversion Principle (의존성 역전의 원칙) = 의존하는 클래스를 추상화하고 외부에서 주입.
스프링 DI(Dependency Injection)
Dependency 객체간의 의존을 의미함.
: 의존하는 객체를 직접 생성하는것이 아닌 전달 받는 방식.
: 두 객체 간의 관계를 외부에서 결정해주는 디자인패턴.
: 인터페이스를 사이에 두어서 클래스 끼리는 의존관계가 없지만 런타임 시에 동적으로 주입 → 객체간 결합도는 낮추고 유연성을 확보해줌.
의존 주입 방법
1) 생성자 방식
: 생성자에 의존성을 주입 받고자 하는 멤버변수를 나열하는 방법.
: 주입할 의존객체가 두개 이상이어도 동일한 방식.
: 빈객체를 생성하는 시점에 모든 의존 객체가 주입됨. → 완전한 상태로 객체 사용 가능.
: 생정자가 받는 파라미터의 개수가 많은 경우 각 인자가 어떤 의존 객체를 설정하는지 알수 없음.→ 생성자 코드 확인 필요.
2) 메소드 방식
: 의존 객체를 setter 메소드에게 주입.
: setter 메소드이름을 통해 어떤 객체가 주입되는지 알수 있다 → 필요한 객체만 정해서 주입 가능. but 불완전한 객체.
: 필요하지 않은 의존객체를 주입하지 않아도 비어있는 객체는 생성되기 때문에 NullPointException이 발생 할 수 있음.
1. @Autowired(의존자동주입)
: Spring에게 의존성을 주입하라는 명령어와 같음.
: 생성자 , 필드, 세터에 붙일 수 있음.
: 자동주입을 적용한 대상과 일치하는 빈이 없다면 실행되지 않으므로 Autowired를 적용한 대상은 반드시 빈으로 등록해주어야함.
: 빈으로 등록된 타입의 클래스에서 주입되어야하는 객체에 붙여주면 빈등록설정에서 주입해주지 않아도 자동으로 주입됨.
→ 스프링 빈으로 생성할 클래스내의 자동주입을 원하는 곳에 @Autowired를 지정해주면 스프링 환경설정 클래스에서 주입없이 기본 생성코드만 작성.
2. @Qualifier
: 자동주입 설정해놓은 빈과 같은 타입의 빈이 2개이상 존재 할때 원하는 빈을 선택할 수 있도록 설정해주는 용도.
→ @Qualifier(value = "bean객체 이름") : 지정하는 쪽도 주입되는 쪽 둘다 써줘야함.
ex) Member 타입의 member1과 member2라는 빈이 있을 경우 member1을 원한다면 양쪽에 모두 지정을해서 짝을잇는 개념으로 사용.
: 같은 타입의 빈이 아니더라도 @Autowired로 지정된 클래스를 상속받는 다른클래스타입의 객체도 포함해서 인식하기 때문에
이러한 오류를 줄이고 정확하게 원하는 빈객체를 명시해주기위해 사용.
: @Qualifier가 명시되지 않은 경우는 빈의 이름을 한정자(클래스 이름에서 앞글자만 소문자로 바꾼 형태)로 지정.
- 스프링 @Autowired 어노테이션 적용시 의존 객체를 찾는 순서
1) 타입이 같은 bean 객체를 검색한다. 1개이면 해당 bean 객체를 사용한다.
2) @Qualifier가 명시되어 있는 경우 같은 값을 갖는 bean 객체여야 한다.
3) 타입이 같은 bean 객체가 두개 이상이고, @Qualifier가 없는 경우 이름이 같은 빈 객체를 찾는다.
→ 찾은경우 그 객체를 사용
4) 타입이 같은 bean 객체가 두개 이상이면, @Qualifier로 지정한 bean 객체를 찾는다.
→ 찾은경우 그 객체를 사용
5) 위 경우 모두 해당되지 않으면 컨테이너가 Exception을 발생시킨다.
3. @Primary
: Qualifier를 지정되어 있지 않을때 특정 클래스에 적용시키면 우선순위를 가짐.
4. @ComponentScan
1) @Component
: 빈으로 설정하고 싶은 필드나 메소드, 생성자에 붙여줌.
: 빈으로 등록할 때 사용할 이름을 지정할 수 있음.
→ 이름을 지정해주지 않았을 경우 클래스 이름의 첫글자를 소문자로 바꾼이름으로 지정. ex) Member → member
: 스캔대상인 클래스들은 자동으로 빈으로 등록되기 때문에 따로 설정클래스에 빈으로 명시해주지 않아도 됨.
2) @ComponentScan
: 스프링이 직접 클래스를 검색하여 빈으로 등록하는 기능.
: 스프링 설정 클래스에 명시해줌.
: {"패키지이름1", "패키지이름2",... }를 써서 한개 이상의 스캔 대상패키지 목록을 정할 수 있음 ==> 지정한 패키지의 하위 패키지도 포함.
3) @ComponentScan(excludeFilters)
: excludeFilters = @Filter(type = FilterType.타입, pattern 또는 classes= "표현식")을 추가해서 스캔제외 대상을 지정할 수 있음.
→ ex) excludeFilters= {@Filter(type = FilterType.REGEX, pattern = "spring\..*Dao")}
: spring. 으로 시작하고 Dao로 끝나는 정규식 패턴을 지정하여 해당 클래스를 스캔대상에서 제외한다는 뜻
4) 기본스캔 대상
:@Component만 스캔대상인것은 아님.
① @Component
② @Controller
③ @Service
④ @Repository
⑤ @Configuration
빈 라이프 사이클 (Bean LifeCycle)
: 스프링 컨테이너 생성 → [스프링 빈 생성 → 의존관계주입 → 초기화 콜백 → 사용 → 소멸 전 콜백] → 스프링 컨테이너 종료.
1. 컨테이너의 라이프 사이클
: 컨테이너의 라이프 사이클에 따라 빈의 라이프 사이클도 자연스럽게 생성과 소멸의 과정을 가짐. → 스프링 컨테이너가 빈의 라이프 사이클을 관리.
: 컨테이너 초기화 (빈 생성, 의존주입, 빈 초기화) → 컨테이너 종료(빈 소멸)
: AnnotationConfigApplicationContext의 생성자를 이용해서 컨테이너 생성하면서 동시에 초기화.
: close() 메소드를 이용해서 컨테이너 종료.
2. 스프링 빈 객체의 라이프 사이클
: 빈 생성 → 의존관계주입 → 초기화 콜백 → 사용 → 소멸 콜백
: 지정된 메소드를 호출하여 빈의 생성고 소멸을 관리함.
스프링 내의 인터페이스르 구현하는 방법과 커스텀 메서드를 지정하는 방법이 있음.
1) 스프링내의 인터페이스를 이용
: 직접 구현한 클래스를 Bean으로 설정할 때 사용.
org.springframework.beans.factory.InitializingBean : 이 인터페이스를 구현하면 스프링 컨테이너는 초기화 과정에서 afterPropertiesSet() 메소드를 실행.
org.springframework.beans.factory.DisposableBean : 이 인터페이스를 구현하면 스프링 컨테이너는 소멸 과정에서 destroy() 메소드를 실행.
: 위의 메소드들은 자동으로 실행 되기 때문에 빈 설정시에 호출하지 않아도됨.
2) 커스텀메서드 이용
: 직접 구현한 클래스가 아닌 외부에서 제공받은 클래스를 Bean으로 설정할 때 사용.
: @Bean 태그에 initMehod 속성과 destroyMethod 속성을 사용해 초기화 메소드와 소멸메소드의 이름을 지정.
→ @Bean (initMethod = "초기화메소드이름", destroyMethod= "소멸 메소드이름")
3. 빈의 생성과 관리범위
: 빈을 설정할 때 빈의 라이프사이클의 범위를 정해줄수 있음
: @Bean 애너테이션과 함께 @Scope 애너테이션을 사용해서 정해줌
: singletone은 기본값이며 지정하면 한 클래스에 대해 한개의 객체만 존재하므로 동일한 이름을 갖는 빈을 여러번 구해도 같은 객체.
: prototype으로 지정하면 빈을 구할때 마다 매번 새로운 객체를 생성하므로 서로 다른 객체.
==> 프로토타입의 빈은 라이프사이클을 완전히 따르지 않음 → 컨테이너가 종료된다고해서 빈의 소멸이 진행되지 않으므로 따로 처리해주어야함.
## AOP(Aspect Oriented Programming) : 관점지향 프로그래밍 : 시스템 엔지니어, 개발자 중심의 서비스 개발 기법. : 여러객체에 공통적으로 적용할수 있어 재사용성 ↑ : 기본적으로 설정되는 spring-context 가 spring-aop 모듈을 함께 제공해주기 때문에 애너테이션 의존만 추가하면됨. : 스프링에서 AOP를 설정하는데 필요한 애너테이션을 제공받기위해 aspectjweaver의존을 추가해야함. → xml에 의존 설정.
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>1.8.13</version>
</dependency>→ AOP는 "중복되는 코드를 떼어내서 분리하고 메소드들은 자신이 해야할 작업만을 가지고있자"는 개념.
- 구성 요소
1) JoinPoint = When 적용시점
2) PointCut = Where 적용위치(공통기능이 적용될 대상 지정.)
3) Advice = What 부가기능 구체적으로 정의
4) Aspect = What + Where 공통으로 사용되는 기능이 어디에적용되는지.
5) target = Who 핵심기능을 담고있는 모듈
6) Weaving = When + Where + Wha 처리과정.
7) Proxy = Weaving 을 통해 지정된 새로운 객체
- 특징
1) Proxy 패턴 기반.
: Proxy = 핵심기능의 실행을 다른 객체에게 위임하고 부가적인 기능만을 제공하는 객체.
: target(핵심기능을 수행하는 클래스)에 대한 Proxy를 만들어서 제공.
: Proxy는 Advice를 target에 적용할때 정의가 되며, 프로그램이 실행되는 시간(Runtime)중 Spring container가 초기화 되는 시점에 같이 생성됨.
: Proxy 를 쓰는 이유는 접근 제어 및 부가기능을 target에 추가하기 위함.
2) 사용자의 프로그램 실행 호출을 Proxy가 가로챔 (Intercept)
: 사용자의 target에 대한 호출을 가로챈 다음 Advice의 부가기능 로직을 수행한 뒤에 target의 핵심기능을 호출 (전처리)
: target의 핵심기능 로직을 호출한 뒤에 Advice를 수행하는 경우도 있음. (후처리)
3) 핵심기능 실행 시점 설정.
: 동적 Proxy를 기반으로 AOP를 구현하기 때문에 Proxy의 적용시점을 지정할 수 있음.
: target의 핵심기능이 호출되는 runtime 시점에만 Advice를 적용할 수 있음.
- AOP구현 방법.
1) 공통적인 부가기능을 정의하여 사용할 클래스를 만들고 @Aspect 애너테이션 적용
2) 공통기능을 실행시킬 지점을 정의하고 @Pointcut 애너테이션적용 => "어떤 핵심기능이 작동할 때 부가기능이 실행되는가"
3) Advice가 담긴 메소드가실행될 시점을 적용하고 Advice와 연결할 핵심기능을 지정 (@Pointcut이 적용된 메소드이름 또는 직접 명시)
→ 하나의 Pointcut(주기능)에 여러개의 Advice가 적용이 될 경우에는 @Aspect의 아래에 @Order로 순서를 정해줌.
→ 하나의 @Aspect 안에 여러개의 Pointcut과 여러개의 Advice가 존재할 수 있고 서로 연결해주면 됨.
→ Advice 동작시점은 애너테이션으로 지정함.
① @Around : 핵심기능이 실행되기 전과 후에서 모두 동작.
② @Before : 핵심기능이 실행되기 전에 동작.
③ @After : 핵심기능 실행 후에 동작.
④ @AfterReturning : 핵심기능이 성공적으로 반환한 후에 동작.
⑤ @AfterThrowing : 핵심기능 실행중 예외가 발생했을 때 동작.
4) Adivce에서 핵심기능을 실행시킬 시점을 지정(애너테이션지정).
→ Advice 가 핵심기능 모듈의 정보를 담고있는 JoinPoint를 파라미터로 받아야함.
→ @Around Advice는 proceed() 메소드로 핵심기능의 실행시점을 제어해야하기 때문에 JoinPoint를 상속받은 ProceedingJoinPoint 객체를 파라미터로 받아야함.
→ 실행 시점은 (before, after-returning, after-throwing, after, around)
→ JoinPoint 인터페이스가 제공하는 메소드
① Signature getSignature( ) : 호출되는 핵심기능에 대한 정보를 구함.
② Object getTarget( ) : 핵심기능 객체를 구함.
③ Object[ ] getArgs( ) : 사용자가 핵심기능을 이용하기위해 입력한 파라미터값의 목록을 구함.
!!!!! JoinPoint 인터페이스가 제공하는 Signature API가 가지고 있는 메소드
① String getName( ) : 호출되는 메소드의 이름을 구함.
② String toLongString( ) : 호출되는 메소드를 완전하게 표현한 문장을 구함. (리턴타입, 파라미터타입 모두 표시)
③ String to ShortString( ) : 호출되는 메소드를 축약해서 표현한 문장을 구함. (메소드 이름만)
DB연동
: JDBC(Java DataBase Connetivity)는 자바에서 데이터베이스에 접속할수 있게 해주는 자바 API
: JDBC 프로그래밍 = Java를 이용해서 데이터베이스와 연동해 원하는 작업을 처리하는 프로그램을 작성.
: Spring은 JDBC의 구조적인 반복을 줄이기 위해 템플릿메소드 패턴과 전략패턴을 엮은 JdbcTemplate클래스를 제공함.
: 외부적으로는 MyBatis와 JPA 프레임워크를 구현하여 많이 사용함.
<MariaDB와 Intellij 연동>
- MariaDB 다운로드(https://mariadb.org/) [무료] → '데이터베이스' 폴더 설치방법 파일 참고
- HeidiSQL 기본제공, MySQL의 Workbench
- UTF-8설정, ROOT 계정에 대한 패스워드 기억필요.
-
ROOT 계정으로 접속후 데이터베이스 생성 → 사용자 계정생성 → 계정 내 권한 부여
-
Intellij의 오른쪽의 DataBase 메뉴를 이용해서 Data Source → MariaDB설정.
-
프로젝트 내 MariaDB 연동
─src
└ build.gradle의 dependencies내 implementation 'org.mariadb.jdbc:mariadb-java-client:3.0.3' 추가 → JDBC Driver 추가
<JDBC 프로그램 구조및 작성순서>
: JDBC 드라이버에서 제공하는 API를 이용.
→ java.sql 또는 javax.sql의 인터페이스를 구현하고 있음.(Connection, Statement/PreparedStatement, ResultSet, DataSource 등)
1) 네트워크를 통해서 데이터 베이스와 연결.
2) 데이터 베이스에 보낼 SQL을 작성하고 전송.
3) 데이터 베이스가 보낸 결과를 받아서 처리.
4) 데이터 베이스와 연결을 종료.
!!!!!!JDBC 연결 테스트
< Junit >
: Java에서 독립된 단위테스트(Unit Test : 특정 소스코드의 모듈이 의도한 대로 작동하는지 검증하는 테스트)를 지원해주는 프레임워크
: 스프링 컨테이너안의 Bean을 테스트 할 수 있음.
-
특징
: 단정 메소드 assert( )로 테스트케이스 결과를 판별 ex) assertEquals(예상값, 실제값)
:@Test애너테이션을 제공하여 테스트 코드 구별.
: 각 @Test 메소드 호출시 새로운 인스턴스를 생성하여 독립적인 테스트가 이루어지도록 함. -
애너테이션 종류
1)@Test: 테스트 수행코드를 가진 메소드
2)@Before: 테스트 메소드가 실행되기 전 반드시 실행되어야함.
3)@After: 테스트 메소드가 실행 된 후 반드시 실행되어야함.
4)@Ignore: 테스트 Skip.
---------(gradle 프로젝트 사용시 )------------
라이브러리를 이용한 JDBC 구현
: 코드의 재사용 및 부품화 실현, 소스를 제공하지않음으로서 중요 기술의 유출 방지, 개발 시간 단축, 반복적인 코드의 생략등을 위해 라이브러리 사용.
1) Lombok
: 코드 작성시 반복되는 코드의 수를 줄여주는 코드 다이어트 라이브러리.
: 여러 애너테이션을 제공하며, 이를 기반으로 반복 소스코드를 컴파일 과정에서 생성해주는 방식으로 동작
==> 클래스에 애너테이션만 존재하지만 실제로 컴파일된 .class 파일에는 코드가 생성되어 있음.
==>─ src
└ build.gradle의 dependencies내 compileOnly 'org.projectlombok:lombok:1.18.24'
annotationProcessor 'org.projectlombok:lombok:1.18.24' 추가
@Getter: 접근자. VO타입의 클래스에 설정(데이터를 보관하며 읽기전용.)@Setter: 설정자@ToString: toString( ) exclude속성을 사용하여 특정 필드를 제외시킬수 있음.@NoArgsConstructor: 파라미터가 없는 기본 생성자. (Mapper 이용시에 필요.)@AllArgsConstructor: 모든 필드값을 파라미터로 받는 생성자. (Mapper 이용시에 필요.)@RequiredArgsConstructor: final이나 NonNull인 필드값만 파라미터로 받는 생성자.@EqualsAndHashCode: 빈 생성할때 사용. callSuper 속성을 통해 부모클래스의 필드까지 고려할지 안할지 설정 할 수 있음.@Data: Getter, Setter, EqualsAndHashCode, RequiredArgsConstructor, ToString기능 모두 포함.@Builder: 필요한 데이터만 설정 가능
: 유연성 확보
: 가독성 ↑
: 변경가능성 최소화@Cleanup: DB연동후 연결 해제 할때 close() 처리코드를 자동으로 생성해줌.
: 별도의 try, catch, finally 코드가 필요하지 않아 코드가 간결함.
: but Lombok 라이브러리에 종속적
2) HikariCP
: 가벼운 용량과 빠른 속도를 가지는 JDBC의 커넥션 풀 프레임워크
: HikariCP의 정보를 담고 있는 싱글턴 객체 (enum)을 작성하고 실제 처리 코드에서는 instance를 호출하여 사용.
: https://github.com/brettwooldridge/HikariCP
─src
└ build.gradle의 dependencies내 implementation group: 'com.zaxxer',name: 'HikariCP', version: '5.0.0' 추가
3) ModelMapper
: 비슷한 구조의 객체를 복제하는 작업에 유용
: 어떤 Object에 있는 필드값들을 원하는 Object타입으로 변환해줌.
: ModelMapper의 정보를 담고 있는 싱글턴 객체(enum)을 작성하고 실제 처리 코드에서는 instance를 호출하여 사용.
─src
└ build.gradle의 dependencies내 implementation group: 'org.modelmapper',name: 'modelmapper',version: '3.0.0' 추가
4) Log4j2 (Log for java)
: Apache에서 만든 로깅(프로그램이 실행되는 동안 일어나는 모든 정보를 기록하는 것)을 위한 자바 기반의 디버그용 라이브러리.
: System.out.print() 대신 사용. → 쓸모없는 리소스 낭비 방지, 시스템 성능 저하 방지.
: Appender를 통해 출력하며 출력 위치에 따라 종류가 달라짐
→ <Console>콘솔출력, <File>파일 출력, <RollingFile>조건에 따라 파일에 출력, <JDBC>RDB Table에 출력.
: setLevel이라는 명령어 로 logginlevel 설정 가능 → 설정한 level 보다 높은 level에 대한 logging message만 출력.
==> trace < debug < info < warn < error < fata
─src
└ build.gradle의 dependencies내
implementation group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.17.2'
implementation group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.17.2'
implementation group: 'org.apache.logging.log4j', name: 'log4j-slf4j-impl', version: '2.17.2' 추가
: 환경설정파일을 등록하여 출력에 대한 출력형태에 대해 정의.
─ main ─resources 마우스 우클릭 ─ new ─XML Configuration File 생성
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
<Appenders>
<!--콘솔-->
<Console name="console" target="SYSTEM_OUT">
<PatternLayout charset="UTF-8" pattern="%d{hh:mm:ss} %5p [%c] %m%n"/>
</Console>
</Appenders>
<Loggers>
<logger name="org.springframework" level="INFO" additivity="false">
<appender-ref ref="console"/>
</logger>
<logger name="net.ict" level="INFO" additivity="false">
<appender-ref ref="console"/>
</logger>
<root level="info" additivity="false">
<AppenderRef ref="console"/>
</root>
</Loggers>
</Configuration>