김성렬 개발 블로그

우연히  S/W 프레임워크 수업을 수강하고 있다.

프레임워크라는 단어에 반가워서 수강신청했는데

수업내용이 전자정부 프레임워크였다.  ;;;

학점관리상 굉장한 이득을 볼 수 있었지만 수업내용은 군대에서 공부한 토비 스프링 

내용보다 원리 중심적이지는 않고 실무 지향적인? 내용으로 수업이 흘러갔다. 

솔직히 스프링 프레임워크를 JDBC도 잘 모르는 학부생들을 상대로 

가르치려고 노력 하시는 강사님이 대단하게 느껴진다. 

학생들이 안타까워... 저걸 어케 이해함...

수업 초기에 작년에 강의평가에서 혹평을 받았다고 하셨는데  

경영학과 학부생 상대로  스프링 프레임워크 강좌가 열린다는 것 자체가 

이상한일....

컴공애들 상대로 강의를 해도 스프링의 철학같은것을 이해하기 힘들텐데 

프로그래밍에 관심도가 덜한 경영 학부생들이면 말 다했다.. 

서문이 길었다. 

수업 듣다보니 단골 질문이 나왔다.

Class 와 Interface의 차이를 서술하시오 

간단한 내용이지만 정리를 해볼까 한다. 

1. Interface는 선언부 Class는 구현부이다. 

자바는 철저한 OOP 를 기반으로 하고있다. 

객체지향 프로그래밍의 핵심은 추상화(Abstraction) 이다. 

추상화를 함으로서 중복된 소스코드를 없앨수도 있고 

느슨한 결합도 (loose Coupling)를 유지 할수도 있다. 

추상화하는방식(상속과 인터페이스의 차이도 나중에 작성해야 겠다. )

인터페이스는 객체지향적인 소스코드를 생산할수 있도록 도와준다.

 .

  Don't re-invent the wheel(바퀴를 다시 만들지 말라)

객체지향 프로그래밍의 궁극적 목표인 위 모토를 만족하기 위해서 객체지향 5대 원칙(SOLID)을 세우고

캡슐화 추상화와 같은 이론들을 정립했다

Interface는 이러한 정립된 이론들을 구현하는 최전선에 서있는 개체이다.

Interface는 프로그래밍에 입문 하는 사람들에게는 그 편리함을 체감하기 힘든  기능이다.

Interface는 식당의 메뉴판 같은 역할을 한다. 

“메뉴판을 보는 손님들이 원하는 정보는 어떤 음식을 먹을까?”이지 그 이상의 복잡한 정보를 원하지 않는다.

스테이크요리를 만들기 위해서는 불에 얼마나 굽고 어떤 소스를 만들고 숙성을 얼마나 하는지 같은 복잡한 내용이 적힌 두꺼운 요리책이 필요하다.

그러나 그러한 두꺼운 요리책을 손님 메뉴판으로 제공하지 않는다.

Class 가  두껍고 복잡한 내용이 담긴 요리책이라면 Interface는 1~2장으로 이루어진 가벼운 메뉴판이다.

우리는 손님에게(사용자) 가벼운 메뉴판을 제공하지 두껍고 무거운 요리책을 주지 않는다. 

손님은 소고기 스테이크가 불위에서 어떤방식으로 구워지는지 몇분 구워지는지 같은 세세한 정보를 알고 싶지 않다.

그저 맛있는 스테이크를 먹고싶어서 간단히 적힌 메뉴판을 보고

"소고기 스테이크 1인분 주세요~" 라고 주문할 뿐이다.

소프트웨어에서도 마찬가지다.

어떠한 라이브러리,API를 사용하는 사용자는 그 API가 얼마나 멋진 추상화가 적용되었고 다양한 기법들이 사용됬는지 알고싶지 않다.

그저 그 API또는 라이브러리를 통해 내가 구현하고자하는 기능에 편하게 쓰고싶을 뿐이다.

그렇기 때문에 우리는 메뉴판을 제공하듯이 인터페이스를 제공한다.

스테이크의 조리법이 수정되었다고 

메뉴판에서 무엇인가 수정되지 않듯이

구현체가 바뀌었다고

인터페이스가 수정되지 않는다.

JDK로 알아보는 Interface 사용 예제

List<String> list=new ArrayList<String>();

