토비의 스프링 3.1 요약 정리

스프링은 싱글톤, 프로토타입외에 요청(request), 세션(session), 글로벌세션(globalSession), 애플리케이션(application)이라는 네 가지 스코프를 기본적으로 제공한다. 
이 스코프는 모두 웹 환경에서만 의미 있다. 
 
이 네가지 스코프 중에서 application을 제외한 나머지 세 가지 스코프는 싱글톤과 다르게 독립적인 상태를 저장해두고 사용하는데 필요하다. 
 
요청스코프
 
요청 스코프 빈은 하나의 웹 요청 안에서 만들어지고 해당 요청이 끝날 때 제거된다.
각 요청별로 독립적인 빈이 만들어지기 때문에 빈 오브젝트 내에 상태 값을 저장해 둬도 안전하다. 요청 스코프 빈은 프로토타입과 마찬가지로 DL을 사용하는 것이 편리하지만 원한다면 DI를 이용할 수도 있다. 하나의 웹 요청을 처리하는 동안에 참조 하는 요청 스코프 빈은 항상 동일한 오브젝트임이 보장된다. 동시에 웹 요청이 달라 지면 별도의 요청 스코프 빈이 만들어지기 때문에 동시에 여러 사용자가 많은 요청 을 보내도 안전하다.
존재 범위와 특징은 하나의 요청이 일어나는 메소드 파라미터로 전달되는 도메인 오브젝트나 DTO와 비슷하다. 그렇기 때문에 애플리케이션 코드에서 요청 스코프의 빈을 사용할 이유가 많지는 않다. 하나의 요청 안에서 유지되는 정보는 메소드 호출 이 일어나는 동안 파라미터와 리턴 값으로 오브젝트를 전달해주면 된다.
요청 스코프 빈의 주요 용도는 애플리케이션 코드에서 생성한 정보를 프레임워크 레벨의 서비스나 인터셉터 등에 전달하는 것이다. 또는 애플리케이션 코드가 호출되 기 전에 프레임워크나 인터셉터 등에서 생성한 정보를 애플리케이션 코드에서 이용 할 때도 유용하다. 예를 들어 보안 프레임워크에서 현재 요청에 관련된 권한 정보를 요청 스코프 빈에 저장해뒀다가 필요한 빈에서 참조하게 할 수 있다.
 
 
세션스코프, 글로벌세션스코프
HTTP 세션과 같은 존재 범위를 갖는 빈으로 만들어주는 스코프다. HTTP 세션은 사용자별로 만들어지고 브라우저를 닫거나 세션 타임이 종료될 때까지 유지되기 때 문에 로그인 정보나 사용자별 선택옵션 등을 저장해두기에 유용하다.
하지만 HTTP 세션을 직접 이용하는 전 매우 번거롭고 귀찮은 일이고, 웹 환경 정보에 접근할 수 있는 계층에서만 가능한 작업이다. 서비스 계층이나 데이터 액세스 계층에서 HTTP 세션에 접근하려 한다면 문제가 된다. 그렇다고 웹 환경에 종속적인 Httpsession 오 브젝트를 다른 계층으로 넘겨서 사용하게 하는 건 매우 나쁜 방법이다. 결국 HTTP 세션에 저장되는 정보를 웹 기술에 종속적이지 않은 오브젝트에 담아서 HTTP 세션 에 직접 접근 가능한 프레젠테이션 계층과 서비스 계층 사이에서 주고받아야 한다.
세션 스코프를 이용하면 이런 번거로움 없이도 HTTP 세션에 저장되는 정보를 모든 계층에서 안전하게 이용할 수 있다. 웹 페이지가 바뀌고 여러 요청을 거치는 동안 에도 세션 스코프 빈은 계속 유지된다. HTTP 세션은 사용자별로 만들어지기 때문에 중복의 위험도 없다.
글로벌세션 스코프는 포틀릿에만 존재하는 글로벌 세션에 저장되는 빈이다.
 
