반응형

※ 서버의 상황

- DNS 서버 : G사에서 회사 도메인을 관리

- 메일 발송 서버 : E사, N사에서 메일 서버를 둠

- E사는 회사 ERP 메일이며, N사는 noreply 메일로 활용

- 메일 발송 시 같은 "@도메인.com"을 사용

 

이슈 : N사의 메일서버에서 사내 ERP 메일에 메일 발송 시 스팸처리 되는 이슈

원인 : 도메인 서버 레코드에 사내 ERP MX레코드 누락

해결 : 도메인 서버 레코드에 사내 ERP MX레코드 등록

※ 사내 ERP 메일 서버 담당자에게 문의 하여 해결

반응형
반응형

※ 서버의 상황

- DNS 서버 : G사에서 회사 도메인을 관리

- 메일 발송 서버 : E사, N사에서 메일 서버를 둠

- E사는 회사 ERP 메일이며, N사는 noreply 메일로 활용

- 메일 발송 시 같은 "@도메인.com"을 사용

 

이슈 : 회사 메일 서버에서 gmail로 메일이 발송이 안되는 이슈가 발생

 

원인 : 메일의 DNS의 인증이 필요하도록 google의 정책 변경

※ google의 정책 : DNS에 SPF인증을 해야 수신이 가능하도록 함.

 

대응

: E사의 gmail 메일 서버 발송 정책 : SPF 인증만으로 gmail 발송

- E사의 메일서버에 SPF를 G사의 DNS서버 Record에 등록시킴

 

: N사의 gmail 메일 서버 발송 정책 : SPF, DKIM, DMARC의 인증이 있어야 gmail 발송

- N사의 메일서버에 SPF, DKIM, DMARC를 G사의 DNS서버 Record에 등록시키려 했으나,

G사의 Record의 바이트수가 DKIM을 담을 수 없어 이슈 발생

- G사, N사 모두 DNS를 바꾸던지 Mail 서버를 바꾸라는 답변

- DNS 서버를 N사로 변경(G사의 도메인의 네임서버를 N사로 설정)

- N사의 메일서버에 SPF, DKIM, DMARC를 N사의 DNS서버 Record에 등록

반응형
반응형
에러 메시지 :
org.springframework.restdocs.snippet.SnippetException: The following parts of the payload were not documented

 

{
  "list" : [ {
    "name" : "ai1"
  }, {
    "name" : "ai2"
  }, {
    "name" : "ai5"
  }, {
    "name" : "ai8"
  } ]
}
 
원인 : 에러메세지 밑에 있는 필드를 restdocs로 작성하지 않았다 or 오타
 
해결 방법 : test에서 name이라는 필드의 값을 찾아서 추가 또는 수정해준다.

fieldWithPath("name").type(JsonFieldType.STRING).description("인공지능 인스턴스 이름"),

 
※ 단순히 restdocs에서 작성 하지 않은 것만 보여주는 것이다. 
반응형
반응형
환경 : 
  • cpu : Intel(R) Core(TM) i5-9400 CPUT @ 2.90GHz
  • hdd : 418GB
  • Memory : 8GB
  • OS : CentOS Linux release 7.9.2009 (64bit)
 
상황 : 젠킨스 설치 후 실행 시 서버가 켜지지 않음
Starting jenkins (via systemctl):  Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
 

 

journalctl -xe에서 에러 메시지 :
jenkins[9063]: jenkins: failed to find a valid Java installation systemd[1]: jenkins.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: jenkins.service: Failed with result 'exit-code'.
systemd[1]: Failed to start My Company Jenkins Controller.
 
원인 : Java 설치 경로를 찾지 못함

 

해결 방법
1) 젠킨스 포트 번호 맞추기
(8080가 기본 포트로 설정 되어있으나 8080을 Well-Known 포트처럼 암묵적으로 많이쓰기때문에 변경필요) 

- 젠킨스 config 수정

sudo vi /etc/sysconfig/jenkins


JENKINS_PORT="9100"

 

- 젠킨스 서비스 config 수정

sudo vi /usr/lib/systemd/system/jenkins.service


Environment="JENKINS_PORT=9100"

 

 

2) 자바 11 버전 업데이트 
- 기존 버전 1.8에서 11버전 다운로드
- 환경변수 세팅
 
3) firewall 설정
sudo firewall-cmd --permanent --service=jenkins --add-port=9100/tcp
sudo firewall-cmd --permanent --add-service=jenkins
sudo firewall-cmd --reload

 

 

4) 자바 candidates 추가

- 젠킨스 시작 config에 java 버전 명시

sudo vi /etc/init.d/jenkins


candidates="
/etc/alternatives/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/lib/jvm/java-11.0/bin/java
/usr/lib/jvm/jre-11.0/bin/java
/usr/lib/jvm/java-11-openjdk-amd64
/usr/bin/java
/usr/local/lib/zulu11/bin/java
"

 

 

5) 자바 버전 명시
- 젠킨스 서비스 config에서 자바 위치 지정
sudo vi /usr/lib/systemd/system/jenkins.service


Environment="JAVA_HOME=/usr/local/lib/zulu11"​
 
 ※ 모든걸 다 적용했는데도 젠킨스 서버 start가 실패하여 5)으로해결 함 
반응형
반응형

RDBMS

1. Oracle과 Mysql 비교

  Oracle Mysql
구조 DB 서버가 통합된 하나의 스토리지를 공유 DB서버 마다 독립적인 스토리지를 할당
조인방식 nested loop join, hash join, sort merge join 제공 nested loop join 제공
확장성 별도의 DBMS 설치해 사용할 수 없음 별도의 DBMS를 설치해 사용할 수 있음
메모리 메모리 사용율이 커서 최소 수백 MB이상이 되어 설치가능 메모리 사용율이 낮아서 1MB 환경에서도 설치 가능
구문이 상이함 (null 체크, 현재 시간, 페이징 처리등)

 

2. Index

2.1 인덱스란?

정의  쉽게 찾아 볼수 있도록 일정한 순서에 따라 놓은 목록
목적  원하는 값을 빠르게 찾는것이 목적(select 하기 위함, where절에 사용해야 의미가 있음)
특징  항상 최신 상태를 유지하고, 인덱스도 하나의 데이터베이스 객체로 약 10%정도 저장용량이 필요함
 인덱스를 저장할때 B-TREE 자료 구조를 사용함

※ B-Tree 자료구조

 데이터를 추가 할때 인덱스가 있을 경우 페이지 분할이 발생 할 수 있어 속도 이슈가 생길 수 있음.

 

2.2 인덱스 적용 기준

카디널리티가 높은(중복도가 낮은) 컬럼

where, join, order by 절에 자주 사용되는 컬럼

insert, update,delete가 자주 발생하지 않는 컬럼

규모가 작지 않은 테이블

 

2.3 클러스터링 인덱스

primary key나 not null과 unique로 지정할 수 있음(primary key가 우선순위가 높음)

실제 데이터 자체가 저장되고 테이블당 1개만 존재가 가능

 

2.4 논클러스터링 인덱스(보조 인덱스, 세컨더리 인덱스)