list.add("HI");

 list.add("assignment");

 list.add("yea~!");

다음 예제를 보자 위 예제는 ArrayList에 3개의 문자열을 넣는 소스코드이다

여기서 봐야할 점은 객체 list 의 선언을 왜 ArrayList<String> 로 하지 않고

List<String> 으로 선언했는가? 이다.

ArrayList<String> list=new ArrayList<String>();

list.add("HI");

 list.add("assignment");

 list.add("yea~!");

이렇게 ArrayList로 선언 해도 돌아가는데 아무런 문제가 없지만

좋은 프로그래머라면 전자방식을 선호하며 

반드시 그래야만 한다.

자바언어를 창시한 제임스 고슬링은 리스트라는 자료구조를 설계할 때 리스트의 구현 방식이

리스트를 선언하는데 영향을 주고 싶지 않았을 것이다.(진짜설계는 다른 사람이 했겠지만 편의상..)

그래서 List<>를 interface로 선언했다.

List<>를 Interface 선언 함으로서 우리는 소스코드 변경이 가능하다

이것은 Strategy Pattern (전략패턴) 이라 부르는 디자인 패턴이다. 

하나의 기능을 구현하는 여러가지 전략(알고리즘)이 있으면 이것을 

인터페이스로 선언부를 작성하고 여러가지 구현부를 클래스로 작성하여 

교체하기 편리하게 하는 것이다.

인터페이스를 사용함으로서 이러한 설계상 이점을 가질수 있다.

사실 인터페이스는 아무런 의미가 없는 껍떼기에 불과하다 느낄 때가 있다.

실제로도 구현상 인터페이스는 그저 매개체 정도의 역할만 하고 실질적인 내용에는 아무런 기여를 하지 않는다.

인터페이스는 설계상 이득을 얻기위해 선언하는것이다.

인터페이스는  기능들을 묶는 논리적인 하나의 단위를 띄고 있다.

인터페이스는 비용(Cost)이다. 그러나 모든 코드 또한 비용이다.

비용을 들인 만큼 얻는 가치가 있다면 투자하면 되고 없다면 투자해서는안될것이다

프로그래밍에서 간접화와 추상화에 관련된 코드를 비용으로 따진다면   간접비에 해당한다.

추상화를 하면 할수록 SW은 오히려 복잡도가 더 올라갈수 있고

소프트웨어 공학에서도 과도한 추상화와 디자인패턴 남발은 피하도록  노력해야 한다고 주의하고있다.

그러나 복잡도가 올라갈수 있는 위험이 있다고 인터페이스를 사용하지  않는다면

구더기 무서워서 장 못담군다는 말이 가장 어울리는 표현일 것이다. 

“그렇다고 모든 클래스에는 인터페이스를 만든다” 라는 과격하고 경직된 방식의 프로그래밍은

인터페이스가 좋다 하더라도 너무 극단적인 방식 이다.

인터페이스의 사용여부는 결국 개발자 또는 아키텍트 당사자의 판단에 맡길 수 밖에 없다.

인터페이스를 사용해야만 하는 상황을 그때그때 적절히 판단하여

사용하는 것이 결국 정답일 것이다. 

http://blog.fupfin.com/?p=81

매우 좋은 토론거리다.

결론

1. 인터페이스는 비용이다 그러나 그 비용을 들인 만큼 얻는 가치가 있다면 투자하면 된다  과도한 추상화나 간접화는 피해야 하지만 

상황에 따라 적절한 판단을 통해 인터페이스를 작성해야한다.

2. 소프트웨어가 커져갈수록 인터페이스 는 추상화로서 이득을 낼것이다.

mybatis 는 정말로 쉽다.

러닝커브가 매우 짧으며 

그 투자된 학습시간에 비해  높은 생산성을 보인다   

단순 문자열로 SQL 이라는 중요한 소스코드를 관리한다는 것은 큰 문제가 있다.

Mybatis는 SQL문을 자바소스코드에서 분리함과 동시에 

SQL 문을 재사용 가능하게 하며

SQL 문을 파일로 분리하여 유지보수성을 높히며

도메인 과 릴레이션의 매칭을  통해 oop와 sql간 사상차이를 극복할수있게 도와준다.

위 파일중 mapper.xml 파일 한개를 가져왔다 