애플레케이션 스코프
애플리케이션 스코프는 서블릿 컨텍스트에 저장되는 빈 오브젝트다. 서블릿 컨텍스 트는 웹 애플리케이션마다 만들어진다. 웹 애플리케이션마다 스프링의 애플리케이 션 컨텍스트도 만들어진다. 따라서 애플리케이션 스코프는 컨텍스트가 존재하는 동 안 유지되는 싱글톤 스코프와 비슷한 존재 범위를 갖는다. 그렇다면 싱글톤 스코프 를 사용하면 될 텐데 애플리케이션 스코프가 따로 존재하는 이유는 무엇일까? 그것 은 드물지만 웹 애플리케이션과 애플리케이션 컨텍스트의 존재 범위가 다른 경우가 있기 때문이다. 웹 애플리케이션 밖에서 더 오랫동안 존재하는 컨텍스트도 있고 더 짧은 동안 존재하기도 하는 서블릿 레벨의 컨텍스트도 있기 때문이다.
애플리케이션 스코프는 싱글톤 스코프와 마찬가지로 상태를 갖지 않거나, 상태가 있다고 하더라도 읽기전용으로 만들거나, 멀티스레드 환경에서 안전하도록 만들어야한다.
 
 
 

iBatis SqlMaps
Batistatp://ibatis.apache.org)는 자바오브젝트와 SOL 문 사이의 자동매핑 기능을 지원하 는 ORM 프레임워크다. iBatis는 코드 내에서 자바오브젝트만을 이용해 데이터 로직 을 작성할 수 있게 해주고, SOL을 별도의 파일로 분리해서 관리하게 해주며, 오브젝 트-50L 사이의 파라미터 매핑 작업을 자동으로 해주기 때문에 많은 인기를 얻고 있는 기술이다.
iBatis는 본격적인 ORM인 JPA나 하이버네이트처럼 새로운 DB 프로그래밍 패러다 임을 익혀야 하는 부담이 없다. 대부분의 개발자가 이미 익숙한 SQL을 그대로 이용할 수 있으면서도 JDBC 코드 작성의 불편함을 제거해주고, 도메인 오브젝트나 DTO를 중 심으로 개발이 가능하다는 장점이 있다.
iBatis의 가장 큰 특징은 SQL을 자바 코드에서 분리해서 별도의 XML 파일 안에 작성하고 관리할 수 있다는 점이다. 따라서 SQL에 변경이 있을 때마다 자바 코드를 수정 하고 컴파일하지 않아도 된다. 또, SQL 의 작성과 관리 또는 검토를 DBA와 같은 개발 자가 아닌 사람에게 손쉽게 맡길 수도 있다.
XML에 담긴 SQL과 자바오브젝트 사이의 매핑은 이름 치환자와 빈 프로퍼티 사이 의 매핑을 이용한다. 이런 매핑 기능은 스프링 JDBC에서도 지원한다. SQL을 외부 리 소스 파일에서 가져올 수 있다는 점을 제외하면 iBatis가 제공해주는 많은 SQL-오브젝 트 매핑 기능은 스프링 JDBC에서도 지원된다.
 
스프링 빈
Spring IoC 컨테이너가 관리하는 자바 객체를 빈(Bean)이라고 부릅니다
 
스프링 AOP ( Aspect Oriented Programming )
AOP는 Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다. 관점 지향은 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다. 여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다. 
 
@importResource
xml의 위치를 지정해준다.
xml이 꼭 필요한 빈 설정만 별도의 파일로 작성한 뒤 @configuration클래스에서 @importResource를 이용해 xml파일의 빈 설정을 가져올 수 있다.
 
@configuration
@ImportResource("/myproject/config/security.xml")
public class AppConfig {
}
 
프로퍼티
자바에서 말하는 프로퍼티는 기본적으로 키와 그에 대응되는 값의 쌍을 말한다. 스프링 빈의 프로퍼티를 예로 생각해보면 프로퍼티가 무엇인지 이해할 수 있을 것이다. 
프로퍼티 정보는 코드에서 직접 만드는 경우를 제외하면 대부분 파일과 같은 외부 리소스에 키과 값의 향태로 저장되어있다. 
 