unique나 unique index, index로 지정이 가능

별도의 인덱스 페이지를 생성하고 테이블당 여러개가 존재 가능

※ 실제 데이터 페이지는 그대로 두고 리프페이지에서 실제 데이터 페이지 주소를 담고 있음

 

2.5 다수의 인덱스

※ 논클러스터링 인덱스로 쿼리 조회 과정

 실제 논클러스터링 인덱스 페이지에선 데이터페이지 주소가 아닌 클러스터링된 컬럼 값을 가지고 있어서 그 컬럼값으로 클러스터링 인덱스 페이지에서 루트페이지를 통해 리프페이지에서 조회함

 데이터 추가시 페이지 분할이 일어나면 많은 논클러스터링 데이터 페이지주소가 변경 될 수 있기 때문에 페이지주소가 아닌 컬럼 값을 가지고 있음

 

3. Join의 수행 원리 3가지

3.1 Nested Loop Join

2중 for문과 비슷

1:N의 관계일 때 1에 해당되는 소량의 데이터를 가진 테이블을 outer table로 설정, N에 해당되는 대량의 데이터를 가진 테이블을 inner table로 설정 해야 조회 속도가 빠름

인덱스에 의한 랜덤 엑세스를 기반으로 하고 있기 때문에 대량 데이터 처리시 불리함

outer table에 조인을 위한 적절한 인덱스가 생성되어있어야함

다수의 트렌젝션을 처리하는 온라인 트렌잭션인 OLTP성 환경에 적합

※ outer table = driving 테이블, inner table = driven table

 

3.2 Sort Merge Join

2중 for문이지만 join 컬럼 기준으로 sorting 후 join 시킴

join에 적절한 인덱스가 없을 경우 사용

대용량 자료를 join할때 사용

Equal join이 아닌 범위로 join 할 경우 사용(범위 join)

인덱스 사용에 따른 랜덤 엑세스의 오버헤드가 많은 경우 사용

 

3.3 Hash Join

• inner table이 대용량일 때 outer join을 bulid input으로 삼아서 hash영역에 저장

※ hash 영역은 PGA(메모리)영역이기 때문에 처리속도가 빠름

  Hash영역으로 올라갈때 join 컬럼을 기준으로 Hash function이 적용 되기 때문에 key 컬럼에 중복값이 적을 수록 유리

배치에서 쓰면 좋은 수행원리, 대용량 table join 시 유리

Hash 영역에 들어간 테이블 사이즈가 너무 크면 PGA영역의 메모리를 넘어 디스크영역을 사용하기 때문에 성능에 불리

반응형
반응형

SPRING

1. 스프링이란

 자바의 오픈 소스 애플리케이션 프레임워크중 하나로 스프링의 기본 철학은 특정  기술에 종속 되지 않고 객체를 관리할 수있는 프레임워크를 제공하는것

컨테이너로 자바객체를 관리하면서 의존성 주입과 제어의 역전을 통해 결합도를 낮춤

 

2. DI

2.1 DI란

Dependency Injection 의존성 주입

객체간 의존관계를 미리 설정해두면 스프링 컨테이너가 의존 관계를 자동으로 연결해줌

컴포넌트 스캔을 통해 하기의 어노테이션이 붙어있으면 자동으로 스프링 빈에 등록해줌 

- @Component : 컴포넌트 스캔에서 사용

- @Controlller : 스프링 MVC 컨트롤러에서 사용

- @Service : 스프링 비즈니스 로직에서 사용

- @Repository : 스프링 데이터 접근 계층에서 사용

- @Configuration : 스프링 설정 정보에서 사용

생성자 주입 시 @Autowired를 쓰거나, 롬복의 @RequireArgsConstructor를 사용

 

2.2 DI 하는 방법 및 장단점

DI 방법 장점 단점
필드 주입  코드가 간결  변경 불가
 프레임워크에 의존적
 테스트 코드 작성시 객체수정이 불가
setter 주입  객체 생성 이후에도 객체 변경가능
 선택적으로 생성해야하는 객체나 변경이 발생하는 의존관계에서 사용
 public으로 구현하기 때문에, 관계를 주입 받는 객체의 변형 가능성을 열어둠
생성자 주입  생성자의 호출 시점에 1회 호출 되는 것이 보장
 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해
 

 

3. IoC (Spring 3대요소 중 하나)

Inversion of Control 제어의 역전

제어권이 사용자에게 있지 않고 프레임워크에 있어서 필요에 따라 사용자의 코드를 호출함

스프링에서는 인스턴스의 생성부터 소멸까지 개발자가 아닌 컨테이너에서 대신 관리함

 

4. AOP (Spring 3대요소 중 하나)

4.1 설명

관점 지향 프로그래밍

여러 객체에 공통으로 적용 할 수 있는 기능을 분리하여 개발자는 반복작업을 줄이고 핵심 기능 개발에만 집중할 수 있음

Object Oriented Programming(객체지향 프로그래밍)을 보완 할 수 있는 패러다임

※ 여러 오브젝트에 나타나는 공통 부가기능을 모듈화하여 재사용

 

4.2구현 방법

※어떤 부가기능을 어디에 적용시킬지 파악

Advice 

- Joinpoint에서 실행되어야 하는 프로그램 코드

- 독립된 클래스의 메소드로 작성
- 실질적으로 어떤 일을 해야할 지에 대한 것, 실질적인 부가기능을 담은 구현체
- 관심사를 구현한 소스코드

- 종류 5가지

@Before : 메서드가 실행되기전에 사용되는 Advice

@AfterReturning: 메서드가 정상적으로 실행되었을 때 사용되는 Advice

@AfterThrowing : 메서드가 예외를 발생 시켰을 때 사용되는 Advice

@After : 메서드가 정상적으로 실해되거나, 예외를 발생시켰을때 사용되는 Advice

@Around : 비지니스 로직 전후 실행되는 Advice

 

 JoinPoint

- Advice가 적용 될 수 있는 위치, 어플리케이션 실행 흐름에서의 특정 포인트(AOP를 적용할 수 있는 지점)를 의미

- 메소드를 호출하는 '시점', 예외가 발생하는 '시점'과 같이 애플리케이션을 실행할 때 특정 작업이 실행되는 '시점'을 의미
- Advice를 적용할 수 있는 후보 지점 혹은 호출 이벤트
- Advice가 적용될 위치, 끼어들 수 있는 지점. 메서드 진입 지점, 생성자 호출 시점, 필드에서 값을 꺼내올 때 등 다양한 시점에 적용가능
- 관심사를 구현한 코드를 끼워 넣을 수 있는 프로그램의 이벤트를 말하며, 예로는 call events, execution events, initialization events 등이 있음

 

PointCut

- joinpoint의 상세한 스펙을 정의한것, 언제 Advice를 실행할지를 정의
- Target 클래스와 Advice가 결합(Weaving)될 때 둘 사이의 결합규칙을 정의
- 예로 Advice가 실행된 Target의 특정 메소드 등을 지정
- JoinPoint의 상세한 스펙을 정의한 것. 'A란 메서드의 진입 시점에 호출할 것'과 같이 더욱 구체적으로 Advice가 실행될 지점을 정할 수 있음
- 관심사가 주프로그램의 어디에 횡단될 것인지를 지정하는 문장이며, 에로는 before call(public void update*(...))등이 있음

 