이 소스코드를 훑어보면서 mybatis사용법을 익혀보자

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

<!DOCTYPE mapper

PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"

"http://mybatis.org/dtd/mybatis-3-mapper.dtd">

mybatis mapper 파일임을 정의 하고 있다.

<!DOCTYPE mapper

.. 이하생략 ..   .dtd>

이라고 문서 타입을 정의하므로서 

해당 문서 타입에 벗어나는 문법을 잡아서 빨간줄을 띄워줌으로서

우리는 mybatis 문법에 대한 에러를 잡을수있다.

<mapper namespace="com.kimsoungryoul.persistence.myblog.studyBoardMapper">

해당 매퍼파일의 고유한 이름을 정의하고있다.

우리는 namespace에 정의된 값으로 통해 자바클래스에서 쿼리문을 가져다 쓸수있다.

마치 int a=5;

prinf("%d",a); 라는 코드에서 a 라는 고유한 변수명으로 5라는 값을 가져다 쓰듯이

 com.kimsoungryoul.persistence.myblog.studyBoardMapper 라는 고유값을 통해 

해당 mapper 아래 여러 쿼리문들을 가져다 쓰는것이다.

<insert id="insert">    

INSERT INTO studyboard

(writer, title,subtitle,

contents)

VALUES

(#{writer}, #{title}, #{subTitle}, #{contents})

</insert>

쿼리문 작성.. 우리는 해당 쿼리문을 

com.kimsoungryoul.persistence.myblog.studyBoardMapper.insert라는 id값을 추가하여 가져다쓸수 있다. 

<select id="get" resultMap="BoardResultMap">

SELECT * FROM studyboard

where

no=#{no}

</select>

<select id="list" resultMap="BoardResultMap">

SELECT * FROM studyboard

where no > 0

order by regdate desc

limit #{pageStart}, #{perPageNum}

</select>

<select id="searchlist" parameterType="hashmap" resultMap="BoardResultMap">

select B.* from studyboard B

inner join tbl_hashtag H

on

H.tag=#{keyword} AND B.no=H.b_no

order by regdate desc 

limit

#{pageStart}, #{perPageNum}

</select>

<update id="update">

UPDATE studyboard

SET

modifieddate = #{modifiedDate},

writer = #{writer},

title = #{title},

contents = #{contents}

WHERE no =

#{no}

</update>

<delete id="delete">

DELETE FROM studyboard

WHERE no=#{no}

</delete>

<delete id="deleteAll">

DELETE FROM studyboard

</delete>

<select id="getB_no" resultType="Integer">

select no from studyboard

where

no=LAST_INSERT_ID()

</select>

<update id="likePlus">

UPDATE

studyboard

SET

likecnt=likecnt + 1

WHERE

b_no=#{b_no}

</update>

<update id="viewplus">

UPDATE

studyboard

SET

viewcnt=viewcnt + 1

WHERE

b_no=#{b_no}

</update>

<resultMap id="BoardResultMap" type="StudyBoard">

<id property="no" column="no" />

<result property="regDate" column="regdate" />

<result property="modifiDate" column="modifidate" />

<result property="title" column="title" />

<result property="subTitle" column="subtitle" />

<result property="writer" column="writer" />

<result property="contents" column="contents" />

<result property="likeCnt" column="likecnt" />

<result property="replyCnt" column="replycnt" />

<result property="viewCnt" column="viewcnt" />

<collection property="hashTagList" select="selectHashTag"

column="{no=no}" javaType="java.util.ArrayList" />

<collection property="attachmentList"

select="com.kimsoungryoul.persistence.study.boardAttachmentMapper.list"

column="{sb_no=no}" javaType="java.util.ArrayList" />

</resultMap>

<insert id="insertHashTag" parameterType="hashmap">

INSERT INTO tbl_hashtag (b_no, tag)

VALUES

<foreach collection="hashTagList" item="tag" open="" close=""

separator=",">

(LAST_INSERT_ID(), #{tag})

</foreach>

</insert>

<select id="selectHashTag" resultType="String">

select tag from

tbl_hashtag

where b_no=#{no}

</select>

<select id="hashTagListInBoardMenu" resultType="HashTagDTO">

select tag, count(tag) as tagcnt from tbl_hashtag group by tag order by count(tag) desc limit 0,4

</select>

<delete id="deleteHashTag">

delete from tbl_hashtag

where b_no=#{no}

</delete>

<delete id="deleteAllHashTag">

delete from tbl_hashtag

</delete>

<sql id="whereSql">

<where>

<if test="title != null and title !='' ">

AND title = #{title}

</if>

<if test="subTitle !=null and subTitle!=''">

AND subtitle=#{subTitle}

</if>

<if test="writer != null and writer !='' ">

AND writer = #{writer}

</if>

<if test="contents!=null and contents != '' ">

AND contents=#{contents}

</if>

<if test="no !=null and no !=0 ">

AND no= #{no}

</if>

</where>

</sql>

</mapper>

공부내용 정리 spring in Action (4.0 edit)

What is the REST?

REST  Contructed with Resource, Method , Message

For example someone request " create User who called terry ",

User is Resource

Create is Method

Terry is Message

Recently Architects implement Restful API with Http & Json

Almost of Open API Implement or are  designed with REST Architecture

 /*

내용 참조

대용량 아키텍쳐와 성능 튜닝 -조대협개발자님 -

part4  Rest의 이해와 설계  내용 참조

Characteristic of REST

• Uniform Interface
• Stateless (무상태성 상태 정보를 저장하지 않음)
• Cacheable

REST 는 HTTP 표준을 따른다면 어떠한 기술이든지 사용할수 있는 인터페이스 스타일이다

예를 들어 HTTP+JSON 으로REST API 를 정의 했다면 안드로이드 플랫폼이건 IOS 플랫폼이건 C든 Python이든 특정 언어나 기술에 종속받지 않고 HTTP+JSON 을 모든 플랫폼에 사용할수 있는 Loosely Coupling 형태 구조이다

*/ 

% 흔히 근래에 REST를  이야기하면 HTTP+JSON을 쉽게 떠올리는데 JSON은 하난의 옵션일뿐 메시지 포맷을 꼭 JSON으로 적용해야할 필요는 없다.

편리성 때문에 JSON을 쓰는 것뿐이다. %

스프링이 REST 를 지원하는 방법

스프링은 리소스의 자바표현을 클라이언트에 전달될 표현으로 변환하는 두가지 방법을 제공한다

• 콘텐츠 협상(view 선택)
• 메시지 변환(컨트롤러가 반환한 객체를 클라이언트에 제공되는 표현으로 변경한다)

DispatcherServlet 은 뷰이름을 viewResolver에게 전달하고 요청의 결과를 렌더링 해야 하는 뷰를 결정하기 위해 도움을 요청한다.

사람과 대면하는 웹애플리케이션에서 선택된 뷰는 거의 대부분 HTML로 렌더링 된다

스프링은 ContentNegotiatingViewResolver 는 클라이언트가 고려하려는 콘텐츠 타입을 선택하는 특별한 ViewResolver 이다.

ContentNegotiatingViewResolver는 먼저 URL 의 파일 확장자를 살펴본 후에 Accept 헤더를 살펴보고 요펑하는 모든 미디어 타입을 사용한다. 만일 uRL 의 끝에 파일 확장자가 있으면 ContentNegotiatingViewResolver는 확장자에 기반하는 원하는 타입을 만들어 낸다.

.json 이면 application/json

.xml이면 application/xml

.html이면 text/html

이런방식으로 리소스를 요청함을 나타낸다.

파일 확장자가 미디어타입을 위한 사용 가능한 단서를 제공하지 못하면 요청된 Accept헤더가 고려된다.

ContentNegotiatingViewResolver는 직접 생성할 필요가 없다

ContentNegotiatingViewManager는 스프링 3.2 에 도입된 상대적으로 새로운 내용이며

ContentNegotiatingViewManager를 통해 ContentNegotiatingViewResolver을 설정할수 있다

자바설정에서 ContentNegotiatingViewResolver를 얻기 가장 쉬운방법은

 WebMvcConfiguererAdapter를 확장하고

configuerContentNegotiation() 메소드를 오버라이드 하는 것이다.

하이버네이트는 자바 기반의 ORM (Object Relationship Mapper)이다. 쉽게 이야기 해서, 자바 객체를 RDBMS의 하나의 ROW로 맵핑해준다.

이 ORM 개념은 상당히 오래전부터 나왔는데, 처음의 시초는 EJB Entity Beans라고 할 수 있는데, 이 EJB는 여러가지 강력한 기능을 가졌음에도 불구하고, 사용법이 너무 어려워서, 근래에는 거의 사용되지 않는다. 이렇게 사용법이 어려워서 이를 간편화 하여 사용법은 편하게 하면서도, 더 많은 기능을 지원하게 한것이 ORM인데, 그중에서 대표적인 것이 Hibernate이다.

Hibernate가 개발된후에, Java 스펙에도 ORM의 표준 스펙을 정의했는데 이것이 JPA (Java Persistence API)이다. JPA는 하나의 스펙으로 JPA에 대한 구현체가 필요하다. 실제 구현체는 TopLink, OpenJPA등 여러가지가 있는데, 이렇게 ORM API를 JPA를 통해서 추상화 시켜놓음으로써, 다른 ORM과 쉽게 교체가 가능하게 만든 개념이지만, 실제로 ORM은 거의 Hibernate만 사용되기 때문에, JPA를 사용하는 것은 큰 의미가 없다.

JPA는 기본적으로 JBoss나 Weblogic과 같은 JEE 컨테이너를 가정으로 개발되어서 JTS/JTA, EJB3등과 사용하기에는 좋지만, 컨테이너 없이 Tomcat과 같은 Servlet 컨테이너만 사용할 경우, 큰 이득을 보기 어렵다.

http://bcho.tistory.com/906 

조대협 개발자님블로그  하이버네이트 정의

ORM 이란  Object Relational Mapper  의 준말로써 

OOP(Object Oriented Programming ) 과  RDB(Relational Database) 와의 

프로그래밍 사상 차이로 인해 생기는 문제를 해결하기 위해 개발되었다.

SQL is interpreter language   it is lower than procedural programming 

SQL 은 대화형 언어이다. 이것은 절차지향형 프로그래밍 이란 메타 보다 

저급한 메타이다.

(여기서 저급하다는 질떨어진다가 아니라

low level 을 의미하며 기계어 에 가까움을 말한다. 

어셈블리어는 C언어에 비해 저급언어이다. 라는 문장에서 사용하는 저급을 뜻한다. )

객체지향형 프로그래밍은 인간의 언어(자연어)에 좀더 가까운 메타이다 

여기서 문제가 생긴다. 

데이터 베이스라는 미들웨어는 소프트웨어에서 빼놓을수 없는 강력하고 중요하다.

데이터를 관리하기 위해서는 RDBMS 를 사용해야하고 그러기위해서는 

SQL사용은 불가피하다.

그러나 객체지향형 언어와 인터프리터 언어 의 메타 차이로 인해 

객체지향적프로그래밍이 필요한 애플리케이션은 대화형 언어(인터프리터)인 

SQL 을 사용하면 객체지향적인 모습을 잃거나 

객체지향적 모습을 유지하기위해 단순한 ER Model 에도 

소스코드가 길어졌다.

데이터에 대한 주체는 애플리케이션이여야 하지만 RDBS 에게 주도권을 빼앗기는 현상이 일어난다.

이러한 문제를 해결하기위해 ORM이 개발됬다.

Persistence Layer 에서 사용되는 기술은 

대표적으로 

 Mybatis(sqlMapper) , Hybernate(ORM) 두가지가 있다.

-우리나라에서만 mybatis 에 대한 점유율이 유독 높다.-

한국에서는 거의 MyBatis가 대세를 이루지만 해외의 경우 높은 생산성등을 이유로 Hibernate가 거의 대세를 이룬다.

그러나, 한국에서 안사용하는 이유 처럼, Hibernate는 자체적으로 쿼리를 생성하고, OR Mapper로써, 객체들을 DB에서 로딩할때, 레퍼런스된 객체등을 로딩하는등, 제대로 특성을 이해하고 사용하지 않으면 장애를 일으키는 경우가 많지 않기 때문에, 해외에 비해서 한국에서는 많이 사용되지 않는다. (SI에서 기피한다)

http://bcho.tistory.com/906

조대협 개발자님 블로그 하이버네이트 쉽게 입문하기

Hybernate 는 자바 기반 ORM 이다 

Hybernate가 개발 된 이후 자바 측에서도 ORM의 표준 스펙을 정의 했는데 

이것이 유명하고 강력한 JPA (Java Persistence API) 이다.

JPA 는 다른 ORM 으로 교체 가능하도록 잘 추상화 되어 있지만 

현업에서는  자바진영은 거의 Hybernate +JPA  조합으로만 쓰인다 .

복잡한 통계 쿼리가 필요한 경우 JPA는 부적합 하다.

이러한 경우에는 Mybatis 나 스프링 JDBCTemplate 같은 SQL 매퍼 형태 프레임 워크를  혼용하는 것도 좋은 방법이다.

-자바 ORM 표준 JPA 프로그래밍 ,김영한, p60-

아이바티스(ibaits)는 아파치 재단에서 진행되던 오픈소스 프로젝트로 

프로젝트 팀원들이 구글 코드로 이전하면서  ibatis 는 개발이 중단 되었다.

(사실상 개발 중단이 아닌 프로젝트 소속기관을 이전하면서 이름만 변경된 것이다 )

구글 코드로 이전하면서 ibatis는 새롭게 이름을 다시 지었는데 

이것이 Mybatis 다.

-what different?-

마이바티스는 객체지향 언어인 자바의 관계형 데이터 베이스 프로그래밍을 좀더 쉽게 할수 있게 도와주는 개발 프레임워크이다. 자바에선 데이터베이스 프로그래밍을 하기 위해 JDBC(자바에서 제공하는 데이터베이스 프로그래밍 API)를 제공하고, JDBC는 관계형 데이터 베이스를 사용하기 위해 다양한 API를 제공한다.

( ORM (Object Relational Mapping) 에서 대표적으로 mybatis , hybernate 가 있다.  ) 

-------------------------------------------------

ORM은 무엇이며 우리는 왜 ORM을 사용해야만 하는가?

http://kimsoungryoul.tistory.com/7

----------------------------------------

다양한 관계형 데이터베이스를 지원하기 위해 JDBC는 세부적인 작업이 가능하게 작업별로 각각의 메소드를 호출하게된다. 이러한 사항들은 다수의 메소드를 호출하고 관련된 객체를 해제해야하는 단점이 있다.

Mybatis는 JDBC보다 좀더 편하게 사용하기 위해 개발 되었다.

Mybatis 의 대표적 특징은 SQL문을 분리하는 

SQL Maper 프레임 워크라는 점이다.

mybatis 관련 참고 이미지 (이해 안가면 그냥 넘겨도 무방하다)

SQL을 분리한다는 것은 무엇인가?

JDBC 로 데이터베이스로 접속하는 프로그래밍을 한다면 

.............

pstmt = conn.prepareStatement("select * from board");     

.............

이런 식으로 쿼리문이 자바 소스코드안에 문자열로 취급되어 들어간다

여기서 JDBC 프로그래밍의 문제점이 보인다

1. SQL과 자바는 서로 다른 언어이다. 

이 두가지가 한 파일(또는 클래스) 내에 섞여 있다는 것은 

굉장히 껄끄러운 문제점이다. 

객체지향 프로그래밍은 각 메서드 클래스별 하나의 책임(SRP)을 맡길 것을 권장하는데

역활이 두가지인것도 아니고 무려 두가지 언어가 뒤섞였다는 점은 

개발자들의 기분을 매우 찜찜하게 만든다.

 2. 객체지향적? SQL 작성의 어려움 

대게 처음 배우는 사람들은 무의식중에 클래스 - 테이블 을 1대1 매칭 시키면서 

공부를 한다.  그러나  1:n 문제 m:n 같은 문제에 부딪치면서 

기존에 1대1매칭 시키던 자신의 사상에 큰 고민을 하기 시작한다.

여러 테이블을 join 하여  어느 정도 해결할수 있더라도 

n:m 과같은 문제는 깔끔한 sql 로 해결 할수 없다.

mybatis는 sql 문을 객체지향적? 으로 쓸수 있게 여러 기능 들을 제공한다. 

쿼리문을 xml 로 분리한 mybatis 프로그래밍 중 일부이다. 

mybatis는 xml 로 쿼리문을 따로 관리하고  자바의 DAO 클래스(Persistence계층)들은 필요한 쿼리문을 이곳에서 불러서 사용한다.

mybatis의 핵심은 이것이다.

.

이것은 xml 으로 분리한 sql 문을 불러 쓰는 DAO 클래스의 일부이다.