기억나는 노트

[javascript, Vue] fs을 이용한 Vue Component import 자동화 파일 생성

밀리노트 — Thu, 12 Oct 2023 13:59:34 +0900

<문제점>

컴포넌트들을 만든 후 index.js에 각 Vue 컴포넌트를 "수기로 import" 해야하는 상황이 발생하여 자동화가 필요하여 추가

자동화할 대상들은 components 하위에 있는 1depth Directory에 index.js 생성이 필요

하지만 각 1dpeth Directory 밑에는 모듈별 컴포넌트들이 존재하여 아래 Depth에 컴포넌트들도 모두 스캔이 필요

<자동화 전 소스 예시>

/dialog/index.js

import ApprovalHistoryModal from './approval/ApprovalHistoryModal.vue';
import ApprovalLineModal from './approval/ApprovalLineModal.vue';
import ApprovalModal from './approval/ApprovalModal.vue';
import BasicAlert from './basic/BasicAlert.vue';
import BasicConfirm from './basic/BasicConfirm.vue';
import AddressSearchModal from './common/AddressSearchModal.vue';
import TypeContentModal from './common/TypeContentModal.vue';
import GroupModal from './group/GroupModal.vue';
import SingleSiteModal from './site/SingleSiteModal.vue';
import MultiUserModal from './user/MultiUserModal.vue';
import SingleUserModal from './user/SingleUserModal.vue';

export default {
  install(Vue) {
    Vue.component('ApprovalHistoryModal', ApprovalHistoryModal);
    Vue.component('ApprovalLineModal', ApprovalLineModal);
    Vue.component('ApprovalModal', ApprovalModal);
    Vue.component('BasicAlert', BasicAlert);
    Vue.component('BasicConfirm', BasicConfirm);
    Vue.component('AddressSearchModal', AddressSearchModal);
    Vue.component('TypeContentModal', TypeContentModal);
    Vue.component('GroupModal', GroupModal);
    Vue.component('SingleSiteModal', SingleSiteModal);
    Vue.component('MultiUserModal', MultiUserModal);
    Vue.component('SingleUserModal', SingleUserModal);
  },
};

/components/export.js

export { default as dialog } from './dialog';
export { default as file } from './file';
export { default as input } from './input';
export { default as table } from './table';
export { default as tree } from './tree';

/components/index.js

import * as components from './export';

export default function install(Vue) {
  Object.values(components).forEach((component) => {
    Vue.use(component);
  });
}

src/index.js

import component from './common/components';

export default {
  install(Vue) {
    Vue.use(component);
  },
};

<작업 내용>

/components/index.js는 수기로 작성할 일이 없어 자동화 대상에서 제외

공통 컴포넌트 1Depth Directory (/dialog/index.js, /file/index.js, 등) 와 최상위 디렉토리(export.js)를 대상으로 처리

공통 컴포넌트 경로는 './src/common/components' 으로 지정하고 처리

[ /script/fileGenerate.js ]

const fs = require('fs');
const rootFolder = './src/common/components';

const readDir = (path, filePaths = []) => {
  const files = fs.readdirSync(path);
  files.forEach((fileName) => {
    const name = `${path}/${fileName}`;
    if (fs.statSync(name).isDirectory()) {
      return readDir(name, filePaths);
    } else {
      filePaths.push(name);
    }
  });

  return filePaths;
};

const groupingDir = (files, moduleMap = {}) => {
  files.forEach((file) => {
    const filePathAndName = file.replace(rootFolder, '').substring(1);

    if (filePathAndName.includes('/')) {
      const dirName = filePathAndName.split('/')[0];
      moduleMap[dirName] = [
        ...(moduleMap[dirName] || []),
        ...[`.${filePathAndName.replace(dirName, '')}`],
      ];
    }
  });

  return moduleMap;
};

const writeIndexFile = (modulePathMap) => {
  for (const [key, value] of Object.entries(modulePathMap)) {
    const rootPath = `${rootFolder}/${key}/index.js`;
    let content = '';

    //import
    value.forEach((modulePath) => {
      // index.js인 경우 패스
      if (modulePath.includes('index.js')) return true;

      const moduleName = modulePath.substring(
        modulePath.lastIndexOf('/') + 1,
        modulePath.lastIndexOf('.'),
      );
      content += `import ${moduleName} from '${modulePath}';\n`;
    });

    content += '\nexport default {\n' + '  install(Vue) {\n';
    // Vue.component
    value.forEach((modulePath) => {
      // index.js인 경우 패스
      if (modulePath.includes('index.js')) return true;

      const moduleName = modulePath.substring(
        modulePath.lastIndexOf('/') + 1,
        modulePath.lastIndexOf('.'),
      );
      content += `    Vue.component('${moduleName}', ${moduleName});\n`;
    });
    content += '  },\n' + '};';

    fs.writeFileSync(rootPath, content);
  }
};

const writeExportFile = (modulePathMap) => {
  const rootPath = `${rootFolder}/export.js`;
  let content = '';
  for (const [key] of Object.entries(modulePathMap)) {
    content += `export { default as ${key} } from './${key}';\n`;
  }

  fs.writeFileSync(rootPath, content);
};

const modulePathMap = groupingDir(readDir(rootFolder));
writeIndexFile(modulePathMap);
writeExportFile(modulePathMap);

readDir() 함수를 통해 지정한 rootFolder에 하위 파일들을 모두 스캔 후 배열(filePaths) 에 저장
- Directory인 경우는 재귀호출을 하여 안에 있는 파일들을 조회
groupingDir()을 통해 읽어드린 배열을 최상위 Directory 명으로 오브젝트를 생성

{
	dialog: [파일path1, 파일path2],
	input: [파일path1, 파일path2],
	...
}

writeIndexFile()을 통해 1depth Directory 밑에 index.js를 생성
- index.js에는 각 컴포넌트 모듈들을 import 및 Vue.component 등록 로직을 추가
writeExportFile()을 통해 최상위 경로에 export.js를 생성
- export.js에는 1depth Directory에 있는 index.js를 등록하는 로직을 추가

[ /package.json ]

npm run serve 또는 npm run build:lib라는 명령어가 들어오는 경우

"node script/fileGenerate.js" 문구를 추가하여 fileGenerate.js가 실행되도록 추가

{
  "name": "컴포넌트명",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "serve": "node script/fileGenerate.js && vue-cli-service serve",
    "build:lib": "node script/fileGenerate.js && vue-cli-service build --target lib --name micro-portal-component ./src/index.js",
  }
  ...
}

[javascript] axios multi form 데이터 처리

밀리노트 — Thu, 12 Oct 2023 13:35:03 +0900

[소스 환경]

BackEnd : Spring boot, jdk17, Lombok

Front: Vue, Axios

BackEnd에서 파일을 수정하는 로직을 배열로 받아 처리하는 부분이 포함

Axios에서 Form을 배열로 전달해야하는 상황이 발생

@PutMapping(value = "[주소]",
        consumes = MediaType.MULTIPART_FORM_DATA_VALUE,
        produces = MediaType.APPLICATION_JSON_VALUE)
public SuccessResponse<List<Response>> [메소드명] (@PathVariable String id,
        @Valid @ModelAttribute Requests requests) {
    return new SuccessResponse<>(service.upsert(id, requests));
}

@Getter
@Setter
public class Request {
	private List<SubRequest> requests;
}

@Getter
@Setter
public class SubRequest {
	private String id;
	private List<MultipartFile> files;
}

일반적으로 Axios에서 파일을 전달하는 경우 아래와 같은 방식을 사용 (단일 처리)

async update(id, files) {
    const headers = { 'Content-Type': 'multipart/form-data' };
    const formData = new FormData();
    files.forEach((file) => {
      formData.append('files', file);
    });
    
    return await axios.put([주소], formData, headers);
  },

배열로 사용하는 경우에는 아래와 같은 처리가 필요 (다건 처리)

formdata.append(`requests...`, value)에 requests는 백엔드에서 사용한 key명을 사용

async update(id, parameters) {
    const headers = { 'Content-Type': 'multipart/form-data' };
    
    const formData = new FormData();
    parameters.forEach((param, index) => {
      for (const [key, value] of Object.entries(param)) {
        if (value) formData.append(`requests[${index}].${key}`, value);
      }
    })
    
    return await axios.put([주소], formData, headers);
  },

[ SpringBoot + jsp + intellij ] jsp 사용을 위한 설정

밀리노트 — Sat, 30 Apr 2022 19:19:44 +0900

- 설치 환경

intellij: IntelliJ IDEA 2021.1.3 (Ultimate Edition)
jdk: java17
spring boot: 2.6.4

1. spring boot 설정

Intellij Community 버전은 https://start.spring.io/ 에서 프로젝트르 세팅

1. *Packaging 방식을 War로 선택 (jar방식은 지원 안되는 듯)

war를 선택

JSP Limitations

When running a Spring Boot application that uses an embedded servlet container (and is packaged as an executable archive), there are some limitations in the JSP support.
With Jetty and Tomcat, it should work if you use war packaging. An executable war will work when launched with java -jar, and will also be deployable to any standard container. JSPs are not supported when using an executable jar.Undertow does not support JSPs.Creating a custom error.jsp page does not override the default view for error handling. Custom error pages should be used instead.

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#web.servlet.embedded-container.jsp-limitations

2. 사용할 Dependencies 추가

- 기본적으로는 Spring Web만 추가하면 사용 가능 (Lombok은 편의를 위해서 추가)

3. Gradle에 jsp에서 사용하는 Dependencie 추가

- plugins에 war 확인 필요 (jar X)

- dependencies에 tomcat-embed-jasper, javax,servlet:jstl, spring-boot-starter-tomcat 확인

plugins {
    id 'org.springframework.boot' version '2.6.7'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
    id 'war' // jsp 사용시 필수 요소
}

...