5. PSA (Spring 3대요소 중 하나)

Portable Service Abstraction. 필요에 따라 바꿔 끼울 수 있는 서비스 추상화

 Service Abstraction으로 제공되는 기술을 다른 기술 스택으로 간편하게 바꿀 수 있는 확장성을 갖고 있는 것

 

6. servlet Filter, Spring Interceptor, AOP의 차이

6.1 호출 순서

 Filter → Interceptor → AOP → Controller → AOP → Interceptor → Filter

 

6.2 Filter

요청과 응답을 거른뒤 정제하는 역할

Dispatcher Servlet 이전에 실행

 지정된 자원의 앞단에서 요청 내용을 변경하거나, 여러가지 체크를 수행

자원 처리가 끝난 후 응답 내용에서도 변경 처리 가능

일반적으로 인코딩 변환, XSS 방어등 요청에 대한 처리로 사용

Init() : 필터인스턴스 초기화

 doFilter() : 전/후 처리

 distroy() : 필터인스턴스 종료

 

6.3 Interceptor

요청에 대한 작업 전/후로 가로챔(Dispatcher Servlet, controller 호출 전/후)

스프링 컨텍스트(context 영역) 내부에서 Controller(Handler)에 관한 요청과 응답에 대해 처리

스프링의 모든 빈 객체에서 접근 가능

 인터셉터 여러개 사용가능(로그인, 권한, 로그 등)

preHandler() : 컨트롤러 메서드 실행전

postHandler() : 컨트롤러 메서드 실행후 view 페이지 렌더링 전

afterCompletion() : view 페이지가 렌더링 된 후

 

6.4 스프링 프레임워크 동작 순서 

 

HTTP 요청 → 핸들러 조회  핸들러 어댑터 조회  핸들러 어댑터 실행  핸들러 실행  ModelAndView 반환 viewResolver 호출  View 반환  뷰 렌더링 HTML 응답

 

※ 스프링 프레임워크 단순 버전

HTTP 요청 → DispatcherServlet에서 매핑할 컨트롤러가 있는지 HandlerMapping에서 조회 → controller 실행 → 요청 처리 후 결과를 출력한 view 이름을 DispatcherSerlvet에 리턴 → 컨트롤러에 보내온 View이름을 ViewResolver에게 전달 → 처리결과를 View에 송신 → Dispatcher서블릿에서 클라이언트에게 최종 결과 출력

 

7. @Bean이 무엇인지, new 연산자를 통해 오브젝트를 생성하는것과 무슨 차이가 있는지

 @Bean

 - 스프링 컨테이너가 관리하는 자바 객체

 - Bean의 등록 방법

   : @Component 에노테이션을 사용하면 컴포넌트 스캔이 자동으로 이루어짐

   : @Configuration에 직접 @Bean 어노테이션 사용

• new 연산자와 @Bean을 주입 받는것의 차이점

 - new 연산자는 실행되는 시점에 인스턴스를 생성

 - @Bean은 @Bean에 등록된 이미 존재하는 인스턴스를 프로그램에 맞도록 주입 시켜줌

 - @Bean 등록 시 싱글톤으로 관리되어 같은 객체 주소를 참조함

※ 클래스간 결합도를 낮추고 응집도를 높임

 

8. 싱글톤

8.1 싱클톤이란

 객체의 인스턴스가 오직 한개만 생성되는 디자인 패턴

메모리낭비 방지, 속도가 빠름, 데이터 공유가 쉬움

 

8.2 싱글톤의 단점

싱글톤인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시키면 다른 클래스간의 결합도가 높아짐

개방 폐쇄 원칙에 위배(확장에는 열려있고 수정에는 닫혀있는 원칙)

 

8.3 스프링에서 싱글톤

스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리

객체 인스턴스를 공유하기 때문에 객체 상태를 유지하게 설계하면 안됨

 

9. Spring과 Spring Boot의 차이점

  스프링 프레임워크 스프링 부트
Dependency  dependency를 설정해줄 때 설정 파일이 매우 길고, 모든 dependency에 대해 버전 관리도 하나하나 해줘야 함  dependency를 Spring Framework보다 쉽게 설정해 줄 수 있고, 라이브러리간 버전 관리도 자동으로 해줌
AutoConfiguration configuration설정을 할 때 매우 길고, 모든 어노테이션 및 빈 등록 등을 설정해 줘야함 application.properties파일이나 application.yml파일에 설정하면 됨
편리한 배포 war파일을 Web Application Server에 담아 배포 Tomcat 이나 Jetty 같은 내장 WAS를 가지고 있기 때문에 jar 파일로 간편하게 배포

※ 스프링부트의 단점: 대부분 만들어져있고 확장이 가능하기 때문에 소스를 분석하거나 로직을 이해할 때 깊숙히 파고들어야함

 

 

10. Spring data JPA

10.1 영속성 컨텍스트란?
 객체지향 적인 코딩이 가능
 컬럼 추가시 쿼리를 작성할 필요없이 필드만 추가하면 됨
 특징 : 영속성 컨텍스트라는 것이 존재함으로 인해 발생하는 특징들이 생김
 같은 키로 조회하면 항상 동일한 오브젝트가 리턴되는것이 보장됨
 더티체킹, 엔티티의 변경된 부분만 찾아서 업데이트 함
 지연된 쓰기 지연, Create, Update, Delete시 쿼리를 캐시에 저장하고 있다가 한번에 처리함


10.2 N+1 문제가 무엇인가? 어떻게 해결할 수 있는가?

 

10.3 단방향 연관관계, 양방향연관관계를 설정해야 하는 경우는?


10.4 양방향연관관계에서 연관관계의 주인은 어디에 설정해야하나?


10.5 영속성전이(Cascade)에 대하여


10.6 연관관계가 없는 컬럼끼리 조인을 해야 하는 경우가 있음


10.7 연관관계가 복잡한 쿼리는 JPA로 힘든 부분이 있을것 같은데 어떻게 처리 했는지

 

 

 

반응형
반응형

JAVA

1. 기본형 변수 타입

  1 byte 2 byte 4 byte 8 byte
논리형 boolean      
문자형   char    
정수형 byte short int long
실수형     float double

※ 1 byte = 8 bit

 

2. 인자(argument)와 매개변수(parameter)

 호출할때 "인자"를 전달 한다고 표현

 메서드를 만들때 "매개변수"를 지정했다고 표현

 

3. 오버로딩 VS 오버라이딩

 오버로딩 : 기존에 없던 새로운 메서드를 정의 하는것 (같은 메서드명, 다른 매개변수)

 오버라이딩 : 상속 받은 메서드의 내용을 변경하는것(메서드 재정의)

 

4. 추상클래스(abstract) VS 인터페이스(interface)

 추상 클래스 : 추상메서드가 하나이상 포함되어있어야함, 상속되어 구현되는것이 목적

 인터페이스 : 모든 메서드가 추상 메서드로 정의 되어있어야 함, 인터페이스를 구현한 객체들은 같은 메서드가 있다는 보장

 