단순히 프로퍼티 정보만 넣는다면 java. util. Properties에서 지원하는 프로퍼티 파 일 포맷을 이용하는 것이 편리하다. 지금까지 DB 관련 정보를 XML 이나 자바 코드 외 부에 둘 때는 Properties가 지원하는 프로퍼티 파일을 이용해왔다. 프로퍼티 파일은 템 스트 파일 포맷으로 되어 있다. 여기에 다음과 같이 '키=값' 형태로 프로퍼티를 기술한 다. 여기서 do.username과 db.password는 키고, Spring과 book은 값에 해당된다.
db.username=spring d.password=book
위와 같은 내용이 database.properties 파일에 저장되어 있다면 Properties 오브제 트를 이용해 다음과 같이 간단히 읽어올 수 있다.
Properties p = new Properties ();
P. load(new FileInputStream("database. properties™));
스프링에서는 <util : properties> 전용 태그를 이용해서 프로퍼티 파일의 내용을 읽 어 초기화된 Properties 타입의 빈을 다음과 같이 정의할 수 있다.

<util:properties id-"dbProperties" location="database properties" /
또는 database,properties 파일을 읽어서 그 프로퍼티 키에 대응되는 치환자를 찾아 빈의 프로퍼티 값을 업데이트해주는 기능이 있는 <context: property-placeholder>를 사용하기도 한다.
‹context:property-placeholder location-"database properties"/)
 
 
그런데 Properties가 기본적으로 지원하는 프로퍼티 파일은 ISO-8859-1 인코딩
'만을 지원하기 때문에 영문만 사용할 수 있다. 따라서 다음과 같이 영어가 아닌 문자는 사용할 수가 없다.
name=토비
 ISO-8859-1  인코딩으로 표현 불가능한 문자는 u로 시작하는 유니코드 값을 대신 사용해야 한다. 위의 내용이라면 다음과 같이 변환해서 파일을 작성해야 Properties에 서 바르게 읽을 수 있다.
name=\uD1A0\uBE44
영어 사용하는 경우라면 별문제가 없겠지만, 한글 같은 비영어권 문자가 포함된 경우라면 유니코드 값으로 변환해서 작성하는 일은 매우 번거롭다. 이럴 땐 XML 포맷 의 프로퍼티 파일을 사용하면 좋다. Properties는 LoadFromXML() 메소드를 이용해 다 음과 같이 XML 로 작성된 프로퍼티를 읽어올 수 있다.
TE

<IDOCTYPE properties SYSTEM "http: //java.sun.com/dtd/properties.dtd")
<properties>
<entry key="name">토비</entry› 
</properties›
XML 프로퍼티 파일은 UTF-8로 인코딩해서 저장해두면 된다.
스프링은 <util:properties>나 <context: property-placeholder>에서 모두 이 두 가지 포맷을 지원한다.
 
