iBatis에서의 습관을 버리고 myBatis로 옮겨올 시기가 된듯합니다.
Spring3.2에서도 iBatis는 deprecated 되어 더이상 myBatis로 옮기는데 주저할수는 없는 현실이 되어버렸습니다.
오늘은 예전 iBatis에서 iterate 문으로 사용했던 부분을 forEach로 변경하는 테스트를 시험삼아 해보았습니다.
myBatis를 쓰면서 느끼는것은 이제 xml문법스타일은 버려도 되겠구나 하는 것입니다.
foreach
동적 SQL 에서 공통적으로 필요한 것은 collection 에 대해 반복처리를 하는 것이다. 종종 IN 조건을 사용하게 된다. 예를 들면,
<select id="selectPostIn" resultType="domain.blog.Post"> SELECT * FROM POST P WHERE ID in <foreach item="item" index="index" collection="list" open="(" separator="," close=")"> #{item} </foreach> </select>
foreach 요소는 매우 강력하고 collection 을 명시하는 것을 허용한다. 요소 내부에서 사용할 수 있는 item, index 두가지 변수를 선언한다. 이 요소는 또한 열고 닫는 문자열로 명시할 수 있고 반복간에 둘 수 있는 구분자도 추가할 수 있다.
참고 파라미터 객체로 MyBatis 에 List 인스턴스나 배열을 전달 할 수 있다. 그렇게 하면 MyBatis 는 Map 으로 자동으로 감싸고 이름을 키로 사용한다. List 인스턴스는 “list” 를 키로 사용하고, 배열 인스턴스는 “array” 를 키로 사용한다.
위의 내용은 myBatis 한국어 사이트 번역판에 설명되어진 것입니다만 사실 제대로된 설명이라고 하기엔, 특히나 개발감각 없는 저 같은 개발자에겐 한방에 와닿지 않습니다.
그저 따라하기 예제 샘플이 최고입니다.
User.java
public class User {
private int userIdx;
private String userName;
private Integer [] userIdxArray;
private List<Company> compList;
public ... 이하는 getter, setter 메소드이므로 생략.
}
1. 배열을 파라메터로 전달하여 foreach문을 사용하는 예
UserMapper.xml
<select id="getUserListByUserIdxArray" resultMap="User-Result" parameterType="User">
SELECT
USER_IDX as "userIdx"
, USER_NAME as "userName"
FROM USER
<trim prefix="WHERE" prefixOverrides="AND|OR">
<if test="userIdxArray != null">
AND USER_IDX IN (
<foreach collection="userIdxArray" item="a" separator=",">#{a}</foreach>
)
</if>
</trim>
</select>
WHERE 문이 오는 곳에 위치한 trim 도 iBatis에는 없던 myBatis에서 새로이 추가된 구문입니다. 보통 꼼수(?)로
위와 같이 사용하던 부분인데, 이러한 꼼수를 쓰지말라고 제공하는 구문이라고 생각합니다.
보통 if 문을 사용하는 곳 앞부분에 추가하는데, 이전 iBatis에서는 <dynamic...> 이란 구문이 아마 이에 해당했던 걸로 기억합니다.
- collection : 말 그대로 collection 객체들이 오는 곳입니다.
- item : Collection 객체들의 instance? 라고 할수 있습니다. jstl에서의 forEach를 예로 들면 "var"에 해당하는 놈이라고 할수 있겠네요. 처음엔 글자가 jstl의 items와 비슷해서 같은걸로 이해했었습니다.
- separator : 구분자.
배열이기 때문에 이 alias를 그대로 넣어주면 쿼리에 적용됩니다.
2. ArrayList를 파라메터로 전달하여 foreach문을 사용하는 예.
<if test="compList != null">
AND COMP_NAME IN (
<foreach collection="compList" item="a" separator=",">#{a.compName}</foreach>
)
</if>
...
배열 사용법과 별 차이는 없습니다.
이전 iBatis를 사용할때는 array 객체가 필요할때는 이상하게 꼭 hashmap 객체에 넣어서 보냈던 기억이 있습니다. POJO 에 넣어서 보내면 뭔가 모르게 오류가 나서 잘 안되던 기억이 있었는데(어쩌면 사용법을 틀려서 그런걸수도 있겠지만), myBatis 에 와서는 그런부분이 없습니다. 좀더 명확해졌다고 해야할까요?
오늘은 myBatis의 foreach문을 통한 반복문 사용법을 테스트 해보았습니다.
끝.
출처 : http://gubok.tistory.com/386
Tomcat의 컨텍스트를 reloadable=“false”인 상태에서, Tomcat Manager를 설치하지 않은 상태에서 수동 Reload 할 수 있는 Valve를 만들어 보았다. Reload Tomcat Context manually(without manager or reloadable=“true” option).
설정
- Tomcat Reload Valve 소스와 Jar 파일에서 tomcatreloadvalve.jar 파일을 $CATALINA_HOME/lib 로 복사한다.
- server.xml 혹은 context.xml의 <Context> 항목에 Valve를 추가한다. 항상 <Context> 항목에만 추가해야 한다.
<Context docBase="some" path="/some" reloadable="false" > <Valve className="kr.pe.kwonnam.tomcat.reloader.TomcatReloadValve"/> </Context>
- reloadable=“false”로 둔다. 원래 이 Valve의 목적은 자동 Reloading을 끄고, 항상 수동으로 원하는 경우에만 Reloading하는 것이다.
실행
- 웹브라우저 혹은 wget 등으로 http://localhost:8080/reloadContext 를 호출한다.
- 실제 URL의 도메인네임 부분은 자신의 톰캣 설정을 따른다.
- “Context Reloaded!!” 메시지가 나오면서 Reloading이 완료된다.
소스
package kr.pe.kwonnam.tomcat.reloader; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServletResponse; import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.connector.Request; import org.apache.catalina.connector.Response; import org.apache.catalina.valves.ValveBase; /** * Reload Tomcat Context by requesting URL * * Context의 reloadable="false"인 상태에서도 /reloadContext URL을 호출하면 해당 컨텍스트가 Reloading 된다. * * @author 손권남 kwon37xi@gmail.com * */ public class TomcatReloadValve extends ValveBase { private static final String RELOAD_CONTEXT_URI = "/reloadContext"; @Override public void invoke(Request request, Response response) throws IOException, ServletException { Container container = getContainer(); String requestUri = request.getRequestURI(); String reloadUri = request.getContextPath() + RELOAD_CONTEXT_URI; if (requestUri.startsWith(reloadUri) && container instanceof Context) { reloadContext(response, container); return; } getNext().invoke(request, response); } private void reloadContext(Response response, Container container) throws IOException { ((Context) container).reload(); HttpServletResponse httpResponse = response.getResponse(); httpResponse.setContentType("text/plain;charset=utf-8"); httpResponse.getWriter().write("Context Reloaded!!"); httpResponse.getWriter().close(); return; } }
http://kwonnam.pe.kr/wiki/java/tomcat/contextreload
프로젝트 수행 계획서라는 것이 있다...사용해본 사람도 있을 것이고 사용 안해본 사람도 있을 것이고...어떤이는 고객이 원하지 않으면 쓰지 않는다고 하고...(나도 사실은 그렇다...고객들이 대부분 삐까뻔쩍한 페이퍼웍을 요구하기 때문에 원하지 않는 경우는 나만 살짝 워드로 정리해 놓는다...)
과거(불과 몇년전)에는 생략된 경우가 많았다. 대부분 제안서에 들어있는 '수행방안' 부분을 참고해서 진행했으나 최근에 제안의 진실에 대해서 고객과 수행조직 모두 반신반의...분명한 구분이 필요하다고 합의되면서 수행계획서는 더욱 빛을 발하게 된다... 사실 수행계획서...How to에 대한 Plan...이 없다는 것 자체가 이상한 것 아닌가??
프로젝트 수행 계획서 왜 써야하나?
1. 프로젝트를 수행하기전 PM에게는 개념 정리의 기회를 제공...
2. 프로젝트 팀원들에겐 한눈에 프로젝트 전체를 볼 수 있게 함...
3. 진행 도중 새롭게 투입된 팀원에게 빠른 시간안에 프로젝트 정체성을 전파...(개발단계에 진입되면 별 의미가 없어진다...)
4. 프로젝트 수행 도중 모든 산출물들이 이 페이퍼에 귀속되어 진행되므로 수시로 꺼내보게 됨.
5. 비체계화, 비구체화된 제안상의 내용을 체계화, 구체화 함으로서 고객과의 실랑이때 증거물로 용이...
이처럼 다양한 이익이 있으므로 귀찮더라도 반드시 작성하도록 하자...
프로젝트 수행 계획서 누가 써야하나?
Project Manager 가 당연히 작성해야 한다.
프로젝트 수행 계획서에 무엇이 들어가야 하나?
일부 영업적인 마인드를 너무 많이 가진 PM이나 실제 수행 베이스가 약한 PM들은 페이퍼의 양에 승부를 걸고자 한다...실무에 도움이 되지 못하는 수행 계획서는 차라리 없는 것이 낫다...왜냐면 전달하고자 하는 의미가 너무나 모호하여 고객에게는 환상적인 기대치를 팀원들에게는 쓸데없는 질문들을 자아내어 PM 자신만 더욱 고달파 지기 때문이다...
수행계획서의 목차는 프로젝트의 성격에 따라 논리적으로 구성해주면 된다...
가장 일반적인 목차의 흐름은 1. 이번 프로젝트는 무엇인가? 2. 구체적으로 무엇을 만들려고 하는가? 3. 누가 만드는가? 4. 어떤 방법으로 만드는가? 5. 어떤 일정을 계획하고 있는가? 6. 마무리의 의미는 무엇이고 어떻게 할 것인가?
다음은 프로젝트 수행 계획서에 들어가는 일반적인 목차이다.
1. 프로젝트 개요 : 프로젝트 공식명칭, 목적, 목표, 수행내용(brief), 수행기간
2. 수행내역 : 내역별 작업설명(작업범위를 쓰면된다...작업범위에 대한 논란이 많으므로 단어 선택에 유의해야한다.), 개발항목 및 설명(가능하면 자세히 쓰야한다. 메인메뉴가 몇개이고 서브메뉴가 몇개인데..메인메뉴에는 가칭 이런이런 조런조런 것들이 있다...솔루션 패키지는 이런 이런것이 들어가고 대강의 메인펑션은 이런이런 것들이 있다...), 단계별 산출물
3. 수행조직 및 업무분장 : 수행조직도(가능하면 갑과을과병의 모든 관련 담당자를 집어넣도록 하자...가장 중요한것은 메인-커뮤니케이션 주체를 명확히 표시해 주는 것이다.), 직책별 업무정의(PM,PL,PA가 해야할일...그 범위와 권한,책임에 대해 명확하게 정의해준다.), 업무분장내역(공정-activity에 따라 갑과을과병의 주요 실무자를 리스트하고 공정별 그들의 참여도를 수치로 보여준다.)
4. 프로젝트 일정 계획 : 전체 일정표(공정별 예상 소모 시간을 주단위로 계획한다.), 인력 투입 계획(공정별 투입 예상 인력을 업무분야별로 참여도와 날짜...결국 M/M을 수치로 나타내준다...훨씬전에 합의된 견적과 밀접한 관계가 있으므로 PM 머리가 좀 아플 것이다...)
5. 품질 보증 및 관리 계획 : 제안서에 있거나 늘 써먹는 컨텐츠 갖다 붙여라...별로 의미가 없다...가능하면 화려하면서도 철학적이고 학술적이면 유용하다...이 부분에 대해서는 별도로 '프로젝트 표준 정의서'를 통해 고객에게 실제적이고 구체적인 내용을 전달하도록 하자...계획서에 실제적이고 구체적인 내용이 들어가면...백발백중 설전으로 아까운 시간 낭비를 하게 된다...이 부분에 잔뜩 신경써는 고객이 있다면 수행하면서 맘대로 가지고 놀아도 되는 고객이 분명하므로 잘된것이다.
6. 보고 및 검토계획 : 보고종류에 따른 보고 내용과 일정에 대해 써준다.
7. 프로젝트 슬로건 : 알아서 적어라...
프로젝트 수행계획서는 뭘로 만드나?
워드든 파워포인트든 상관없다...액셀도 상관없다...PM 자신이 가장 잘 쓰는 페이퍼웍 도구를 활용하자...
프로젝트 수행계획서는 버젼업 되어야 하나?
버젼업은 1.0이 되기 전까지 가능하다. 1.0은 고객과의 합의를 의미하고 이 후에 버젼업이 지속적으로 일어난다면 그 프로젝트는 난항의 연속...퇴사를 준비하자...
작성시 유의사항은?
프로젝트 수행 도중 언제든지 꺼내서 실무에 적용가능하도록 최대한 최선을 다해 실제에 가깝게 작성되어야한다...
예제는 없는가?
목차만으로 충분하지 않은가? 구체적인 예제를 바란다면 프로젝트 매니저를 포기하길 권장한다...
[출처] 그것을 알랴주맛! 프로젝트 수행 계획서|작성자 즐닭주의
Prev