5. 자바 에플리케이션 실행 과정

 자바 소스 코드 : 개발자가 Java로 작성한 소스 파일로 확장자 명은 .java

 자바 바이트 코드 : 클래스코드가 읽을 수 있도록 컴파일된 파일 확장자명은 .class

 Methode Area : 클래스가 사용되면 클래스별로 클래스 정보가 저장되는 영역(static 변수, static 메소드 등)

 Heap Area : 인스턴스가 생성되는 영역 (Garbage Collection의 대상이 되는 영역)

 Stack Area : 메서드 실행에 필요한 메모리 공간(매개변수, 지역변수, 리턴정보등 을 저장)

 PC Register : 현재 수행중인 JVM 명령어가 저장

 Native Method Area : 자바 외의 언어 (C, C++ 등)를 수행하기위한 영역

 

6. 가비지 컬렉션(Garbage Collection)

JVM에서 메모리를 관리해주는 모듈

Heap 메모리를 재활용 하기 위해 더이상 참조하지 않는 인스턴스들을 메모리에서 제거

개발자가 직접 메모리를 정리하지 않아도 됨

참조 되지 않는 객체를 찾는 과정에서 Mark and Sweep이 발생하여 스레드가 잠깐 멈춤

 

 

7. 객체 지향 프로그래밍

 현실 세계의 사물과 같은 객체를 만들고, 객체에 필요한 특징을 뽑아 프로그래밍을 수행

 특징

    - 추상화 : 객체들의 공통적인 특징(기능, 속성)을 도출하는 것

    - 캡슐화 : 실제 구현되는 부분을 외부에 드러나지 않도록 은닉

                    객체가 독립적으로 역할을 수행하도록 데이터를 하나로 묶어 관리 (응집도가 높아짐)

                    데이터를 보이지 않고 외부와 상호작용을 할 때 메서드를 이용 (결합도가 낮아짐)

    - 상속성 : 하나의 클래스가 가진 특징(함수, 데이터)을 다른 클래스가 그대로 물려받는것

    - 다형성 : 약간 다른 방법으로 동작하는 함수를 동일한 이름으로 호출하는것 (오버로딩, 오버라이딩)

 

 좋은 객체 지향 설계의 5가지 원칙(SOLID)
    - SRP 단일 책임 원칙 : 한 클래스는 하나의 책임만 가져야한다.
변경이 있을때 파급효과가 적으면 단일 책임 원칙을 잘 따른것 (객체의 생성과 사용을 분리)
※ 책임의 범위를 잘 조절해야함

    - OCP 개방 폐쇄 원칙 : 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야한다. (다형성)
역할과 구현을 분리, 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는것.

    - LSP 리스코프 치환 원칙 : 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다.
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 함. 컴파일은 잘 되더라도 규약을 위배하면 LSP 위반.
자동차 인터페이스의 엑셀은 앞으로가라는 기능, 뒤로가게 구현하게되면 LSP 위반, 느리더라도 앞으로가야함.

    - ISP 인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다.
자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
인터페이스가 명확해지고, 대체 가능성이 높아짐

    - DIP 의존 관계 역전 원칙 : 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
스프링의 의존성 주입은 이 원칙을 따르는 방법중에 하나.
클라이언트 코드가 구현 클래스를 바라보지 말고 인터페이스를 바라보라는 뜻.
역할에 의존해야지 구현에 의존하지 말라는것.
의존 = 내가 그 코드를 안다.

 

 

8. 컬렉션 프레임 워크

8.2 Java 컬렉션 프레임워크 구조도

데이터 군을 저장하는 클래스를 표준화 한 설계

List  순서가 있는 데이터 집합, 데이터의 중복을 허용함
 ArrayList, LinkedList, Stack, Vector
Set • 순서를 유지 하지 않는 데이터 집합, 데이터 중복을 허용하지 않음
HashSet, TreeSet
Map 키와 값의 쌍으로 이루어진 데이터 집합, 순서유지가 안됨, 키는 중복이 불가, 값은 중복이 가능
HashMap, TreeMap, HashTable

8.2 List

순서가 있고 중복을 허용, 인덱스로 원소에 접근이 가능, 크기가 가변적

ArrayList

      ◦ 배열을 기반으로 데이터를 저장

      ◦ 단반향 포인터 구조로 데이터 순차적 접근에 강점

      ◦ 데이터 삽입, 삭제에 불리하나, 순차적 추가/삭제는 빠름

      ◦ 임의의 요소에 대한 접근성이 뛰어남

 LinkedList

      ◦ 연결 기반으로 데이터를 저장

      ◦ 각 요소(node)들은 자신과 연결된 다음요소에 대한 참조 주소값과 데이터로 구성되어있음

      ◦ 양방향 포인터 구조로 데이터 삽입, 삭제가 빠름

       임의의 요소에 대한 접근성이 안좋음

 

8.3 Set

 순서가 없고 중복된 데이터를 허용하지 않음, 중복되지 않은 데이터를 구할 때 유용, 빠른 검색 속도를 가짐

HashSet

      ◦ 인스턴스의 해시값을 기준으로 저장하기 때문에 순서를 보장하지 않음

      ◦ NULL 값을 허용
      ◦ TreeSet보다 삽입, 삭제가 빠름

LinkedHashSet 

      ◦ 입력된 순서를 보장

 TreeSet

      ◦ 이진 탐색 트리(Red-Black Tree)를 기반으로 함
      ◦ 데이터들이 오름차순으로 정렬
      ◦ 데이터 삽입, 삭제에는 시간이 걸리지만 검색, 정렬이 빠름

 

8.4 Map

Key와 Value의 한쌍으로 이루어지는 데이터의 집합. Key에 대한 중복이 없으며 순서를 보장하지 않음, 뛰어난 검색 속도

 HashMap
      ◦ Key에 대한 중복이 없으며 순서를 보장하지 않음
      ◦ Key와 Value 값으로 NULL을 허용
      ◦ 동기화가 보장되지 않음
      ◦ 검색에 가장 뛰어난 성능을 가짐
 HashTable
      ◦ 동기화가 보장되어 병렬 프로그래밍이 가능하고 HashMap 보다 처리속도가 느림
      ◦ Key와 Value 값으로 NULL을 허용하지 않음
 LinkedHashMap
      ◦ 입력된 순서를 보장
 TreeMap
      ◦ 이진 탐색 트리(Red-Black Tree)를 기반으로 키와 값을 저장
      ◦ Key 값을 기준으로 오름차순 정렬되고 빠른 검색이 가능
      ◦ 저장 시 정렬을 하기 때문에 시간이 다소 오래 걸림

 

9. HashTable

※ 해시함수(key) → 해시코드 Index   Value

검색하고자하는 key 값을 입력 받아 해시함수로 로직을 수행

반환된 해시코드를 배열의 Index로 환산하여 데이터에 접근 하는 자료구조

 

10. String, StringBuffer, StringBuilder

10.1 String VS StringBuffer, StringBuilder