@PropertySource와 프로퍼티 파일
@PropertySource와 프로퍼티 파일
대표적인 프로퍼티 정보 저장 방식인 프로퍼티 파일도 프로퍼티 소스로 등록하고 사 용할 수 있다. ePropertysource를 이용하면 된다. 방법은 간단하다. 다음과 같이 OPropertySource 애노테이션을 @Configuration 클래스에 붙이고 프로퍼티 파일 위치 를 기본 엘리먼트 값으로 넣어주면 된다.
@Configuration
@PropertySource ("database .properties")
public class AppConfig {
 
프로퍼티 파일을 여러 개 동시에 지정할 수도 있고, 프로퍼티 소스로 등록될 때의 이름을 넣을 수도 있다. 프로퍼티 소스의 이름을 myProper tySource라 하고 두 개의 프로퍼티 파일을 넣는다면 다음과 같이 작성한다.
@PropertySource (name-"my PropertySource", value=("database properties", "settings .xmI"})
OProperty Source로 등록되는 프로퍼티 소스는 컨텍스트에 기본적으로 등록되는 프로퍼티 소스보다 우선순위가 낮다.
 
요약정리
여기서 다룬 주요 내용은 다음과 같다.
• 스프링 애플리케이션은 POJO 클래스와 빈 설정 메타정보로 구성된다.
• 빈 설정 메타정보는 특정 포맷의 파일이나 리소스에 종속되지 않는다. 필요하다면 새로운 설정정보 작성 방법을 얼마든지 만들어 사용할 수 있다.
• 스프링의 빈 등록 방법은 크게 XML.과 빈 자동인식, 자바 코드 세 가지로 구분할 수 있다.
• 스프링의 빈 의존관계 설정 방법은 XML과 애노테이션, 자바 코드로 구분할 수 있다.
• 프로퍼티 값은 빈에 주입되는 빈 오브젝트가 아닌 정보다.
• 프로퍼티 값 중에서 환경에 따라 자주 바뀌는 것은 프로퍼티 파일과 같은 별도의 리소스 형 태로 분리해놓는 것이 좋다.
• 빈의 존재 범위인 스코프는 싱글톤과 프로토타입 그리고 기타 스코프로 구분할 수 있다.
• 프로토타입과 싱글톤이 아닌 스코프 빈은 DL 방식을 이용하거나, 스코프 프록시 빈을 D 받는 방법을 사용해야 한다.
• 스프링 3.1은 애노테이션과 자바 코드를 이용한 빈 메타정보 작성 기능을 발전시켜서 자바
코드만으로도 스프링 애플리케이션의 모든 빈 설정이 가능하게 해준다.
• 스프링 3.1의 프로파일과 프로퍼티 소스로 이뤄진 런타임 환경 추상화 기능을 이용하면 환 경에 따라 달라지는 빈 구성과 속성 지정 문제를 손쉽게 다룰 수 있다.
 

POJO(Plain Old Java Object)

아래는 위키백과에 있는 POJO의 정의 입니다.
https://ko.wikipedia.org/wiki/Plain_Old_Java_Object

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. 

“우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.”
 — 마틴 파울러 —

POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임워크이다.

POJO, 오래된 방식의 간단한 자바 오브젝트라고 하는데 오래된 방식의 간단한 자바 오브젝트가 무엇일까요?
POJO란 특정 기술에 종속되지 않는 순수한 자바 객체를 의미합니다.
 
예를들어, 특정 기술을 사용하기 위해 특정 프레임워크를 의존하게되면 그것은 POJO라고 할 수 없습니다.
특정 기술에 종속되어있기 때문입니다.
 
예시를 들어봅시다.

public class UserDTO {
	
	private String userName;
	private String userId;
	private String userPassword;
	
	public String getUserName() {
		return userName;
	}
	
	public void setUserName(String userName) {
		this.userName = userName;
	}
	
	public String getUserId() {
		return userId;
	}
	
	public void setUserId(String userId) {
		this.userId = userId;
	}
	
	public String getUserPassword() {
		return userPassword;
	}
	