dependencies {
    implementation 'org.apache.tomcat.embed:tomcat-embed-jasper' // 추가
    implementation 'javax.servlet:jstl' // 추가

    implementation 'org.springframework.boot:spring-boot-starter-web'
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' // jsp 사용시 필수 요소
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

2. 소스 설정

1. 설정 파일

- src/main/resources/application.yml 또는 src/main/resources/application.properties

- 두가지 방법 중 선택

- 필수요소는 아니지만 페이지에 반복적인 경로와 파일형식을 제거하기 위해 사용
-> 사용하는 경우 return "home", 사용하지 않는 경우 return "/WEB-INF/views/home.jsp"

.yml인 경우

spring:
  mvc:
    view:
      prefix: /WEB-INF/views/
      suffix: .jsp


.properties인 경우

spring.mvc.view.previx=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

2. jsp 디렉토리 생성

- src/webapp/WEB-INF는 이름을 변경하지 않고 기본적인 디렉토리로 사용 (필수)

- views, jsp, 등의 하위 디렉토리 생성 (선택, 이름도 변경 가능)

3. 테스트 파일

테스트를 위한 용도로 만든 파일 예시

1. Controller (HomeController.java)

@Controller
public class HomeController {

    @GetMapping("/home")
    public String home() {
        return "home";
    }
}

2. jsp (home.jsp)

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<!doctype html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Document</title>
</head>
<body>
    테스트
</body>
</html>

오류 사항

1. 원인

필자는 프로젝트내에 Module을 추가하여 세팅을 하는 중 404 오류가 발생

2. 해결방법

- Intellij 오른쪽 상단에 콤보박스를 선택 후 Edit Configurations..를 클릭

- jsp가 실행되는 Spring Boot > MyJspApplication 선택

- Configuration 탭에 Environment 밑에 있는 Working Directory에 $MODULE_WORKING_DIR$ 입력

[ Docker / 도커 ] 윈도우(windows) 도커 설치하기

밀리노트 — Wed, 20 Apr 2022 22:49:55 +0900

1. 설치조건

WSL은 Windows Subsystem for Linux 2의 줄임말로 윈도우에서 리눅스를 사용할 수 있게 해주는 기능

Windows 10 Pro 에디션
- WSL2 기반 Docker Engine 사용 가능
- Hyper-V 기반 Docker Engine 사용 가능
Windows 10 Home 에디션 (윈도우 패치가 된 경우)
- WSL2 기반 Docker Engine 사용 가능
Windows 11 설치 가능

Windows 10 Home은 WSL2를 지원하지 않았는데, 2020년 5월 Windows 10 May 2020 Update(20H1) 업데이트
가 릴리스되면서 WSL2가 정식 릴리스되었다는 점입니다. WSL2는 Windows 10 Home에서도 사용 가능하도록 패치 됌

2. WSL 설치방법

1. Windows Terminal을 ’관리자 권한으로 실행’합니다.

2. PowerShell 탭에서 다음 두 명령어를 실행합니다.

$ dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
$ dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

3. 두 명령어 모두 ‘작업을 완료했습니다’ 출력으로 종료되었는지 확인합니다.

4. 윈도우를 재부팅합니다.

5. x64 머신용 최신 WSL2 Linux 커널 업데이트 패키지를 다운로드 받아 안내에 따라 설치합니다.

6. Windows Terminal을 열고 다음 명령어를 실행합니다.

$ wsl --set-default-version 2

3. 도커 설치

다운로드주소: https://www.docker.com/products/docker-desktop/

Docker Desktop - Docker

DockerCon 2022 Don’t miss it – register now for May 10th! DockerCon is a free, immersive online experience complete with product demos, breakout learning tracks, panel discussions, hacks & tips, deep dive technical sessions from Docker experts, the dev

www.docker.com

설치파일을 받은 후 실행
도커 회원가입 https://hub.docker.com/
설치와 회원가입이 모두 완료된 화면

도커 실행화면 및 숨긴 아이콘 표시

4. 그 외 문제해결

필자는 windows 10 Home을 사용중이라 WSL이 설치되어있지 않은 현상이 발생 아래와 같이 조치

윈도우10 > 설정 > 업데이트 및 복구 > windows 업데이트로 최신화 진행
업데이트 진행중에 windows 10 버전 20h2의 기능 업데이트에서 멈춤현상 발생-> 수동 업데이트 파일을 받아 다운로드 진행

윈도우10 20H2 업데이트시 61% 에서 멈추는 오류 해결 방법

제가 가지고 있는 LG 노트북에서 윈도우 10 20H2 업데이트를 실행하면 61% 에서 멈추는 현상이 있어서 ...

blog.naver.com

출처:

https://www.lainyzine.com/ko/article/a-complete-guide-to-how-to-install-docker-desktop-on-windows-10/

[Windows 10] Docker 설치 완벽 가이드(Home 포함)

Docker는 경량 가상화 기술인 리눅스 컨테이너 도구입니다. Windows 10 Home과 Pro에서도 몇 가지 설정을 통해 Docker Desktop으로 리눅스 컨테이너를 사용할 수 있습니다. 이 글에서는 Windows 10에서 Docker Des

www.lainyzine.com

https://mainia.tistory.com/5064

윈도우10 최신 상태로 업데이트 하는 방법

윈도우10 최신 상태로 업데이트 하는 방법 환경: Windows 10 모든 프로그램이 그렇듯 윈도우 또한 처음부터 완벽할 수 없습니다. 그래서 윈도우는 항상 최신 상태를 유지하는 것이 좋습니다. 그 중

mainia.tistory.com

https://blog.naver.com/PostView.naver?blogId=websearch&logNo=222248105770

윈도우10 20H2 업데이트시 61% 에서 멈추는 오류 해결 방법

제가 가지고 있는 LG 노트북에서 윈도우 10 20H2 업데이트를 실행하면 61% 에서 멈추는 현상이 있어서 ...

blog.naver.com

[ Intellj / 인텔리제이 ] Execution failed for task ':test'.

밀리노트 — Tue, 19 Apr 2022 22:33:36 +0900

1. 상황

Intellij를 통해 간단한 출력용 코드를 junit으로 돌리는데 에러가 발생

class를 public으로 변경해도 동일 에러 발생
메소드에 public으로 변경해도 동일 에러 발생

@SpringBootTest
public class UserSearchRepositoryTest {

    @Test
    void 사용자_생성() {
        System.out.println("aaaa");
    }
}

Execution failed for task ':test'.
> There were failing tests. See the report at: file:///D:/sideProject/elastic-jdk17-toy/build/reports/tests/test/index.html

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

파일에 들어가서 확인하니 gradle이 테스트 실행할때 Exception이 발생

org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not execute test class 'com.mile.elasticjdk17toy.repository.rdb.UserRepositoryTest'.

2. 해결방법

File > Setting > Gradle에 빨간색 부분을 Gradle -> Intellij IDEA로 변경하여 해결

[ Intellj / 인텔리제이 ] 파일 저장시 자동 정렬 (Save Actions)

밀리노트 — Mon, 7 Feb 2022 23:19:49 +0900

1. 설치하는 법 : File > Settings > Plugins > Markeyplace > SaveActions 검색

2. 설정하는법 : File > Settings > Save Actions

[General]

Activate save actions on save (before saving each file, performs the configured actions below)
- 저장시 활성화 (각 파일을 저장하기 전에 아래에 구성된 작업 수행)
Activate save actions on shorcut (default "CTRL + SHIFT + S")
- 단축키로 저장했을 때 활성화 (기본값 "CTRL + SHIFT + S")
Activate save actions on batch
- 일괄 작업 시 활성화
No action if compile errors(applied per file)
- 컴파일 오류 발생시 조치 없음 (파일별로 적용)

[Formatting Actions]

Optimize imports
- import 최적화
Reformat file
- file 재정렬

3. 포함할 파일과 제외할 파일 지정 : File > Settings > Save Actions 스크롤 맨 아래

참고: https://hirlawldo.tistory.com/136

[IntelliJ] 저장 시 자동 정렬 설정하는 방법 (Save Actions) - Mac

단축키(Option + Command + L)를 누르면 자동 정렬이 되지만, 가끔 까먹고 안할 때가 있다. 자동으로 저장할 때 정렬해주면 편하지 않을까? (가끔 정렬하면 더 구린 경우 팀원들에게 욕을 먹을 수 있으

hirlawldo.tistory.com

[도커 / docker] 명령어 정리

밀리노트 — Mon, 7 Feb 2022 10:38:49 +0900

1. 한글시간으로 변경

docker run -e TZ=Asia/Seoul debian:jessie date

[토비의 스프링 - Vol.2] 2장 - 2.4 JPA

밀리노트 — Mon, 17 Jan 2022 22:34:07 +0900

2.4 JPA

Java Persistent API의 약자로 EJB 3.0과 함꼐 등장한 JavaEE와 JavaSE를 위한 영속성 관리와 O/R 매핑을 위한 표준 기술

오브젝트를 중심으로 개발하는 자바 같은 언어를 통해 접근하려면 불편한 점이 많았음

ORM이란 오브젝트와 RDB 사이에 존재하는 개념과 접근 방법, 성격의 차이 떄문에 요구되는 불편한 작업을 제거

오브젝트를 가지고 정보를 다루면 ORM 프레임워크가 이를 RDB에 적절한 형태로 변환해주거나 그 반대로 RDB에 저장되어 있는 정보를 자바오브젝트가 다루기 쉬운 형태로 변환해주는 기술

ORM을 사용하는 개발자는 모든 데이터를 오브젝트 관점으로 생각

가장 믾이 사용되는 대표적인 JPA 구현 제품들
- JBoss의 하이버네이트
- 아파치 OpenJPA
- 이클립스 EclipseLink
- 오라클 TopLink Essentionals

2.4.1 EntityManagerFactory 등록

JPA Persistence Context에 접근하고 엔티티 인스턴스를 관리하려면 JPA의 핵심 인터페이스인 EntityManager를 구현한 오브젝트가 필요

EntityManager는 JPA에서 두가지 방식으로 관리
1. 애플리케이션이 관리하는 EntityManager
  - JavaEE와 JavaSE에서 모두 사용 가능
1. 컨테이너가 관리하는 EntityManager
  - JavaEE 환경과 서버가 필요

반드시 EntityManagerFactory를 빈으로 등록해줘야 함

LocalEntityManagerFactoryBean

JPA 스펙의 JavaSE 기동 방식을 이용해 EntityManagerFactory를 생성

<bean id="emf" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean" />

이 빈은 PersistentProvider 자동 감지 기능을 이용해 프로바이더를 찾고 META-INF/persistence.xml에 담긴 정보를 활용해 EntityManagerFactory를 생성

이 방식은 JPA만을 사용하는 단순한 환경에서 적용 가능하지만 스프링에서 본격적으로 사용하기에는 많은 제약사항이 발생
- 가장 큰 단점은 스프링의 빈으로 등록한 DataSource를 사용 못함
- 스프링이 제공하는 바이트코드 위빙 기법도 적용할 수 없음

실전에서 이 방법을 사용하는건 좋지 않음

JavaEE 5 서버가 제공하는 EntityManagerFactory

JPA는 JavaSE 환경보다는 JavaEE에서 서버가 제공하는 JPA 프로바이더를 통해 사용하는 것이 일반적인 방법

스프링에선 JNDI를 통해 서버가 제공하는 EntityManager와 EntityFactory를 제공 받음

서버의 JTA를 이용해 트랜젹솬 관리 기능을 활용

이 방식은 JPA를 지원하는 JavaEE 5이상의 서버에 배치하고 JPA 프로바이더와 서버가 요구하는 설정을 해뒀다고 전제

모든 JPA 기능은 서버와 JPA 퍼시스턴스 유닛 설정을 따름

<jee:jndi-lookup id="emf" jndi-name="persistence/myPersistenceUnit" />

jndi-name은 JNDI로 등록된 퍼시스턴스 유닛의 이름을 지정

LocalContainerEntityManagerFactoryBean

스프링이 직접 제공하는 컨테이너 관리 EntityManager를 위한 EntityManagerFatocy를 생성

JavaEE 서버에 배치하지 않아도 컨테이너에서 동작하는 JPA 기능 활용 가능

스프링이 제공하는 일관성 있는 데이터 액세스 기술 접근 방법도 적용 가능

스프링의 JPA 확장 기능도 활용

<bean id="emf"
			class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
		<property name="dataSource" ref="dataSource" />
</bean>

이 빈은 META-INF/persistence.xml을 참고해 퍼시스턴스 유닛과 이를 활용하는 EntityManagerFactory를 생성

DB 연결정보는 persistence.xml 프로퍼티에 등록하지 않아도 됌

대신 스프링에 빈으로 DataSource를 JPA에서 사용

META-INF/persistence.xml 파일 예시
```
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
							xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
							xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
							http://java.sun.com/xml/ns/persistence/persistence_2.0.xsd" 
							version="2.0">
		<persistence-unit name="default">
				<class>springbook.learningtest.spring.jpa.Member</class>
				<exclude-unlisted-classes />

				<properties>
						<property name="eclipselink.waving" value="false" />
				</properties>				
		</persistence-unit>
</persistence>
```
- 일부 프로퍼티 설정은 JPA 구현 제품마다 다름을 주의
- 자바오브젝트와 RDB 테이블 사이의 매핑과 변환을 위한 정보는 orm.xml과 같은 매핑 정보를 담은 파일에 정의하거나 애노테이션을 이용해 클래스 안에 정의 가능
```
@Entity
public class Member {
		@Id
		int id;

		@Column(length=100)
		String name;
	
		@Column(nullable=false)
		double point;
		
		// 수정자(setter), 접근자(getter)
		...
}
```
- LocalContainerEntityManagerFactoryBean에는 dataSource 외에 다음과 같은 프로퍼티 추가가 가능
persistenceUnitName
- persistence.xml에는 하나 이상의 퍼시스턴스 유닛이 정의될 수 있음
- persistence.xml에 다음과 같이 퍼시스턴스 유닛이 정의되어 있고, 이 설정을 따라 EntityManagerFactory 빈을 정의해야한다면 아래와 같이 추가
```

<persistence-unit name="subPersistenceUnit">


<property name="persistenceUnitName" value="subPersistenceUnit" />
```
persistenceXmlLocation
- LocalContainerEntityManagerFactoryBean은 디폴트 위치인 META-INF에서 persistence.xml 파일을 찾음
- 일부 WAS에서는 META-INF/persistence.xml 파일을 자동으로 인식해서 서버가 관리하는 EntityManagerFactory와 충돌이 발생
- 따라서 스프링이 제공하는 컨테이너 관리 EntityManager를 적용하고 동시에 JPA 프로바이더를 제공하는 WAS에 배포할 경우 디폴트 위치에 persistence.xml을 넣는건 피해야 함
- persistenceXmlLocation의 프로퍼티에 파일 위치를 지정하여 변경
- 가장 간단한 방법은 파일의 이름을 spring-persistence.xml과 같이 변경하는 방법
```
<property name="persistenceXmlLocation" value="META-INF/spring-persistence.xml" />
```
jpaProperties, jpaPropertyMap
- EntityManagerFactory를 위한 프로퍼티를 지정할 때 사용
- jpaProperties는 <props>를 이용, jpaPropertyMap은 <map>을 이용해 정보를 입력
```

<persistence-unit name="default">
		...
		<properties>
				<property name="eclipselink.waving" value="false" />
		<properties>
</persistence-unit>
```
- persistence.xml 파일 대신 스프링의 LocalContainerEntityManagerFactoryBean 빈에 정의
```

<property name="jpaProperties">
		<props>
				<prop key="eclipselink.waving">false</prop>
		</props>
</property>
```
jpaVendorAdapter
- JPA는 비슷한 기능이지만 벤더별로 다른 설정 프로퍼티를 사용해야 하는 경우가 많음
- 구현 벤더별로 다르게 지정되는 프로퍼티나 설정을 JpaVendorAdapter를 이용하면 스프링이 정의한 표준 프로퍼티를 이용해 지정 가능
- JPA는 코드상에서 데이터 액세스 로직을 작성할 때 자바오브젝트와 전용 쿼리 언어, Criteria 등을 이용
- 이런 API와 오브젝트 쿼리 등을 DB가 이해할 수 있는 SQL 언어로 전환해서 처리
- ORM 계층의 언어와 API가 아닌 DB SQL을 출력하고 싶을때 아래와 같이 옵션 설정
```
<property name="jpaVendorAdapter">
		<bean class="org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter">
				<property name="showSql" value="true" />
		</bean>
</property>
```
- showSql이라는 프로퍼티는 true, false로 지정 가능
- 밴더 어댑터에 맞는 설정으로 변환 (EclipseLink: eclipselink.logging.level=FINE, 등)
- 스프링 3.1에선 EclipseLink. Hibernate, OpenJpa, TopLink 네가지 벤더를 위한 JpaVendorAdapter를 지원
- JpaVendorAdapter를 이용하면 showSql뿐 아니라 매핑 DDL을 자동생성해주는 generatedDdl과 DB 종류인 database, DB 플랫폼 정보인 databasePlatform 등을 지정
- 이 외에도 각 벤더의 JPA 구현에 따라 달라지는 다양한 정보를 EntityManagerFactory 생성을 위헤 제공
loadtimeWeaver
- JPA는 POJO 클래스를 ORM의 엔티티로 사용
- POJO방식의 단점은 오브젝트가 만들어 진 후엔 컨테이너가 직접 관리할 수 없다는 점
- 엔티티 사이에 관계도 JPA 인터페이스가 아닌 직접 POJO 오브젝트끼리 연결 되있음
- JPA는 그래서 단순한 자바 코드로 만들어진 엔티티 클래스의 바이트코드를 직접 조작해서 확장된 기능을 추가하는 방식을 이용
  - 엔티티 오브젝트 사이에 지연된 로딩이 가능
  - 엔티티 값의 변화를 추적 가능
  - 최적화와 그룹 페칭(fetching) 등의 고급 기능을 적용 가능
- 이미 컴파일된 클래스 바이트 코드를 조작해서 새로운 기능을 추가하는 것을 바이트코드 향상 기법이라고 함
- 클래스의 바이트 코드를 향상시키는 방법은 두가지
  - 바이트코드를 빌드 중에 변경하는 것, JPA 벤더가 제공하는 바이트 코드 컴파일러가 필요하며 매번 빌드 작업중에 이 과정을 반드시 거쳐야 함
  - 런타임 시에 클래스 바이트코드를 메모리에 로딩하면서 다이내믹하게 바이트코드를 변경해서 기능을 추가하는 방법
    - 특별한 툴과 ANT 등을 이용한 번거로운 빌드 작업을 추가하지 않아도 되기 떄문에 애용되는 방법
    - 런타임 시에 클래스를 로딩하면서 기능을 추가하는 것을 로드타임 위빙이라 하고 이런 기능을 가진 클래스를 로드타임 위버라고 부름
- 자바 5 이상에서는 JVM을 기동할 때 javaagent 옵션을 줘서 JVM이 로딩하는 모든 자바 클래스를 조작할 수 있는 기능을 넣었음
- JPA 구현 제품은 대부분 자바 에이전트를 이용해 로드타임 위버를 적용 가능
- 자바 에이전트는 간단해 보이지만 단점이 많음
  - 엔티티 클래스는 몇십 개지만, JVM을 통해 로딩되는 모든 클래스를 일일이 다 확인
  - 서버환경에서는 기동하는 JVM에 자바 에이전트를 설정해줘야하고, 운영정책과 관리 측면에서 부담을 줄 수 있어서 거부될 위험이 많음
- 스프링은 자바 에이전트 대신 특별한 클래스 로더를 이용해 로드타임 위빙 기능을 제공
  - JPA 벤더에 종속되지 않는 방법을 통해 로드타임 위빙 기능 적용 가능 (5장 참고)
  - org.springframework.instrument-3.0.7.RELEASE.jar를 사용
```
//자바 에이전트
-javaagent:eclipselink.jar

//스프링이 제공하는 자바 에이전트
-javaagnet:lib/org/springframework.instrument-3.0.7.RELEASE.jar
```
- LocalContainerEntityManagerFactoryBean의 loadtimeWaver프로퍼티를 아래로 지정
```
<property name="loadTimeWeaber">
		<bean class=
		"org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver" />
</property>
```

트랜잭션 매니저

컨테이너가 관리하는 EntityManager 방식에는 컨테이너가 제공하는 트랜잭션 매니저가 반드시 필요

스프링의 EntityManager를 사용하려면 적절한 트랜잭션 매니저 등록이 필요

스프링 JDBC는 트랜잭션 매니저가 없어도 동작, JDBC 자체가 자동 트랜잭션 모드를 갖고 있기 때문에 명시적으로 트랜잭션 관리를 안해도 됌

반면 JPA는 반드시 트랜잭션 안에서 동작하도록 설계

LocalContainerEntityManagerFactoryBean을 통해 컨테이너 관리 EntityManger를 사용할 때는 트랜잭션 매니저를 다음과 같이 추가

<bean id="emf" class=
			"org.springframework.orm.jpa.localContainerEntityManagerFactoryBean">
		...
</bean>

<bean id="transactionManager"
			class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="entityManagerFactory" ref="emf" />
</bean>

JPA를 이용하는 DAO 코드는 스프링이 관리하는 트랜잭션 관리 기능을 이용 가능

@Transactional이나 트랜잭션 AOP를 이용해서 트랜잭션 경계설정을 해주면 자동으로 JPA 트랜잭션을 시작하고 커밋하도록 만듬

JpaTransactionManager를 사용하면 DataSource를 공유하는 JDBC DAO와 트랜잭션 공유 가능 (서비스 계층의 코드가 JPA DAO와 JDBC DAO를 하나의 트랜잭션 안에서 사용 가능)

JTA 트랜잭션을 이용하는 경우라면 JtaTransactionManager를 사용

2.4.2 EntityManager와 JpaTemplate

JDBC나 iBatis를 사용한 템플릿처럼 JPA도 템플릿 방식을 지원

템플릿을 통해 JPA 코드가 스프링 트랜잭션과 동기화 할 수 있도록 하고 예외를 변환하는 등의 기능을 지원 받음

스프링에선 JpaTemplate뿐 아니라 JPA API를 직접 사용해 DAO를 작성 가능

JPA의 핵심 프로그래밍 인터페이스는 EntityManager

EntityManager 오브젝트를 가져올 수 있으면 JPA의 모든 기능을 이용 가능

JpaTemplate

jdbcTemplate, SqlMapClientTemplate와 동일하게 템플릿 방식으로 JPA 코드를 작성 가능
- 장점 : 템플릿을 이용하면 반복 작업을 줄여주고 예외 변환같은 편리한 기능을 제공
- 단점 : 데이터 액세스 기술이 직접 제공하는 API 대신 템플릿의 메소드와 콜백을 사용

스프링에선 JPA를 사용할 때 JpaTemplate은 자주 사용 안함

JPA API가 익숙치 않고 스프링 템플릿 방식이 편리할 때 JpaTemplate를 사용 권장

public class MemberTemplateDao {
		private JpaTemplate jpaTemplate;

		@Autowired
		public void init(EntityManager emf) {
				jpaTemplate = new JpaTemplate(emf);
		}
}

JpaDaoSupport 클래스를 상속해서 DAO를 만들면 JpaTemplate 생성코드 생략 가능
- JpaTemplate 필요할 떄는 getJpaTemplate()를 이용

JpaTemplate를 사용할 떄는 기본적으로 JpaCallback 인터페이스의 doInJpa()에 필요한 작업을 입력

DoinJpa()는 파라미터로 EntityManager를 전달, 이를 통해 모든 JPA 기능을 사용가능

List<Member> ms = templateDao.jpaTemplate.execute(new JpaCallback<List<Member>>() {
		public List<Member> doInJpa(EntityManager entityManager) throws
				PersistenceException {
				return entityManager.createQuery("select m from Member m".getResultList();
		}
});

JpaTemplate은 콜백 오브젝트 없이도 간단한 메소드를 이용해 EntityManager가 제공하는 대부분의 기능을 사용 가능하게 해줌

Member m = new Member(1, "Spring", 8.9);
jpaTemplate.persist(m);
Member m2 = templateDao.jpaTemplate.find(Member.class, 1);

애플리케이션 관리 EntityManager와 @PersistenceUnit

애플리케이션 코드가 관리하는 EntityManager는 JavEE환경과 JavaSE 모두 사용 가능

EntityManager는 EntityManagerFactory가 있다면 다음과 같이 직접 생성

EntityManager em = entityManagerFactory.createEntityManager();

컨테이너가 관리하지 않는 EntityManager이므로 트랜잭션은 다음과같이 사용

em.getTransaction().begin();

Member m = new Member(1, "Spring", 7.8);
em.persist(m);
Long count = em.createQuery("select count(m) from Member m", Long.class)
							.getSingleResult();

em.getTransaction().commt();

@Autowired, @Resource

EntityManagerFactory를 빈으로 등록하는 것은 LocalContainerEntityManagerFactoryBean을 이용하는 방법과 JNDI를 통해서 서버가 제공하는 EntityManagerFactory를 가져와 빈으로 사용하는 방법 두가지가 존재

어떤 방법이든 EntityManagerFactory는 빈으로 등록되므로 @Autowired, @Resource 또는 일반적인 스프링 DI방식으로 DAO 사용 가능

public class MemberDao {
		@Autowired EntityManagerFactory emf;

		public void addMember(Member member) {
				EntityManager em = emf.createEntityManager();
				...
		}
}

EntityManagerFactory는 EntityManager를 만들 수 있는 createEntityManager()를 제공

@PersistenceUnit

EJB에서 JPA를 사용할 때와 비슷

스프링의 DI 방식 대신 JPA 표준 스팩에 나온 방식을 이용

javax.persistence 패키지의 @PersistenceUnit 애노테이션을 사용

public class MemberDao {
		@PersistenceUnit EntityManagerFacotry emf;

@Autowired를 쓸때와 다른점은 스프링 의존도가 전혀 없는 순수한 JPA 코드라는 점

JavaEE 컨테이너에서 EntityManagerFactory를 제공받아 사용하는 전형적인 JPA 코드

@PersistenceUnit에 의해 주입되려면 애노테이션을 이용한 의존관계 설정이 가능한 컨테이너이거나, XML에 반드시 다음 설정이 필요

<context:annotation-config />

내부적으론 <context:annotation-config />에 의해 자동등록되는 PersistenceAnnotationBeanPostProcessor 후처리기가 @PersistenceUnit에 대한 DI 담당

EntityManagerFactory를 직접 이용하는 방법은 실제로 자주 사용 안함

EntityManagerFactory 인터페이스에서 제공하는 QueryBuilder, Metamodal, PersistenceUnitUtil을 가져오거나 캐시나 프로퍼티 정보를 참조할 필요가 있을때 사용

컨테이너 관리 EntityManager와 @PersistenceContext

DAO가 컨테이너로부터 EntityManager를 직접 주입받으려면 JPA의 @PersistenceContext을 사용

EntityManager는 스프링의 빈으로 등록하지 않음, 따라서 스프링 DI 방법으론 주입X

스프링에서는 JavaEE 컨테이너가 관리하는 EntityManager를 주입받는 방법을 스프링 애플리케이션의 코드에도 동일하게 사용 가능

표준 스펙을 따르는 프로그래밍 모델을 스프링에서도 동일하게 사용 가능해짐

LocalContainerEntityManagerFactoryBean에 의해 등록된 EntityManagerFactory로부터 컨테이너가 관리하는 EntityManager를 직접 DOA에 주입받는 예시
```
public class MemberDao {
		@PersistenceContext EntityManager em;

		public void addMember(Member member) {
				em.persist(member);
		}
```
- EntityManager는 인스턴스 변수에 한 번 주입받아서 재사용 못함
- EntityManager는 그 자체로 멀티스레드에서 공유 할 수 없음
- 트랜잭션마다 하나씩만 만들어져서 사용되고 트랜잭션이 종료되면 함꼐 제거가 돼야 함

인스턴스 변수에서 한번 DI 받아놓고 여러 스레드에서 사용할 수 있는 이유
- @PersistenceContext로 주입받은 EntityManager는 실제가 아니라 현재 진행 중인 트랜잭션에 연결되는 퍼시스턴스 컨텍스트를 갖는 일종의 프록시
- 하나의 오브젝트를 공유하는 듯하지만 각 스레드가 자신의 컨텍스트에 따라서 만들어진 독립적인 오브젝트를 사용하도록 연결해주는 기능을 가진 프록시를 이용하는 것

컨테이너가 관리하는 EntityManager도 이와 비슷한 방식으로 동작
- DAO에서 마치 하나의 EntityManager를 독점적으로 사용하듯이 접근하지만 실제로는 트랜잭션마다 다른 EntityManager 오브젝트를 사용
- EntityManager가 존재하는 컨텍스트가 트랜잭션 범위이므로 type 앨리먼트는 아래와 같이 default 값이 적용
```
@PersistenceContext(type=PersistenceContextType.TRANSACTION) EntityManager em;
```

JPA 스펙에 따르면 트랜잭션 스코프의 퍼시스턴스 컨텍스트는 JTA를 통해 트랜잭션 관리

스프링은 이를 JpaTransactionManager를 통해 관리하기 떄문에 JavaEE 서버의 트랜잭션 매니저와 JTA가 없어도 JPA의 장점인 @PersistenceContext를 통한 EntityManager 주입 가능

@PersistenceContext와 확장된 퍼시스턴스 컨텍스트

@PersistenceCOntext를 이용해서 컨테이너가 관리하는 EntityManager를 주입

다만 type 앨리먼트의 값이 다름, type을 PersistenceContextType.EXTENDS로 지정

트랜잭션 스코프 대신 확장된 스코프를 갖는 EntityManager가 만들어짐

JPA에서 확장된 퍼시스턴스 컨텍스트는 상태유지 세션빈에 바인딩되는 것을 의미

상태유지 세션빈은 사용자별로 독립적이며 장기간 보존되는 오브젝트를 생성

세션빈에 바인딩되는 EntityManager 역시 사용자별로 독립적으로 장기간 보존

상태를 가진 세션빈이나 장기간 지속되는 스코프 빈에만 싱글톤 빈으로 사용 가능
- 하나 이상의 오브젝트로 만들어지기 때문에 각각 독립적으로 EntityManager를 가질 수 있기 때문에 스코프 프록시를 사용할 필요가 없음

public class MemberDao {
		@PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManager em;

확장된 퍼시스턴스 컨텍스트는 싱글톤 빈에 적용하면 안되며, 상태를 가진 세션빈 또는 스프링 스코프 빈의 활용 방법을 잘 이해하고 이에 맞게 EntityManager 활용할때 추천

JPA 예외 반환

JpaTemplate이 JPA API를 직접 사용하는 방법이 좀 더 나은 점은 JPA의 예외를 스프링의 데이터 액세스 예외 추상화 클래스 계층인 DataAccessException의 예외를 반환해준다는 점

JPA의 API는 자동 예외 변환이 발생X, 런타임 예외를 발생시키기 떄문에 try/catch 블록이나 throws 선언이 필요 없음

EntityManager와 같은 리소스 관리는 JPA 지원 컨테이너가 알아서 관리

JPA 예외 변환 AOP

JPA API를 직접 이용하는 경우에도 JPA 예외를 스프링의 DataAccessException 전환 가능

AOP를 이용해서 JPA API가 던지는 JPA 예외를 스프링의 예외로 전환하는 부가기능을 추가

이 방법을 이용하려면 다음 두가지 작업이 필요

@Repository

예외 변환이 필요한 DAO 클래스에 @Repository 애노테이션을 부여

@Repositry는 @Component와 같은 자동인식을 위한 스테레오타입 애노테이션

빈 스캐너를 사용하지 않는 경우에도 @Repository를 DAO에 사용 가능

@Repository가 붙은 DAO 클래스의 메소드는 AOP 예외 변환 기능이 부가될 빈으로 선정

PersistenceExceptionTranslationPostProcessor

@Repository가 붙은 빈을 찾아 예외 변환 기능을 가진 AOP 어드바이스를 적용해주는 후처리기가 필요

PersistenceExceptionTranslationPostProcessor를 빈으로 등록만 하면 사용 가능

<bean class=
"org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" />

SQL 에러 코드를 직접 해석해서 일관된 의미의 예외로 변환해주는 JdbcTemplate의 예외 변환과는 달리, JPA의 예외 자체가 분류하기 힘든 예외로 던져주기 떄문에 해석해서 변환

JPA 스펙이 정의하는 예외는 제한적, 대부분의 DB 예외는 벤더가 정의한 예외나 시스템 예외 등으로 포장돼서 전달되고 스프링은 포장된 예외의 코드 수준까지 분석해 변환하는 기능X

JPA 실행 중에 발생한 DB 예외등은 JDBC와 다른 방식으로 전달, 패러다임이 다르기 떄문에 발생하는 근본적인 한계

JDBC/iBatis와 JPA/하이버네이트 같은 ORM은 프로그래밍이 근본적으로 많은 차이 존재
- POJO 기반의 투명한 영속성이 적용된 ROM의 엔티티 오브젝트를 사용하는 서비스 계층 코드와 항상 명시적으로 특정 SQL을 실행하는 JDBC/iBatis의 서비스 계층 코드는 미묘하지만 분명한 차이가 존재

예외 변환을 통해 완벽하게 독립적인 예외를 기대할 순 없지만 JPA의 예외를 스프링의 예외로 변경하는 건 가치가 있는 작업
- @Repository와 PersistenceExceptionTanslationPostProcessor를 이용한 예외 변환 AOP를 반드시 적용

[토비의 스프링 - Vol.2] 2장 - 2.3 iBatis SqlMaps

밀리노트 — Mon, 17 Jan 2022 22:29:44 +0900

2.3 iBatis SqlMaps

자바오브젝트와 SQL 문 사이의 자동매핑 기능을 지원하는 ORM 프레임워크

iBatis는 코드 내에서 자바오브젝트만을 이용해 데이터 로직을 작성할 수 있게 해주고 SQL을 별도의 파일로 분리해서 관리해주며, 오브젝트-SQL 사이의 파라미터 매핑 작업을 자동으로 해주기 때문에 많은 인기를 얻고 있는 기술

본격적인 ORM인 JPA나 하이버네이트처럼 새로운 DB 프로그래밍 패러다임을 익힐 부담X

SQL을 그대로 이용할 수 있으면서도 JDBC 코드 작성의 불편함을 제거해주고, 도메인 오브젝트나 DTO를 중심으로 개발이 가능하다는 장점

XML파일로 작성하므로 컴파일이 필요 없고, SQL 작성과 관리 또는 검토를 DBA와 같은 개발자가 아닌 사람에 맡길 수 있다는 장점

SQL 매핑은 스프링 JDBC에도 지원하지만, iBatis는 매핑 이상의 많은 기능을 제공

2.3.1 SqlMapClient 생성

핵심 API는 SqlMapClient 인터페이스에 담겨 있음

JDBC가 Connection, Statement, ResultSet을 생성해 사용하듯 iBatis를 이용하려면 SqlMapClient를 구현한 오브젝트가 필요

스프링에서는 SqlMapClient를 빈으로 등록해두고 DAO에서 DI 받아 사용해야 하기 때문에 SqlMapClient를 빈으로 등록해주는 팩토리 빈의 도움이 필요

스프링이 제공하는 SqlMapClient용 팩토리 빈은 SqlMapClientFactoryBean

iBatis 설정파일과 매핑파일

iBatis를 이용하려면 공통 설정을 담은 XML 파일과 매핑정보를 담은 XML매핑 파일이 필요

보통 하나의 설정파일과 한 개 이상의 매핑파일로 구성

설정파일

데이터소스, 트랜잭션 매니저, 매핑 리소스 파일 목록, 프로퍼티, 타입별칭과 핸들러, 오브젝트 패곹리와 설정 프로퍼티 값을 넣을 수 있음

데이터소스와 트랜잭션 매니저는 스프링의 빈으로 등록된 것을 사용하는게 좋음

그 외의 반드시 넣어야 하는 것은 매핑파일 정보

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMapConfig
		PUBLIC "-//ibatis.apache.org//DTD SQL Map Config 2.0//EN"
		"http://ibatis.apache.org/dtd/sql-map-config-2.dtd">

<!-- 매핑정보를 담은 파일의 클래스 패스를지정, 매핑파일마다 <sqlMap> 태그를 추가 -->
<sqlMapConfig>
		<sqlMap resource="springboot/learningtest/spring/ibatis/Member.xml"/>
</sqlMapConfg>

DB 커넥션과 트랜잭션 관리를 위한 정보는 iBatis 설정파일이 아닌 스프링 빈으로 등록한 것을 사용하는게 바람직한 방법

스프링의 DI 기법으로 DataSource 변경도 쉽고 트랜잭션 기능을 iBatis DAO도 이용 가능

매핑파일

SQL-오브젝트 사이의 매핑정보는 XML 파일로 만듬

사용할 SQL 문과 SQL 파라미터, 실행 결과를 자바 오브젝트로 변환할지에 대해 정의

각 SQL은 고유한 아이디를 가지며, DAO에서는 아이디를 이용해 SQL을 실행
- ‘#’으로 둘러싸인 부분은 이름 치환자 (스프링 JDBC의 ‘:’ 이용한 것과 비슷)
- 테이블의 컬럼 이름과 매핑할 오브젝트의 프로퍼티 이름이 일치하면 자동으로 파라미터와 결과의 전환이 가능, 불일치할 경우 매핑 정보를 추가

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMap
		PUBLIC "-//ibatis.apache.org/DTD SQL Map 2.0//EN"
		"http://ibatis.apache.org/dtd/sql-map-2.dtd">

<sqlMap namespace="Member">
		<typeAlias alias="Member" type="springbook.learningtest.spring.jdbc.Member"/>
		
		<delete id="deleteMemberAll">
				delete from member
		</delete>

		<insert id="insertMember" parameterClass="Member">
				insert into member(id, name, point) values(#id#, #name#, #point#)
		</insert>

		<select id="findMemberById" parameterClass="int" resultClass="Member">
				select * from member where id = #id#
		</select>
	
		<select id="findMembers" resultClass="Member">
				select * from meber order by id
		</select>
</sqlMap>

SqlMapClient를 위한 SqlMapClientFactoryBean 등록

DAO가 iBatis 기능을 사용하려면 SqlMapClient가 필요

JDBC의 Connection처럼 모든 데이터 액세스 작업에 필요로 하는 오브젝트

SqlMapClient를 싱글톤 빈으로 등록해서 필요한 DAO에서 DI받아 사용 가능
- 멀티 스레드에서 공유해서 사용해도 안전한 오브젝트

SqlMapClientFactoryBean을 이용해 팩토리 빈이 생성해줘야 함, 필요한 프로퍼티는 DataSource와 앞에서 만들어둔 설정파일의 위치

<bean id="sqlMapClient"
			class="org.springframework.orm.ibatis.SqlMapCleintFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="configLocation"
							value="springbook/learningtest/spring/ibatis/SqlMapConfig.xml" />
</bean>

2.3.2 SqlMapClientTemplate

iBatis용 DAO는 SqlMapClient 빈을 DI 받아서 iBatis 기능을 이용

SqlMapClient를 직접 사용하는 대신 스프링이 제공하는 템플릿 오브젝트인 SqlMapClientTemplate를 이용하는 것이 좋음
- 스프링 데이터 액세스 기술이 제공하는 다양한 혜택을 제공 받음
- 사용방법은 JdbcTemplate과 거의 유사하며, 예외 변환, 스프링 트랜잭션과 동기화 등이 지원

public class MemberDao {
		private SqlMapClientTemplate sqlMapClientTemplate;

		public void setSqlMapClient(SqlMapClient sqlMapClient) {
				sqlMapClientTemplate = new SqlMapClientTemplate(sqlMapClient);
		}

SqlMapClientTemplate를 직접 생성하는 대신 스프링이 재공하는 SqlMapClientDaoSupport를 상속해 DAO를 만들어도 사용 가능
- SqlMapClient를 DI 받아서 템플릿을 만들어주는 기능이 포함
- 템플릿 오브젝트는 getSqlMapClientTemplate()로 가져와서 사용 가능
```
public class MemberDao extends SqlMapClientDaoSupport {
		public void insert(Member member) {
				getSqlMapclientTemplate().insert("insertMember", member);
		}
}
```

등록, 수정, 삭제

insert()

SQL 아이디와 파라미터 오브젝트를 넣어주면 해당 INSERT 문을 실행

내부적으로 iBatis의 SqlMapExecutork의 isnert()가 사용

Ojbect insert(String statementName)
Object insert(String statementName, Object parameterObject)

update()

SQL 아이디와 파라미터 오브젝트를 제공하면 해당 UPDATE 문을 실행

내부적으로 SqlMapExecutor의 update()가 사용

int update(String statementtName)
int update(String statementName, Object parameterObject)

//영향을 받은 로우의 개수를 체크
//기대했던 로우의 개수와 실행결과가 일치하지 않으면 예외가 발생
void update(String statementName, Object parameterObject, 
			int requiredRowsAffected)

delete()

매핑파일에 정의된 DELETE문을 실행

SqlMapExecutor의 delete() 가 사용

메소드의 실행은 update()와 비슷

int delete(String statementName)
int delete(String statementName, Object parameterObject)
void delete(String statementName, Object parameterObject, 
			int requiredRowsAffected)

sqlMapClientTemplate을 갖고 있는 DAO라면 아래와 같이 작성 가능

public void insert(Member member) {
		sqlMapClientTemplate.insert("insertMember", member);
}

public void deleteAll() {
		sqlMapClientTemplate.delete("deleteMemberAll");
}

조회

단일 로우 조회: queryForObject()

SQL의 실행 결과가 한 건인 경우에 사용

리턴 오브젝트는 매핑파일에 지정된 타입이 사용

Object queryForObject(String statementName)
Object queryForObject(String statementName, Object parameterObject)
Object queryForObject(String statementName, Object parameterObject,
				Object resultObject)

다중 로우 조회: queryForList()

SQL 실행 결과가 한 건 이상인 경우 각 로우를 오브젝트에 담고 리스트로 리턴

List queryForList(String statementName)
List queryForList(String statementName, Object ParameterObject)
List queryForList(String statementName, int skipResult, int maxResults)
List queryForList(String statementName, Object parameterObject, int skipResults,
									int maxResults)

다중 로우 조회: queryForMap()

스프링 JDBC의 queryForMap()과 이름은 비슷하지만 맵에 내용이 담기는 방식은 전혀 다르므로 주의가 필요

iBatis의 queryForMap()은 다중 로우를 가진 결과를 조회할 때 사용

맵의 키는 지정된 컬럼 값이 사용

Map queryForMap(String statementName, Object parameterObject,
								String keyProperty)
Map queryForMap(String statementName, Object parameterObject,
								String keyProperty, String valueProperty)

다중 로우 조회: queryWithRowHandler()

스프링 JDBC의 RowMapper처럼 SQL의 결과를 루프로 돌면서 각 로우마다 콜백 오브젝트를 호출해주는 방식

RowMapper는 각 로우를 매핑해서 돌려주는 것이 목적인 데 반해서 queryWithRowHandler()의 RowHandler는 그 자체로 해당 로우를 매핑한 결과를 어떻게 처리할지를 스스로 결졍

조회된 로우의 개수가 매우 많다면 리스트나 맵에 담는 것보다 각 로우를 직접 처리하는 방법을 쓰는편이 좋음

RowHandler는 iBatis에서 직접 제공되는 콜백 인터페이스

queryWithRowHandler()는 결과를 리스트에 담는 목적이 아니라 리턴이 없음

void queryWithRowHandler(String statementName, RowHandler rowHandler)
void queryWithRowHandler(String statementName, Object parameterObject,
												RowHandler rowHandler)

SqlMapClientCallback

콜백이 내장된 템플릿 메소드를 이용하는 대신 직접 iBatis의 SqlMapExecutor의 API를 사용하고 싶다면 SqlMapClientCallback 인터페이스를 사용

public interface SqlMapClientCallback<T> {
		T doInSqlMapClient(SqlMapExecutor executor) throw SQLException;
}

이 인터페이스를 구현한 콜백 오브젝트를 SqlMapClientTemplate의 execute()에 전달

public <T> T execute(SqlMapClientCallback<T> action)

SqlMapClientCallback은 iBatis API의 사용법을 충분히 숙지 후 스프링 템플릿/콜백 방식의 동작원리를 잘 이해한 후에 사용

[토비의 스프링 - Vol.2] 2장 - 2.2 JDBC

밀리노트 — Mon, 17 Jan 2022 22:14:30 +0900

2.2 JDBC

자바의 데이터 액세스 기술의 기본이 되는 로우 레벨의 API

JDBC는 표준 인터페이스를 제공하고 각 DB 벤더와 개발팀에서 이 인터페이스를 구현한 드라이버를 제공하는 방식으로 사용

JDBC는 모든 자바의 데이터 액세스 기술의 근간

2.2.1 스프링 JDBC 기술과 동작원리

스프링 3.0에서는 다섯 가지 종류의 접근 방법을 제공

JdbcTemplate는 그중에서 가장 오래된 기초적인 접근 방법

스프링의 JDBC 접근 방법

접근 방법 중에서 가장 사용하기 편하고 자주 이용되는 것은 다음 두가지

SimpleJdbcTemplate

jdbcTemplate과 NameParameterJdbcTemplate에서 가장 많이 사용되는 기능을 통합하고 자바 5 이상의 장점을 최대한 활용할 수 있게 만든 방식

방대한 템플릿 메소드와 내장된 콜백을 제공

JDBC의 모든 기능을 최대한 활용할 수 있는 유연성을 지님

SimpleJdbcInsert, SimpleJdbcCall

이 두가지 접근 방법은 DB가 제공해주는 메타정보를 활용해서 최소한의 코드만으로 단순한 JDBC 코드를 작성 가능

메타정보에서 컬럼 정보와 파라미터 정보를 가져와서 삽입용 SQL과 프로시저 호출 작업에 사용해주기 때문에 매우 편리

스프링 JDBC가 해주는 작업

Connection 열기와 닫기

스프링 JDBC를 사용하면 코드에서 직접 Connection을 열고 닫는 작업이 필요 없음

Connection과 관련된 모든 작업은 스프링 JDBC가 필요한 시점에서 알아서 진행

Connectio을 열고 닫는 시점은 스프링 트랜잭션 기능과 맞물려서 결졍

같은 코드와 DAO라고 해도 트랜잭션 경계를 어떻게 선언해뒀고 어떤 순서로 호출하느냐에 따라서 매번 Connection을 열고 닫는 위치가 달라짐

Statement 준비와 닫기

SQL 정보가 담긴 Statement 또는 PreparedStatement를 생성하고 필요한 준비 작업을 해주는 것도 대부분 스프링 JDBC의 몫

준비된 Statement는 콜백 오브젝트가 전달받아서 사용

콜백을 직접 만들기보다는 스프링 JDBC가 미리 만들어 놓은 것을 사용하는 경우가 많음 그래서 직접 Statement를 사용하는 코드는 많지 않음

Statement도 Connection과 마찬가지로 사용이 끝나고 스프링 JDBC가 알아서 반환

Statement 실행

SQL이 담긴 Statement를 실행하는 것도 스프링 JDBC의 몫

ResultSet 루프

ResultSet에 담긴 쿼리 실행 결과가 한 건 이상이라면 루프를 돌면서 각각의 로우들에 대해 처리가 필요

ResultSet의 루프를 만들어 반복해주는 것도 스프링 JDBC가 해주는 작업

ResultSet 각 로우의 내용을 어떻게 오브젝트에 담을 것인지는 루프 안에서 실행되는 콜백으로 만들어 템플릿에 제공해주면 됌

어떤 경우 각 로우의 매핑을 위해 콜백을 직접 작성하기 보다는 스프링 JDBC가 미리 정해둔 포맷의 오브젝트나 컬렉션으로 전환하고 이를 전달받는 것이 편리

트랜잭션 처리

스프링 JDBC는 트랜잭션 동기화 기법을 이용해 선언적 트랜잭션 기능과 맞물려 실행

트랜잭션을 시작한 후에 스프링 JDBC의 작업을 요청하면 진행 중인 트랜잭션에 참여

트랜잭션이 없는 채로 호출된 경우 새로운 트랜잭션을 만들어서 사용

스프링 JDBC가 대부분 작업을 해주기 떄문에 데이터 액세스 로직만 정의해주면 됌

많은 경우 실행할 SQL과 바인딩할 파라미터를 넘겨주거나 쿼리의 실행 결과를 어떤 오브젝트에 어떻게 넣어서 받을지 지정해주는 역할만 해주면 됌

SimpleSqlInsert를 사용하면 SQL도 생략 가능

스프링 개발자가 해야하는 한가지는 DB 커넥션을 가져올 DataSource를 정의해주는 것

2.2.2 SimpleJdbcTemplate

스프링 JDBC를 사용한다면 가장 많이 이용하게 될 JDBC용 템플릿

SimpleJdbcTemplate이 제공하는 기능은 실행, 조회, 배치의 세가지 작업으로 구분
- 실행 작업은 INSERT, UPDATE와 같이 DB의 데이터 변경이 일어나는 작업
- 조회는 SELECT를 이용해 결과를 가져오는 작업
- 배치는 하나 이상의 실행 작업을 한 번에 수행해줘야하는 작업

SimpleJdbcTemplate 생성

SimpleJdbcTemplate은 DataSource를 파라미터로 해서 다음과 같이 생성

SimpleJdbcTemplate template = new SimpleJdbcTemplate(dataSource);

DataSource는 보통 빈으로 등록하므로 필요한 DAO에서 DataSource 빈을 DI 받아서 SimpleJdbcTemplate를 생성해두고 사용

SimpleJdbcTemplate은 멀티스레드 환경에서도 안전하게 공유해서 쓸 수 있기 때문에 DAO의 인스턴스 변수에 저장해두고 사용 가능

SimpleJdbcTemplate 자체를 싱글톤 빈으로 등록하고 모든 DAO에 공유해서 사용도 가능

스프링 개발자는 관례적으로 DAO의 코드에서 DataSource를 받아 SimpleJdbcTemplate를 생성하는 방식을 선호
- DataSource가 있으면 다른 스프링 JDBC 오브젝트를 만들어 사용이 가능하기 떄문
```
public class MemberDao {
		SimpleJdbcTemplate simpleJdbcTemplate;
		public void setDataSource(DataSource dataSource) {
				this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
		}
}
```
- 애노테이션 방식을 이용한다면 @Autowired나 @Resource를 붙이거나 메소드에 의한 주입 방법이나 생성자 주입을 이용해서도 사용 가능
```
@Autowired
public void init(DataSource dataSource) {
		this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
}
```

SQL 파라미터

SimpleJdbcTemplate에 작업을 요청할 때는 문자열로 된 SQL 제공이 필요

SQL에 매번 달라지는 값이 있는 경우에는 ‘?’와 같은 치환자를 넣어 파라미터 바인딩 방법을 사용하는 것이 편리

스프링 JDBC는 JDBC에서 제공하는 위치를 이용한 치환자인 ‘?’뿐 아니라 명시적으로 이름을 지정하는 이름 치환자도 지원

위치 치환자를 사용하는 경우에는 파라미터의 개수가 많으면 실수하기 쉬움

또한 치환자의 순서를 바꾸거나 추가, 삭제하는 작업도 어려움

SQL을 사용하는 예시

//실행할 SQL
INSERT INTO MEMBER(ID, NAME, POINT) VALUES(1, 'Spring', 2.3);

//위치 치환자
INSERT INTO MEMBER(ID, NAME, POINT) VALUES(?, ?, ?);

//이름 치환자
INSERT INTO MEMBER(ID, NAME, POINT) VALUES(:id, :name, :point);

이름 치환자의 또 다른 장점은 맵이나 오브젝트에 담긴 내용을 키 값이나 프로퍼티 이름을 이용해 바인딩 할 수있다는 점

Map / MapSqlParameterSource

Map<String, Object> map = new HashMap<String, Object>();
map.put("id", 1);
map.put("name", "Spring");
map.put("point", 3.5);

map은 이름 치환자를 가진 SQL과 함께 SimpleJdbcTemplate에 전달돼서 바인딩 파라미터로 사용 가능

맵의 키 값과 일치하는 치환자에 맵의 값이 자동으로 삽입

코드를 이용해 맵에 정보를 직접 넣어야 한다면 Map 대신 스프링 JDBC의 MapSourceParameterSource를 사용하는 것이 편리

MapSqlParameterSource params = new MapSqlParameterSource()
																		.addValue("id", 1)
																		.addValue("name", "Spring")
																		.addValue("point", 3.5);

BeanPropertySqlParameterSource

Map 대신 도메인 오브젝트나 DTO를 사용하게 해줌

오브젝트의 프로퍼티 이름과 SQL의 이름 치환자를 매핑해 파라미터 값을 넣어주는 방식

도메인 오브젝트의 파라미터와 SQL 치환자의 이름만 같게 만들면 매우 편리

public class Member {
		int id;
		String name;
		double point;

		public int getId() {return this.id;}
		...
}

Member member = new Member(1, "Spring", 3.5);
BeanPropertySqlParameterSource params = new BeanPropertySqlParameterSource(member);

SQL 실행 메소드

INSERT, UPDATE, DELETE와 같은 SQL을 실행할 때는 SimpleJdbcTemplate의 update()를 사용

update()를 호출할 때는 SQL과 함께 바인딩할 파라미터를 다음 세가지 방식 중 하나로 전달

varargs

위치 치환자를 사용하는 경우 바인딩할 파라미터 순서대로 전달

simpleJdbcTemplate.update(
		"INSERT INTO MEMBER(ID, NAME, POINT, args) VALUES(?,?,?)", 1, "Spring", 1.5);

파라미터는 가변인자이므로 필요 없다면 생략 가능

simpleJdbcTemplate.update("delete from member");

Map

이름 치환자를 사용한다면 파라미터를 Map으로 전달

simpleJdbcTemplate.update(
		"INSERT INTO MEMBER(ID, NAME, POINT, args) VALUES(:id, :name, :point)", map);

SqlParameterSource

도메인 오브젝트나 DTO를 이름 치환자에 직접 바인당하려면 SqlParameterSource 타입인 BeanPropertySqlParameterSource를 사용해 update()를 호출

simpleJdbcTemplate.update(
		"INSERT INTO MEMBER(ID, NAME, POINT, args) VALUES(:id, :name, :point)",
		new BeanPropertySqlParameterSource(member));

파라미터를 직접 지정하려면 MapSqlParameterSource의 addValue()를 이용

simpleJdbcTemplate.update(
		"INSERT INTO MEMBER(ID, NAME, POINT, args) VALUES(:id, :name, :point)",
		new MapSqlParameterSource()
			.addValue("id", 1).addValue("name", "Spring").addValue("point", 3.5"));

SimpleJdbcTemplate의 update()는 SQL 실행으로 영향을 받은 레코드의 개수를 리턴

SQL 조회 메소드

SELECT를 이용하는 조회용 메소드는 단순 값이나 오브젝트를 가져오는 경우와 리스트를 가져오는 경우로 구분

int queryForInt(String sql, [SQL 파라미터])

하나의 int 타입 값을 조회할 때 사용

[SQL 파라미터]에 사용할 수 있는 방법들
- 위치 치환자에 사용하는 Object 타입 가변인자(Object... args)
- 이름 치환자에 사용할 수 있는 맵(Map<String, ?> args)
- SQL 파라미터 소스(SqlParameterSource args)

파라미터가 없는 단순한 쿼리라면 다음과 같이 SQL 파라미터 생략이 가능

int count = simpleJdbcTemplate.queryForInt("select count(*) from member");

simpleJdbcTemplate.queryForInt("select count(*) from member point > :min",
				new MapSqlParameterSource("min", min));

queryForInt()의 실행 결과는 한 개의 숫자 컬럼만 가져야하며, 아닌 경우 예외 발생

long queryForLong(String sql, [SQL 파라미터])

하나의 long 타입 값을 조회할 때 사용

리턴 타입만 다를 뿐 사용 방법은 queryForInt()와 동일

<T> T queryForObject(String sql, Class<T> requiredType, [SQL 파라미터])

쿼리를 실행해서 하나의 값을 가져올 떄 사용, 결과 타입을 직접 지정 가능

SQL 실행 결과는 하나의 컬럼을 가진 하나의 로우, 아닌 경우 예외 발생

String name = simpleJdbcTemplate.queryForObject(
		"select name from member where id = ?", String.class, id);

검색된 로우가 없다면 EmptyResultDataAccessException 예외가 발생

쿼리의 결과가 없어도 예외가 던져지길 원하지 않는다면 DAO에서 직접 처리 필요

try {
		return simpleJdbcTemplate.queryForObject(
		"select name from member where id = ?", String.class, id);
} catch(EmptyResultDataAccessException) {
		return null;
}

<T> T queryForObject(String sql, RowMapper<T> rm, [SQL 파라미터])

SQL 실행 결과, 하나의 로우가 돌아오는 경우에 사용

단일 컬럼이 아니라 다중 컬럼을 가진 쿼리에 사용할 수 있다는 장점

다중 컬럼을 가진 결과이므로 도메인 오브젝트나 DTO처럼 여러 개의 프로퍼티 오브젝트로 전환 필요

테이블의 컬럼 이름과 매핑될 오브젝트의 프로퍼티 이름이 일치한다면 RowMapper를 직접 구현하는 대신 BeanPropertyRowMapper<T>를 사용하는 것이 편리
- 생성자에 매핑할 클래스를 넣어서 오브젝트를 생성하면 주어진 클래스의 프로퍼티 이름과 SQL 결과를 자동 매핑해주는 RowMapper 콜백 오브젝트로 사용
```
Member m = simpleJdbcTemplate.queryForObject(
	"select * from member where id=?"
	, new BeanPropertyRowMapper<Member>(Meber.class)
	, id)	
```

queryForObject()는 단일 조회, 결과가 없거나 여러 개의 로우로 돌아면 예외 발생

<T> List<T> query(String sql, RowMapper<T> rm, [SQL 파라미터])

SQL 실행 결과로 여러 개의 컬럼을 가진 로우를 RowMapper 콜백을 이용해 도메인 오브젝트나 DTO에 매핑

query()는 여러 개의 로우를 처리 가능, 리스트의 각 요소가 하나의 로우에 해당

로우의 개수에 제한은 없음 로우의 개수가 0이어도 예외가 발생 안함

List<Member> members = simpleJdbcTemplate.query(
	"select * from member where point > ?", 
	new BeanPropertyRowMapper<Member>(Member.class),
	point);

Map<String, Object> queryForMap(String sql, [SQL 파라미터])

queryForObject() 처럼 단일 로우의 결과를 처리하는데 사용

RowMapper를 이용해 도메인, DTO에 매핑하는 대신 맵에 로우 내용을 저장해서 리턴

저장할 오브젝트를 매번 정의하기 번거롭거나 맵의 사용이 편리한 환경에서 유용

맵의 키에는 컬럼 이름이 들어가고 값에는 컬럼의 값이 저장

Map<String, Object> map = simpleJdbcTemplate.queryForMap(
	"select * from member where id = ?", id);

SQL 실행 결과는 하나의 로우를 돌려주는 것이 보장 필요, 그 외엔 오류 발생

조회 결과를 서비스 계층의 비즈니스 로직에 활용할 경우 컬럼 값을 매번 적절한 타입으로 캐스팅해줘야 하는 번거로움 발생

List<Map<String, Object>> queryForList(String sql, [SQL 파라미터])

queryForMap()의 다중 로우 버전, 로우의 내용을 Map에 넣고 리스트로 만들어 리턴

SQL 배치 메소드

update()로 실행하는 SQL들을 배치 모드로 실행하게 해줌

내부적으로 JDBC Statement의 addBatch()와 executeBatch()를 이용해 여러 개의 SQL을 한번에 처리

많은 SQL을 실행해야 하는 경우 배치 방식을 사용하면 DB 호출을 최소화하여 성능 향상

모든 배치 메소드는 하나의 SQL과 SQL 파라미터 배열을 파라미터로 가짐

int[] batchUpdate(String sql, Map<String, ?>[] batchValues)

이름 치환자를 가진 SQL과 파라미터 정보가 담긴 맵의 배열을 이용

배열의 개수만큼 SQL을 실행하며, 리턴 값은 영향받은 로우의 개수를 담은 배열

int[] batchUpdate(String sql, SqlParameterSource[] batchArgs)

맵 대신 SqlParameterSource 타입 오브젝트의 배열로 파라미터를 제공

MapSqlParameterSource와 BeanPropertyParameterSource는 모두 SqlParameterSource 타입이므로 함꼐 사용 가능

dao.simpleJdbcTemplate.batchUpdate("update member set name = :name where id = :id",
		new SqlParameterSource[] {
				new MapSqlParameterSource().addValue("id", 1).addValue("name", "Spring3"),
				new BeanPropertySqlParameterSource(new Member(2, "Book3"))
		}
};

int[] batchUpdate(String sql, List<Object[]> batchARgs)

위치 치환자를 사용할 때 varags로 전달했던 파라미터를 Object 배열에 넣고 이를 List로 만들어서 전달 가능

JdbcTempate에서 제공하는 좀 더 세밀한 템플릿/콜백 방식을 이용하고 싶다면 getJdbcOperations()를 이용, JdbcTemplate이 제공하는 메소드를 직접 이용 가능

2.2.3 SimpleJdbcInsert

SQL을 이용하는 프로그래밍의 귀찮은 일은 비슷한 구조의 SQL을 반복적으로 만드는 점

특히 모든 컬럼을 다 적어야하는 INSERT 문의 작성은 가장 귀찮은 일

SQL은 런타임 시에 DB에서 처리되기 떄문에 빌드 시점에서 미리 검증X (쿼리 오타 빈번)

DB 메타정보를 활용해서 INSERT 문의 작성을 간편하게 만들어주는 것이 SimpleJdbcInsert

SimpleJdbcInsert 생성

SimpleJdbcInsert는 테이블별로 만들어서 사용

하나의 DAO에서 여러 개의 SimpleJdbcInsert를 사용 가능

SimpleJdbcTemplate은 멀티스레드 환경에서 안전하게 공유해서 사용 가능

생성할 떄는 DataSource가 필요

SimpleJdbcInsert jdbcInsert = new SimpleJdbcInsert(dataSource);

SimpleJdbcInsert withTableName(String tableName)

테이블 이름을 지정, DB로부터 테이블 메타정보를 읽어서 INSERT 문에 활용

SimpleJdbcInsert jdbcInsert =
		new SimpleJdbcInsert(dataSource).withTableName("member");

SimpleJdbcInsert withSchemaName(String schemaName), SimpleJdbcInsert withCatalogName(String catalogName)

스키마와 카탈로그 이름을 지정해야 할 경우 사용

SimpleJdbcInsert usingColumns(String... columnNames)

SimpleJdbcInsert는 기본적으로 테이블의 모든 컬럼을 사용해서 INSERT문을 작성

usingColumns()를 사용하면 일부 컬럼만 사용해서 INSERT문을 작성

SimpleJdbcInsert usingGeneratedKeyColumns(String... columnNames)

DB에 의해 자동으로 생성되는 키 컬럼을 지정 가능

지정된 컬럼은 INSERT 문장에서 제외, 자동 키 값은 INSERT 실행 후 가져오는 것 가능

SimpleJdbcInsertOperations withoutTableColumnMetaDataAccess()

DB에서 테이블 메타 정보를 가져오지 않도록 만듬

일부 DB는 메타정보를 제공해주지 않는데 이때 사용

DB의 메타정보 대신 파라미터로 제공된 정보를 활용해서 INSERT 문을 작성

SimpleJdbcInsert 실행

int execute([이름 치환자 SQL 파라미터])

SimpleJdbcInsert가 내부적으로 생성하는 SQL은 이름 치환자를 가진 INSERT 문이라고 생각하면 됌

치환자를 넣을 SQL 파라미터 지정이 필요

파라미터 지정 방법은 맵(Map<String, Object>)과 SqlParameterSource 타입 오브젝트 두 가지 종류 이용

SimpleJdbcInsert insert = new SimpleJdbcInsert(dataSource).withTableName("member");
Member member = new Member(1, "Spring", 3.5);
insert.execute(new BeanPropertySqlParameterSource(member));

SimpleJdbcInsert 오브젝트는 테이블 설정이 같다면 재사용 가능, 새롭게 만들 필요 X

Number executeAndReturnKey([이름 치환자 SQL 파라미터])

execute()와 동일한 작업을 수행하고, 자동생성된 키 값을 Number 타입으로 리턴

java.lang.Number는 숫자 타입 클래스(Integer, 등)가 모두 상속하고 있는 상위 클래스

-- 테이블 생성
CREATE TABLE REGISTER (
		ID INT PRIMARY KEY AUTO_INCREMENT,
		NAME VARCHAR(100) NOT NULL
)

-- INSERT문 (ID는 자동생성)
INSERT INTO REGISTER(NAME) VALUE('Spring')

SimpleJdbcInsert registerInsert = new SimpleJdbcInsert(dataSource)
																	.withTableName("register")
																	.usingGeneratedKeyColumns("id");
int ket = registerInsert.executeAndReturnKey(
					new MapSqlParameterSource("name", "Spring")).intValue();

KeyHolder executeAndReturnKeyHolder([이름 치환자 SQL 파라미터])

하나 이상의 자동생성 키 컬럼을 갖는 테이블도 존재

Number 대신 KeyHolder 타입으로 생성된 키 정보를 돌려주는 executeAndReturnKeyHolder()를 이용

usingGeneratedKeyColumns()를 초기화할 때 하나 이상의 자동생성 키 컬럼을 넣음

KeyHolder는 키 이름과 생성된 값이 담긴 List<Map<String, Object>> 타입으로 돌려주는 getKeyList()를 제공

2.2.4 SimpleJdbcCall

DB에 생성해둔 저장 프로시저 또는 저장 펑션을 호출할 떄 사용

SimpleJdbcCall 생성

dataSource를 이용해 생성

멀티스레드 환경에 안전하므로 인스턴스 변수에 저장해두고 공유해서 사용 가능

SimpleJdbcCallOperations withProcedureName(String procedureName)

실행할 프로시저 이름을 지정

SimpleJdbcCallOperations withFunctionName(String functionName)

실행할 펑션의 이름을 지정

SimpleJdbcCallOperations returningResultSet(String parameterName, parameterizedRowMapper rowMapper)

프로시저가 ResultSet을 돌려주는 경우에 이를 RowMapper를 이용해 매핑

하나 이상의 ResultSet이 돌아오는 경우라면 순차적으로 returningResultSet()을 지정

SimpleJdbcCall 실행

DB의 메타정보를 이용해 필요한 파라미터 정보를 가져옴

프로시저나 펑션을 실행할 때는 이에 맞게 파라미터 값을 전달

<T> T executeFunction(Class<T> returnType, [SQL 파라미터])

저장 펑션을 실행해주는 메소드, 리턴 값의 타입과 SQL 파라미터를 전달해서 사용

create function find_name(in_id INT)
returns varchar(255)
begin
		declare out_name varchar(255);
		select name
				into out_name
				from member
				where id = in_id;
		return out_name;
end

SimpleJdbcCall call = new SimpleJdbcCall(dataSource).withFunctionName("find_name");
String ret = call.executeFunction(String.class, id);

<T> T executeObject(Class<T> returnType, [SQL 파라미터])

저장 프로시저를 호출할 때 사용

프로시저의 출력 파라미터가 하나일 때만 이용, 사용방법은 executeFunction()과 동일

Map<String, Object> execute([SQL 파라미터])

하나 이상의 출력 파라미터를 가진 저장 프로시저를 호출할 때 사용

여러 개의 출력 파라미터 값이 맵의 형태로 리턴, 리턴 타입을 따로 지정할 필요 X

2.2.5 스프링 JDBC DAO

보통 DAO는 도메인 오브젝트 또는 DB 테이블 단위로 생성

JdbcTemplate, SimpleJdbcTemplate, SimpleJdbcInsert 등은 모두 멀티스레드 환경에서 안전하게 공유해서 사용 가능

각각을 싱글톤 빈으로 등록해두고 이를 DAO에서 DI 받아서 사용 가능, 하지만 스프링 개발자는 DataSource 타입의 빈을 DI 받은 뒤 DAO 코드에서 템플릿 오브젝트 등을 생성해서 자주 사용

SimpleJdbcInsert와 SimpleJdbcCall은 테이블이나 저장 프로시저 단위로 오브젝트를 만들어야 하기 떄문에 DAO마다 다른 SimpleJdbcInsert가 사용되는 경향

모든 JDBC 오브젝트는 한번 만들어지면 반복적으로 사용 가능하기 떄문에 초기에 만들어 인스턴스 변수에 저장해두는 것이 편리

public class MemberDao {
		private SimpleJdbcTemplate simpleJdbcTemplate;
		private SimpleJdbcInsert memberInsert;
		private SimpleJdbcCall memberFindCall;

		@Autowired
		public void init(DataSource dataSource) {
				this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
				this.memberInsert = new SimpleJdbcInsert(dataSource).withTableName("member");
				this.memberFindCall = 
						new SimpleJdbcCall(dataSource).withFunctionName("find_member");
		}

SimpleJdbcTemplate을 생성하는 코드의 중복을 제거하는 방법은 두가지
1. SimpleJdbcTemplate를 독립적인 빈으로 등록하고 주입받는 방법
1. DAO의 공통 코드를 뽑아내 추상 클래스를 만들어두고 모든 DAO가 이를 상속하는 방법

스프링은 JdbcDaoSupport라는 JDBC를 이용한 DAO 작성에 사용할 수 있는 추상클래스를 제공
- DataSource의 DI와 JdbcTemplate의 생성과 같은 공통 기능을 담은 클래스
- SimpleJdbcDaoSupport는 SimpleJdbcTemplate을 사용하는 DAO를 만들때 사용

AbstractSimpleJdbcDaoSupport는 JdbcDaoSupport를 확장해서 SimpleJdbcTemplate 생성과 초기화를 담당하는 메소드를 자동으로 실행해주는 기능을 가진 추상 클래스
- initJdbcObjects()를 오버라이드해서 SimpleJdbcInsert 등을 생성하는 코드를 넣으면 됌

public abstract class AbstractSimpleJdbcDaoSupport extends JdbcDaoSupport {
		protected SimpleJdbcTemplate simpleJdbcTemplate;
		
		//JdbcDaoSupport에서 제공하는 초기화용 메소드, dataSource가 준비 된 후 호출
		protected void initTemplateConfig() {
				this.simpleJdbcTemplate = new SimpleJdbcTemplate(getDataSource());
				initJdbcObjects();
		}
		
		//SimpleJdbcDaoSupport를 상속받는 DAO에서 SimpleJdbcInsert 등을 생성할 때 
		//오버라이드해서 사용할 수 있는 초기화 메소드
		protected void initJdbcObjects() {}
}