String : 불변의 속성을 가짐

// ① 메모리 할당
String str = new String("hello");

// ② 기존 메모리가 아닌 새로운 메모리에 할당
str = str+" world";

 

 StringBuffer, StringBuilder

// ① 메모리할당
StringBuffer sb = new StringBuffer("hello");

// ② 기존 메모리에 append
sb.append(" world");

 

10.2 StringBuffer VS StringBuilder

StringBuffer : 동기화 키워드를 지원하여 멀티스레드 환경에서 안전함

StringBuilder : 동기화 지원이 안되지만 단일스레드 환경에서 성능이 좋음

 

11. 제네릭스(Generics)

 다양한 타입의 객체들을 다루는 메서드나 컬렉션에 컴파일 시 타입을 체크해주는 기능(JDK 1.5에 도입)

 타입의 안정성 제공

 타입체크와 형변환을 생략할 수 있어 코드가 간결해짐

 

12. CheckedException과 UnCheckedException

  CheckedException UnCheckedException
처리여부 개발 시 반드시 예외를 처리해야함 예외 처리를 강제 하지 않음
확인시점 컴파일 단계 실행단계(Run Time)
예외 종류 RunTimeExcepion을 제외한 모든 예외
SQLException
IoException
RunTimeException 하위 예외
NullPointException
IndexOutOfBoundException

 

13. int와 double, Integer와 Double등의 래퍼 타입과 Primitive 타입의 차이점

 Primitive 타입은 변수에 값자체를 저장하지만 래퍼타입은 변수에 객체의 주소 값을 저장

int에는 null을 넣을수 없지만 Integer는 객체이기 때문에 null 입력이 가능

Boxing : Primitive 타입을 래퍼타입으로 바꾸는것

UnBoxing : 래퍼타입을 Primitive 타입으로 바꾸는것

 

14. 익명 클래스와 람다 표현식의 차이

 익명 내부 클래스는 새로운 클래스를 생성하지만, 람다는 새로운 메서드를 생성하여 포함.
 내부 클래스는 새로운 클래스파일이 생성
 람다는 static 이든, 객체 사용을 위한 non-static 이든, 메서드로 생성.
익명 내부 클래스의 this : 새로 생성된 클래스, 람다의 this : 람다식을 포함하는 클래스

람다표현식이 클래스 정의와 구현을 동시에 하여 코드가 더 간결함

프로그램 내에서 한번 만 객체로 만드는데 클래스를 정의하고 생성하는 것이 비효율적 

 

15. 스레드를 생성하는 방법

 Runnable 인터페이스를 Implements 하여 run 메서드를 정의

Thread 클래스를 상속 받아 run 메서드를 오버라이딩

 

 

JSP

1. Servlet과 JSP, MVC

Servlet

 - 자바 소스코드에서 response로 PrintWriter객체에 HTML 소스를 삽입하여 response를 함

 - 웹페이지를 동적으로 생성하기 위한 서버측 프로그램

 - 자바를 기반으로 만들어지면 WAS위에서 컴파일되고 동작함

 

JSP

 - JavaServerPage의 약자로 HTML 소스에 스클립틀릿(<% ... %>)에 자바소스를 작성

 - 웹페이지를 동적으로 생성하기 위한 웹 어플리케이션 도구

 - Java 기반의 서버사이드 스크립트 언어

 ※ 스크립트 언어란 컴파일 없이 내장된 번역기로 실행할 수 있는 프로그래밍언어

 - JSP 컨테이너에서 서블릿을 생성하여 컴파일 후 실행하는 구조

 

MVC

 - Model View Controller : 하나의 서블릿이나, JSP로 처리하던 것을 컨트롤러(Controller)와 뷰(View)라는 영역으로 서로 역할을 나눈 것

 - 컨트롤러: HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행.  뷰에 전달할 결과 데이터를 조회해서 모델에 담음.

 - 모델: 뷰에 출력할 데이터를 담아서 뷰에 전달함. 따라서 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있음

 - 뷰: 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중. (HTML을 생성하는 부분)

 

 

2. EL과 JSTL

JSP 작성을 도와주는 언어와 라이브러리

EL

 - Expression Language

 - JSP에서 객체의 값을 쉽게 꺼내 쓸수 있는 도구

 - HTML : <span>${prod.no}</span>

 - Javascript : "${prod.no}"

 - 스크립틀릿안에서 값을 가져오고 할당할 필요가 없음

      <%=((Product)request.getAttribute("prod")).getNo()%>

 

JSTL

 - JSP Standard Tag Library

 - 일반적으로 JSTL + EL의 조합을 의미함

 - JSP에서 자주 사용하는 스클립틀릿을 하나의 태그로 묶은 라이브러리

 ex) <c:set>, <c:if>, <c:forEach> ...

 

※ <c:out> 태그를 쓰는 이유

- Cross-site Scripting 공격은 스크립트를 주입시켜서 사이트를 침입

- c:out 태그를 사용할 시에 이 HTML에서 사용하는 특수 문자를 HTML 엔티티로 변경해줌(escape)

- 크로스 사이트 스크립팅을 막아줌

반응형
반응형

프로젝트 생성 - STS 4.x 세팅

1. 개발 툴 설치

1.1 STS 4.x 설치 : https://spring.io/tools

 

Spring | Home

Cloud Your code, any cloud—we’ve got you covered. Connect and scale your services, whatever your platform.

spring.io

 

1.2 H2 DB 설치 : https://www.h2database.com/html/download-archive.html

• 버전은 1.4.199 ZIP으로 다운로드

 

Archive Downloads

 

www.h2database.com

- H2 실행

zip파일 압축 해제 > h2경로의 bin 폴더 접근 > h2w.bat실행 > 브라우저에 창이 뜸 > localhost:8082로 입력

Generic H2 (Server) 선택 > JDBC URL에 jpa_study로 설정 > C:\Users\xxxxx에 jpa_study.mv.db명으로 빈 파일명 입력 > 연결 버튼 클릭

 

2. 프로젝트 세팅

2.1 신규 프로젝트 생성

• create a project 클릭 > Maven Project 선택 > Next 클릭

 

2.2 location 선택

• Next 클릭

 

2.3 maven 기본 틀 선택

• Filter에 org.apache.maven 검색 > artifact Id : maven-archetype-quickstart 선택 > next 클릭

 

2.4 프로젝트 세팅

• 내용 작성 > Finish 클릭

 

2.5 콘솔창에서 y 입력 후 엔터

 

2.6 maven 디팬던시 추가

• workspace\ex1-hello-jpa\pom.xml 열기

• 컴파일러 버전 수정 및 dependency 추가

javax.xml.bind 추가 이유 : JAVA11에서 에러 발생

 

plugin 추가

org.apache.maven.plugins 추가 이유 : JAVA11에서 에러 발생

 