	public void setUserPassword(String userPassword) {
		this.userPassword = userPassword;
	}

	
}

위 객체는 기본적인 자바 기능인 getter, setter 기능만 가지고 있습니다.
특정 기술에 종속되어 있지 않은 순수 자바 객체이기 때문에 위 객체는 POJO라고 할 수 있습니다.
 
 
학습 테스트와 통합 테스트를 위한 Datasource
순차적으로 진행하는 통합 테스트나 단순한 학습 테스트라면 이 책에서 지금까지 사용해왔던, 스프링이 제공하는 단순한 Datasource를 사용할 수 있다. 다만, 이런 Datasource는 운영환경에서는 절대 사용해서는 안 되므로 주의해야 한다. 개발 중 사용 하던 테스트용 DataSource를 그대로 운영서버에 적용해서 애를 먹는 경우가 종종있으니 주의해야 한다. 이런 실수를 피하려면 하나의 설정파일을 개발, 테스트, 운영환경에 서 매번 수정해서 사용하지 말고 개발용이나 테스트용 스프링 설정파일을 따로 만들어 적용하는 게 좋다.

• SimpleDriverDataSource
스프링이 제공하는 가장 단순한 Datasource 구현 클래스다. getconection()을 호 출할 때마다 매번 DB 커넥션을 새로 만들고 따로 풀을 관리하지 않는다. 따라서 실전에서는 절대 사용하면 안 된다. 단순한 테스트용으로만 사용해야 한다.

- SingleConnectionDataSource
하나의 물리적인 DB 커넥션만 만들어두고 이를 계속 사용하는 DataSource다. 순차 적으로 진행되는 통합 테스트에서는 사용 가능하지만 동시에 두 개 이상의 스레드가 동작하는 경우에는 하나의 커넥션을 공유하게 되므로 위험하다. 매번 DB 커넥션을 생성하지 않기 때문에 SimpLeDriverDataSource에 비해 빠르게 동작한다.

오픈소스 또는 상용 DB 커넥션 풀
오픈소스로 개발된 DB 커넥션 풀도 많이 사용된다. 서버의 DB 풀로 등록해서 사용할 수도 있지만 일반적으로는 애플리케이션 레벨에서 애플리케이션 전용 DB 풀을 만들어 사용한다. 대표적으로 다음 두 가지 오픈소스 DB 커넥션 풀이 스프링과 함께 많이 사용 된다. 두 가지 모두 스프링의 빈으로 바로 등록해서 사용할 수 있는 수정자 메소드를 가 진 클래스가 제공돼서 사용하기 편리하다. 다양한 방식의 풀 클래스와 설정 옵션이 있으므로 자세한 내용은 레퍼런스 문서나 웹사이트의 정보를 참고하자.

• 아파치 Commons DBCP
 

가장 유명한 오픈소스 DB 커넥션 풀 라이브러리다. 아파치의 Commons 프로젝트 http:/commons. apache.org/dbcp/)에서 찾을 수 있다.
 
2.2.2 SimpleJdbcTemplate
simoleldbc Template은 스프링 JDBC를 사용한다면 가장 많이 이용하게 될 JDBC용 템 플릿이다. Vol. 1에서 잠깐 살펴봤던 Jdbc TempLate을 더욱 편리하게 사용할 수 있도록 기능을 향상시킨 것이라고 생각하면 된다.
Simplelabcfemplate이 제공하는 기능은 실행, 조회, 배치의 세 가지 작업으로 구분할 수 있다. 실행 작업은 INSERTL UPDATE와 같이 DB의 데이터에 변경이 일어나는 쿼 리를 수행하는 것이고, 조회는 SELECT를 이용해 결과를 가져오는 작업이다. 배치는 하 나 이상의 실행 작업을 한 번에 수행해줘야 할 때 사용한다.
먼저 simpleJdbcTemplate을 생성하는 방법과 sQL을 전달하는 방법을 알아보자.

simpleJdbc Template 생성
simplejdbc Template은 Datasource를 파라미터로 해서 다음과 같이 생성할 수 있다.
•SimpleJdbcTemplate template = new Simple]dbcTemplate (dataSource);
Datasource는 보통 빈으로 등록해두므로 Simple Jdbc Templateol 필요한 DAO
에서 Datasource 빈을 DI 받아 SimpleJdbc Template을 생성해두고 사용하면 된다.
simpleldbc Temolate은 멀티스레드 환경에서도 안전하게 공유해서 쓸 수 있기 때문에 DAO의 인스턴스 변수에 저장해두고 사용할 수 있다. 또는 SimoLe Jdbc Template 자체 를 싱글톤 빈으로 등록하고 모든 DAO가 공유해서 사용하도록 만들어도 된다.
스프링 개발자는 관례적으로 DAO의 코드에서 Datasource를 제공받아서
simpleJdbc Template을 생성하는 방식을 선호한다. Datasource 오브젝트가 있으면 simpleJdbc Template 외에도 다른 스프링 JDBC 오브젝트를 만들어 사용할 수도 있기 때문이다.
리스트 2-2는 일반적으로 사용되는 DAO의 기본 구조다. DataSource에 대한 수정 자 메소드에서 직접 Simple Jdbc Template 오브젝트를 생성해준다. Datasource 자체는 이후에 사용할 필요가 없다면 저장해둘 필요는 없다.

리스트 2-2 DAO 클래스의 일반적인 구조
public class MemberDao {
SimpleJdbcTemplate simple]dbcTemplate;
IT o
public void setDataSource (DataSource dataSource) {
this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
}