※ pom.xml 전체 소스

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>jpa-basic</groupId>
  <artifactId>ex1-hello-jpa</artifactId>
  <version>1.0.0</version>

  <name>ex1-hello-jpa</name>
  <!-- FIXME change it to the project's website -->
  <url>http://www.example.com</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>

  <dependencies>
	<dependency>
		<groupId>javax.xml.bind</groupId>
		<artifactId>jaxb-api</artifactId>
		<version>2.3.0</version>
	</dependency>
	<!-- JPA 하이버네이트 -->
	<dependency>
		<groupId>org.hibernate</groupId>
		<artifactId>hibernate-entitymanager</artifactId>
		<version>5.3.10.Final</version>
	</dependency>
	<!-- H2 데이터베이스 -->
	<dependency>
		<groupId>com.h2database</groupId>
		<artifactId>h2</artifactId>
		<version>1.4.199</version>
	</dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <configuration>
            <source>8</source>
            <target>8</target>
          </configuration>
        </plugin>
		  
        <!-- clean lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#clean_Lifecycle -->
        <plugin>
          <artifactId>maven-clean-plugin</artifactId>
          <version>3.1.0</version>
        </plugin>
        <!-- default lifecycle, jar packaging: see https://maven.apache.org/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging -->
        <plugin>
          <artifactId>maven-resources-plugin</artifactId>
          <version>3.0.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.8.0</version>
        </plugin>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.22.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-jar-plugin</artifactId>
          <version>3.0.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-install-plugin</artifactId>
          <version>2.5.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-deploy-plugin</artifactId>
          <version>2.8.2</version>
        </plugin>
        <!-- site lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#site_Lifecycle -->
        <plugin>
          <artifactId>maven-site-plugin</artifactId>
          <version>3.7.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-project-info-reports-plugin</artifactId>
          <version>3.0.0</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
</project>

 

 

2.7 프로젝트 1.8로 세팅

• 프로젝트 우클릭 > properties 클릭 > Java Bulid Path 선택 > JRE System Library [JavaSE-1.7] 선택 > Edit 선택 > JavaSE-1.8(jre) 변경 후 Finish

 

 

2.8 JPA 세팅 정보 설정

• src/main/java 우클릭 > New > Package 클릭 > source folder에 java 삭제 후 name에 resources 입력 > Finish 클릭

• src/main/resources 우클릭 > New > Folder 클릭 > Folder name에 META-INF 입력 > Finish 클릭

• workspace\ex1-hello-jpa\src\main\resources\META-INF\persistence.xml 파일 생성

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.2"
	xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
	<persistence-unit name="hello">
		<properties>
			<!-- 필수 속성 -->
			<property name="javax.persistence.jdbc.driver" value="org.h2.Driver" />
			<property name="javax.persistence.jdbc.user" value="sa" />
			<property name="javax.persistence.jdbc.password" value="" />
			<property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/jpa_study" />
			<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect" />
			
			<!-- 옵션 -->
			<property name="hibernate.show_sql" value="true" />
			<property name="hibernate.format_sql" value="true" />
			<property name="hibernate.use_sql_comments" value="true" />
			<!-- <property name="hibernate.hbm2ddl.auto" value="create" />-->
		</properties>
	</persistence-unit>
</persistence>

 

 

3.  실행 테스트

 App.java에 테스트 코드 작성

package jpa_basic.ex1_hello_jpa;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

public class App {
	public static void main(String[] args) {
		EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
		
		EntityManager em = emf.createEntityManager();
		
		em.close();
		emf.close();
	}
}

실행

 - App.java 우클릭 > Run > Java Application 클릭

 - 로그

반응형
반응형

JPA와 모던 자바 데이터 저장기술

1. 현재 개발 트렌드

애플리케이션 : 객체지향 언어 (ex: [Java, Scala, Kotlin...])

데이터베이스 : 관계형 데이터 (ex: [Oracle, Mysql, PostgreSQL...])

 객체를 관계형 DB에 관리하는 것에 시간을 많이씀

객체 데이터, 데이터 객체 : SQL 중심적인 개발이 됨

 

 

2. SQL 중심적인 개발의 문제점

2.1 기능추가, 테이블 생성 될때마다 CRUD SQL을 다 만들어야함

(JdbcTemplate, MyBatis가 Mapping에 도움을 주는 것은 있지만 그래도 한계가 있음)

 

회원 객체의 CRUD가 구현되있는 상황

 - 기존 회원 객체 테이블 기능 쿼리 구현

/*회원 객체*/
public class Member {
	private String memberId;
	private String name;
}

/*쿼리*/
INSERT INTO MEMBER(MEMBER_ID, NAME) VALUES ...
SELECT MEMBER_ID, NAME FROM MEMBER M
UPDATE MEMBER SET .

- 전화 번호 필드를 추가해야하는 상황

/*회원 객체*/
public class Member {
	private String memberId;
	private String name;
	private String tel;
}
/*쿼리*/
INSERT INTO MEMBER(MEMBER_ID, NAME, TEL) VALUES ...
SELECT MEMBER_ID, NAME, TEL FROM MEMBER M
UPDATE MEMBER SET ...TEL = ?

※ 모든 CRUD에 TEL을 하나하나 추가해야함

※ SQL에 의존적인 개발

 

 

2.2 패러다임의 불일치 (객체 VS RDBMS)

관계형 데이터베이스와 객체지향은 사상이 다름
객체지향개발 : 추상화, 캡슐화, 정보은닉, 상속, 다형성등 시스템의 복잡성을 제어하는 다양한 장치들 제공
관계형데이터베이스 : 데이터를 잘 정규화해서 저장하는 것이 목표.


 객체를 관계형 데이터베이스에 저장하는 도식

※ 객체를 SQL로 변환해서 RDB에 저장하는 변환과정을 개발자가 해야함

 

 

3. 객체와 관계형 데이터 베이스의 차이

3.1 상속

객체 상속관계 VS Table 슈퍼타입 서브타입 관계

 객체의 상속관계와 유사한 관계형 데이터베이스의 개념으로 Table 슈퍼타입, 서브타입 관계가 있음
상속 받은 객체(Album, Movie, Book)을 데이터베이스에 저장하려면 복잡함
 - 객체 분해 : Album객체를 Item과 분리

- Item Table에 하나, Album테이블에 하나 두개의 쿼리를 작성해서 저장

 Album 객체를 DB에서 조회하는것도 복잡
 - SQL로 ITEM과 ALBUM을 조인해서 데이터를 가져옴

 - 조회한 필드를 각각 맞는 객체(ITEM, ALBUM)에 매핑시켜서 가져와야함
결론: DB에 저장할 객체는 상속관계를 쓰지 않음

 

 

3.2 연관 관계

객체 연관 관계 VS 테이블 연관 관계

 객체는 참조를 사용 : member.getTeam();
 테이블은 외래 키를 사용 : JOIN ON M.TEAM_ID = T.TEAM_ID


 Member와 Team간에 참조  
- 객체:  Member → Team 은 member.getTeam()을 통해 가능, Team → Member 는 참조할 객체가 없기 때문에 불가능
 - 테이블: 서로가 서로를 참조할 키(FK)가 있기 때문에 양측이 참조가 가능하다. Member ↔ Team


객체를 테이블에 맞춰 모델링, 테이블에 맞춘 객체 저장

/* 회원 객체 */
class Member{
	String id;        //MEMBER_ID 컬럼 사용
	Long teamId;      //참조로 연관관계를 맺는다.
	String username;  // USERNAME 컬럼 사용
}

/* 팀객체 */
class Team{
	Long id;      //TEAM_ID 컬럼 사용
	String name;  //NAME 컬럼 사용
}

/* 쿼리 */
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...
INSERT INTO TEAM(TEAM_ID, NAME) VALUES...

- 객체 지향적이지 못함

 

 객체다운 모델링, 객체 모델링 저장

/* 회원 객체 */
class Member{
	String id;        // MEMBER_ID 컬럼 사용
	Team team;        // Team 객체 참조로 연관관계를 맺음
	String username;  // USERNAME 컬럼 사용
    
    Team getTeam(){
        return team;
    }
}

/* 팀객체 */
class Team{
	Long id;      // TEAM_ID 컬럼 사용
	String name;  // NAME 컬럼 사용
}


/* 쿼리에 teamId를 저장하기 위해 꺼냄*/
member.getTeam().getId();


/*쿼리*/
INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...
INSERT INTO TEAM(TEAM_ID, NAME) VALUES...

 

객체 모델링 조회

SELECT M.*, T.*
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

public Member find(String memberId){
	//SQL 실행
	Member member = new Member();

	//데이터터베이스에서 조회한 회원 관련 정보를 모두 입력
	Team team = new Team();

	//회원과 팀 관계 설정
	member.setTeam(team);
	return member;
}

 

 객체 그래프 탐색

 - 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 함

 - Member 객체에서 엔티티 그래프를 통해 Category 까지도 접근이 가능해야 함

ex) member.getOrder().getOrderItem().getItem().getCategory;

 

처음 실행하는 SQL에 따라 탐색 범위가 결정

SELECT M.*, T.*
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

member.getTeam(); //OK
member.getOrder(); //null


class MemberService{
	...
	public void process(){
		Member member = memberDao.find(memberId);
		member.getTeam(); //????
		member.getOrder().getDelivery(); //????
	}
}

※ 엔티티 신뢰 문제가 발생

 - member안에 모든 참조를 자유롭게 참조 할 수 없음

 - 새로운 필드를 추가했는데 조회 로직에서 해당 부분 매핑을 빼놓을 가능성도 있음
 - 모든 코드와 쿼리를 분석해보기전까지는 엔티티 그래프 검색이 어디까지 되는지 확신할 수 없음 

 - 모든 객체를 미리 로딩할 수도 없음

memberDAO.getMember(); //Member만 조회
memberDAO.getMemberWithTeam(); //Member와 Team조회
memberDAO.getMemberWithOrderWithDelivery(); // Member, ORder, Delivery 조회
...

 

※ 기존의 방식으로는 계층형 아키택처, 진정한 의미의 계층분할을 구현 할 수 없음

 

 

4. 객체 비교

동일한 식별자(memberId)로 조회한 두 객체 비교

String memberId = "100";
Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);

member1 == member2; // false 다르다

class MemberDAO{
	public Member getMember(String memberId){
		String sql = "SELECT * FROM MEMBER WHERE MEMBER_ID = ?";
		...
		//JDBC API, SQL 실행
		return new Member(...);
	}
}

 - member를 조회할 때마다 new Member()를 통해 새로운 객체를 만들어서 조회 하기 때문에 두 인스턴스 비교는 내용물이 같더라도 참조값이 다름

 

• 자바 컬렉션에서 조회한 객체 비교

String memberId = "100";
Member member1 = list.get(memberId);
Member member2 = list.get(memberId);

member1 == member2; // true 같다.

 

※ 동일성과 동등성(Identical & Equality)
 - 자바에서 두 개의 오브젝트 혹은 값이 같은가
: 동일한 오브젝트라는 말(identical)은 같은 레퍼런스를 바라보고 있는 객체라는 말로 실제론 하나의 오브젝트라는 의미

: 동등한 오브젝트라는 말(Equivalent)은 같은 내용을 담고 있는 객체라는 의미 

 

 

 

 

※ 결론

객체지향적으로 모델링을 할 수록 매핑작업만 늘어나고 불일치가 늘어나서 사이드이펙트가 커지기만함. 
객체를 자바 컬렉션에 저장하듯이 DB에 저장하기위해 나온 것이 JPA

 

 

JPA (Java Persistence API)

1. 용어

 JPA : 자바진영의 ORM 기술 표준

 ORM

- Object-relational mapping(객체 관계 매핑)
- 객체는 객체대로 설계 하고, RDBMS는 RDBMS대로 설계해서 ORM 프레임워크가 중간에서 매핑 해줌
- 대중적인 언어에는 대부분 ORM 기술이 존재

 

2. JPA 동작 원리

2.1 애플리케이션과 JDBC 사이에서 동작함

 

2.2 저장

 

2.3 조회

 

3. JPA를 사용하는 이유

3.1 생산성

• 저장: jpa.persist(member)
• 조회: Member member = jpa.find(memberId)
• 수정: member.setName(“변경할 이름”)
• 삭제: jpa.remove(member)

※ CRUD가 간편함

 

3.2 유지보수

/*회원 객체*/
public class Member {
	private String memberId;
	private String name;
	private String tel;
}
/*쿼리*/
INSERT INTO MEMBER(MEMBER_ID, NAME, TEL) VALUES ...
SELECT MEMBER_ID, NAME, TEL FROM MEMBER M
UPDATE MEMBER SET ...TEL = ?

※ 기존에는 필드 변경시 모든 SQL을 수정했어야했으나, JPA는 필드만 추가하면 되고 SQL은 JPA가 수행함

 

 

3.3 패러다임 불일치 해결

• 상속

 - 상속되어 있는 객체의 저장

 : 개발자의 할일  jpa.persist(album);

 : JPA가 나머지 처리

 

 - 상속되어 있는 객체의 조회

 : 개발자가 할일 Album album = jpa.find(Album.class, albumId);

 : JPA가 나머지 처리

 

 

• 연관관계

 - 연관관계 저장

member.setTeam(team);
jpa.persist(member);

 

• 객체 그래프 탐색

Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam()

※ JPA로 계층 엔티티를 신뢰할수 있음

 

• 비교

String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);
member1 == member2; //같다

※ 동일한 트랜잭션에서 조회한 엔티티는 같음을 보장

 

 

3.4 성능 최적화 기능

 1차 캐시와 동일성 보장

String memberId = "100";
Member m1 = jpa.find(Member.class, memberId); //SQL
Member m2 = jpa.find(Member.class, memberId); //캐시
println(m1 == m2) //true

- 같은 트렌젝션 안에는 같은 엔티티를 반환(조회성능 향상)

- DB Isolation Level이 Read Committed이어도 애플리케이션에서 Repeatable Read 보장

- SQL을 한번만 수행함

 

※ DB Isolation Level(DB 격리 수준)