애노테이션 방식을 이용한다면 Datasource 수정자 메소드에 @Autowired나
@Resource를 붙여도 되고 리스트 2-3과 같이 메소드에 의한 주입 방법이나 생성자 주입을 이용할 수 있다
 
 
RequestMapping 정보가 클래스 상속이나 인터페이스 구현을 통해 상속된다는 사실 을 잘 활용하면 매우 편리한 매핑 전략을 만들어낼 수도 있다. 타입만 바꿀 수 있는 제 네릭스 인터페이스를 사용하거나 추상 클래스에 매핑정보를 미리 넣어두고 이를 상속 하는 개별 컨트롤러 클래스에서 필요한 부가 매핑정보만 넣도록 만들면, 컨트롤러마다 들어가는 공통적인 매핑 작업을 대폭 줄일 수 있다.
반면에 체계적인 정책과 잘 준비된 가이드라인을 가지고 개발하지 않고 개발자마다
제멋대로 @RequestMapping을 남발해서 적용하면 이해하고 관리하기 매우 힘든 코드를 낳게 될 테니 주의해야 한다. 자유도가 높은 애노테이션 방식의 OMVC를 사용한다면 반드시 강력한 표준 정책을 만들어둘 것을 권장한다.

제네릭스와 매핑정보 상속을 이용한 컨트롤러 작성
@RequestMapping을 상속과 구현에서 잘 활용하면 반복적인 설정을 피하고 간결한 코드 를 얻어낼 수 있다. 특히 자바 5 이상의 타입 파라미터를 이용한 제네릭스를 활용해서 상위 타입에는 타입 파라미터와 메소드 레벨의 공통 매핑정보를 지정해놓고, 이를 상속 받는 개별 컨트롤러에는 구체적인 타입과 클래스 레벨의 기준 매핑정보를 지정해주는 기법을 사용할 수 있다.
기본 정보의 입출력을 다루는 컨트롤러에는 도메인 오브젝트별로 CRUD와 검색 기 능을 가진 메소드가 중복돼서 등장한다. 값의 검증이나 뷰 로직 등은 컨트롤러에서 독 립적으로 만들 수 있으므로, 이런 컨트롤러들은 서비스 계층의 CRUD 메소드로 요청을 위임해주는 것이 전부인 경우도 적지 않다. 각 컨트롤러마다 모델의 타입만 달라질 뿐
기본적인 구성과 코드는 동일한 코드가 중복돼서 만들어지기 마련이다. CRUD8 컨트 롤러라면 모델은 보통 도메인 오브젝트를 사용할 것이다.
타입만 달라지는 중복된 코드라면 제네릭스의 타입 파라미터를 가진 슈퍼클래스로 공통적인 코드를 뽑아내는 것이 좋다. 동시에 매핑정보의 일부, 즉 URL의 일부가 중부 되는 것도 슈퍼클래스에 미리 정의해둘 수 있다.
 
 
 
SQL 실행 메소드
INSERT, UPDATE, DELETE와 같은 SQL을 실행할 때는 SimpleJdbc Template의 update()
메소드를 사용한다. update() 메소드를 호출할 때는 SQL과 함께 바인딩할 파라미터를 다음 세 가지 방식 중의 하나로 전달하면 된다.
• varargs
위치 치환자가를 사용하는 경우 바인딩할 파라미터를 순서대로 전달하면 된다.
simpleJdbcTemplate.update(
"INSERT INTO MEMBER(ID, NAME, POINT, argS) VALUES(?,2,2)", 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를 이름 치환자에 직접 바인딩하려면 SalParameter Source
타입인 BeanPropertySqlParaneterSource를 사용해 update()를 호출할 수 있다.
 
 
simpleJdbcTemplate.update(
"INSERT INTO MEMBER(ID, NAME, POINT, args) VALUES(:id, :name, point)" new BeanPropertySq1ParameterSource (member));

이름 치환자를 위한 파라미터를 메소드 호출 시에 직접 지정하려면 다음과 같이

MapSqlParameterSource의 adaValue() 메소드를 이용할 수 있다.

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 실행으로 영향을 받은 레코드의 개수를 리턴해준다.