<아래로 내려갈수록 트랜잭션간 고립 정도가 높아지고 성능이 떨어짐>

 - READ UNCOMMITTED : 어떤 트랜잭션의 변경내용이 COMMIT이나 ROLLBACK과 상관없이 다른 트랜잭션에서 보여짐

 - READ COMMITTED : 어떤 트랜잭션의 변경 내용이 COMMIT 되어야만 다른 트랜잭션에서 조회할 수 있음

 - REPEATABLE READ : 트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회할 수 있는 격리수준

 - SERIALIZABLE : 읽기 작업에도 공유 잠금 설정, 동시에 다른 트랜잭션에서 이 레코드를 변경하지 못하게 됨

 

 

쓰기 지연

- insert

transaction.begin(); // [트랜잭션] 시작
em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

//커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
transaction.commit(); // [트랜잭션] 커밋

※ 트랜잭션을 커밋할 때까지 INSERT SQL을 모으고 JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송

 

- update

transaction.begin(); // [트랜잭션] 시작

changeMember(memberA);
deleteMember(memberB);
비즈니스_로직_수행(); //비즈니스 로직 수행 동안 DB 로우 락이 걸리지 않는다.

//커밋하는 순간 데이터베이스에 UPDATE, DELETE SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋

※ UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
※ 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋

 

 

지연 로딩

- 지연 로딩: 객체가 실제 사용될 때 로딩
- 즉시 로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회

반응형
반응형

OAuth 소개

1. 우리서비스를 이용하는 USER의 니즈

• 우리의 서비스를 이용하는 USER가 우리 서비스에서 일정을 관리하면 USER가 가입한 그들의 서비스에도 공유가 되는 기능이 필요함.

 

2. 구현 방법

• 우리의 서비스는 USER가 사용하고 있는 그들의 서비스에 접근할수 있도록 허가를 받고 그 서비스에 접근하여 기능을 수행.

• 우리의 서비스가 그들의 서비스에 접근하도록 허가를 받는 가장 간단한 방법

- USER가 그들의 서비스의 계정정보(ID,PW)를 우리 서비스에게 전달해서 그들의 서비스에게 허가 받음

하지만 우리의 서비스도, USER도, 그들의 서비스도 모두 불편....

 

3. OAuth가 하는일

• 우리의 서비스와 USER가 사용하고 있는 그들의 서비스의 안전한 상호작용을 가능하게 해줌

• USER의 계정 정보를 우리의 서비스에게 넘기는게 아니라 USER의 요청에 의해 그들의 서비스가 AccessToken이라는 일종의 비밀번호를 발급 (나의 서비스가 필요한 부분만 허용하는 비밀번호)

• 우리의 서비스가 OAuth를 통해 AccessToken을 획득한 후 AccessToken을 통해서 그들의 서비스에 접근 하여 데이터를 가져오고 수정하고 생성하고 삭제할 수 있음.

• 이걸 가능하게 해주는 기능이 OAuth

• USER의 계정 정보를 우리의 서비스에서 처음부터 보관하지 않고 회원을 식별할수 있는 기능을 구현할 수 있음

(USER가 가입한 그들의 계정을 통해 우리의 서비스에서 로그인 기능을 연동, federated identity라고함)

※ 이 기술의 기반 기술이 OAuth

 

 

OAuth의 3개의 주체

 USER = Resource Owner

 Mine(우리의 서비스) = Client

 Their(그들의 서비스) = Resource Server

 

 

OAuth의 등록 

※ 클라이언트가 리소스 서버를 이용하기 위해서는 리소스서버의 승인을 사전에 받아야 함

 

 서비스마다 등록 방법이 다르지만 공통적으로 리소스서버에서 제공하는 항목과 입력해야하는 항목이 3개 있음

 - Client ID : 애플리케이션을 식별하는 식별자

 - Client Secret : 애플리케이션에 대한 비밀번호

 - Authorized Redirect URIs : 리소스서버가 권한을 부여하는 과정에서 authorize code를 전달하는데 그 코드를 전달 받는 곳의 주소, 다른 주소에서 요청하면 무시하게됨

※ 리소스서버에서 이 세가지를 찾아서 확인 및 입력.

 

 

OAuth Resource Owner의 승인

Client에서 심어둔 리소스 서버 url로 링크

 - 회원 가입, 로그인 등 리소스 서버의 기능을 사용할 Client 페이지에 리소스 서버 링크추가

 - 리소스 서버 링크 예시 :  http://resource.server/?client_id=1&scope=B,C&redirect_uri=https://client/callback

② 리소스 서버에서 리소스 서버 계정 로그인 요청

③ 유저는 리소스 서버의 계정 로그인

 - 유저가 보낸 url 파라미터에서 client_id,redirect_uri를 리소스 서버가 가지고있는 Client ID, Redirect URL를 비교하여 일치하지 않으면 끝냄

④ Client서버가 신청한 필요기능(B,C) 확인 및 동의 요청

⑤ 동의 확인

⑥ 허용한 유저 정보 추가

 - 유저가 보낸 url 파라미터로 리소스 서버에 허용한 유저 정보를 추가함

 

 

OAuth Resource Server의 승인

Resource 서버가 Authorization Code를 생성

Redirect URL을 통해 authorization code 전송

 - ex) location : https://client/callback?code=3

 - 응답할때 header 값으로 location을 보내면 Resource Owner가 알아차리지 못하게 리다이렉션이 됨

Client에게 authorization code 전송

URI파라미터를 통해 Authorization code저장

authorization_code, Client ID, Client Secret, Redirect URL 파라미터로 보내서 access token을 요청

 - ex) https://resource.server/token

         ?grant_type=authorization_code

         &code=3

         &redirect_uri=https://client/callback

         &client_id=1

         &client_secret=2

- Resource 서버는 URI의 파라미터를 통해 정상적인 요청인지 확인

 

 

OAuth 엑세스토큰 발급

Authorization Code를 삭제

 - Resource 서버와 Client는 Authorizaiton Code를 삭제

 - 다시 인증을 반복하지 않기 위해

Resource 서버가 AccessToken 발급

Client에게 access token응답

URL파라미터를 통해 AccessToken 저장

※ 클라이언트가 발급받은 access token으로 리소스 서버에 접근하게 되면 리소스 서버는 access token을 보고 해당되는 user에 대해 유효한 scope(기능)의 권한이 열려있는 것이라고 허용하게 됨

 

 

OAuth API 호출

 리소스 서버를 핸들링 하기 위해서 리소스 서버가 작성해둔 사용 방법에 맞게 호출해야함

 각 리소스 서버마다 API호출 방법이 문서로 나와있음

 

 

OAuth Refresh token

1. 리프레시 토큰이란

 엑세스토큰은 수명이 있고 그 수명이 끝나면 API에 접속했을때 데이터를 주지 않음

 그럴때마다 엑세스토큰을 다시 발급 받아야하는데 그것을 매번 사용자에게 시키기엔 불편함

 손쉽게 우리가 엑세스토큰을 발급 받을 수 있게 하는 방법이 리프레시 토큰

 

※ RFC : 인터넷과 관련된 기술의 표준안

 

2. 리프레스 토큰의 동작 방식

각 리소스 서버마다 Refresh token을 요청하여 Access Token을 재발급 받는 방법에 대한 API호출 방법이 문서로 나와있음

반응형

+ Recent posts