구현하다보면 설계했던거 보다 더 좋은 방법이 떠오르거나 또 그것으로 인해 생각이 복잡해지는 경우가 많습니다. 이럴때 조심해야 할게 있는데, 설계 변경 시도를 코드로써 풀어내려 하면 안된다는 것입니다.

실제로 전 기수 프로젝트 때 설계에 대한 부분을 중요시 생각 안하고 생각 나는대로 코드로써 풀어나갔었습니다. 막히는 부분도 많았고 점점 알수 없는 코드들로 변해갔습니다. 원하던 결과 값은 나왔으나 알수없는 계산식들...

지금 다시 그 코드를 보면 정말 무식하게 코딩했구나 라는 생각이 들고 또 느낀것도 많았는데, 일단은 설계했던 대로 구현해서 테스트를 통해 기능이 제대로 작동되는지를 우선시 하고, 그 이후에 보완하는식으로 하는게 가장 좋을꺼 같단 생각을 했습니다.

그래서 이번 프로젝트는 단위 테스트(Junit4.4)에 비중을 많이 두고서 진행하고 있고, 안정적이면서 최대한 빠르게 구현하고, 그 이후에 좀 더 나은 방법으로 보완해 나가면서 버전업을 할 계획입니다.

일단 Hibernate Tool을 사용하였고, GenerationSchemaExport를 통해 Model, Schema생성을 한번에 해결하였습니다.

src 폴더에 실질적인 구현 코드들이 만들어지고 있고, test/java와 test/resource에 테스트 코드와 테스트에 필요한 설정파일들을 배치하였습니다. 보시는대로 전체 모듈에 대해서 최대한 테스트를 통해 구현하고 있습니다.
 

비록 간단한 소스 코드이긴 하지만 이러한 작은 것들부터 테스트를 수행하고 빠진 부분이 없는지 확인합니다.

IBatis로 했다면 쿼리문에 대해 많이 신경썼을테고 오류도 쿼리문에 대해서 많이 나왔을테지만 Hibernate는 Mapping 문서에 설정된 연관 관계들과 쿼리 실행전, 후 필요한 설정들에 대해 신경을 써야 합니다. 

Dao와 마찬가지로 비지니스 로직단도 테스트를 수행하며, Controller까지 테스트를 완료하는것으로 한 모듈을 마치게 됩니다.

간단한 MultiActionController 테스트 입니다.
methodParameter 방식을 사용하지 않고 Url경로로써 바로 메서드를 호출 하는 방식을 택했습니다. (상황에 따라서는 methodParameter 방식도 사용하긴 합니다.)


Url 요청이 들어왔을시에 Url에 맞는 메서드가 호출되는지의 확인과 요청된 데이터가 제대로 넘어오는지 테스트합니다.


SimpleFormController도 마찬가지 입니다. (유효성 검사는 아직 진행 단계가 아니라서 제외되었습니다.)

폼 요청시에 필요한 데이터를 가져올수 있는지와 데이터를 전송했을때 데이터를 제대로 바인딩 하는지, 등록과 수정은 제대로 이루어 지는지 테스트를 합니다.
 
현재 모든 모듈들은 이러한 방식으로 테스트를 진행중에 있고 플랙스가 사용되는 부분은 Service단까지만 구현중에 있습니다.

예전에는 테스트 없이 model, dao, service, controller를 모두 구현한 뒤에 웹페이지를 띄워보고서 제대로 작동하는지 확인을 했었는데, (그러다가 결국 원점으로 돌아와 다시 수정을 하곤 했습니다.) 지금 생각해보면 정말 미련하게 개발하진 않았나 싶기도 하고 느낀것도 많았습니다. 항상 모든 프로그램은 실제 상황을 기준으로 모의 테스트를 하되,최하 밑단부터 시작해서 차근차근 구현해 나가야 할 것 같습니다.

'Project > B.M.S' 카테고리의 다른 글

Hibernate.  (0) 2012.03.05
ERD.  (0) 2012.03.05
처음 계획은 IBatis를 사용할 계획이였지만 어쩌다 보니 IBatis + Hibernate로 수정이 일어났고, 현재는 Hibernate로만 진행중입니다.

이유는 이클립스 플러그인 중 하나인 Hibernate Tool을 사용하면 코드 Generation과 DB 스키마 생성을 한번에 해결 할 수 있었기 때문입니다.

물론, 장단점은 다 있습니다. IBatis는 직접 쿼리문을 작성하기 때문에 코드가 어떤식으로 돌아갈지 명확하게 보입니다. 반면에 Hibernate는 Config파일, Mapping 문서에 작성된 대로 연관 관계를 맺고 쿼리문이 자동으로 생성되며 돌아갑니다. (IBatis 방식으로도 사용 가능하긴 합니다.)

그래서 될수 있으면 Hibernate로 올인하려 합니다.

시작에 앞서 저희팀은 Mapping 문서 기반으로 가야할지 Annotation 기반으로 가야 할지 짧게 고민을 해봤으나 어렵지 않게 Mapping 문서 기반으로 하는것으로 결정했습니다.

왼쪽은 Annotation기반으로 작성된 코드이며 오른쪽은 Mapping 문서를 통해 Generation된 코드 입니다.


코드 Generation에 사용된 Mapping 문서 입니다.

Annotation 기반으로 작성된 코드는 심플해 보이지만 Annotation부분은 저희 팀원들 눈에 명확하게 읽히지 않는 문제점이 있었고(Mapping 문서가 눈에 많이 익어서 그런것일수도 있습니다.), Mapping문서를 기반으로 작성된 코드는 몇가지 생성자와 오버라이드 된 toString() 메서드가 추가되서 코드가 생성되었습니다.

하지만, 안좋은 점은 모듈이 추가 될때마다 새로운 모델을 Generation해야 하는데 등록되있는 도메인 모델 전부가 다시 Generation 되는게 좀 불편했습니다. 이유는, 저희팀은 Svn 저장소를 통해 버전업 관리를 하고 있는데 Generation 할때마다 생기는 주석에 시간때문에 변경된 파일로 구분되는 문제가 있었습니다.

해결법이 있는지는 모르겠지만 진행하는데 있어서 큰 어려움은 없었기에 알아보진 않았고, Svn 기능을 이용해서 넘어가고 있습니다.

그 외에도 Mapping 문서에서 쓰일수 있는 속성들이 많은데, 아직 완벽하게 다루지 못하는 가장 큰 문제점이 있으나 개인적인 생각으로는 조만간, 금방 해결해나가면서 진행될 것 같습니다.

결론적으로는 ERD를 통해서 Mapping 문서를 작성하고 코드 Generation.. Dao 구현, 그리고 Junit 테스트를 하는 순서대로 진행하니까 상당히 안정적이고 구현 속도도 빨랐습니다. (Service, Controller도 마찬가지였습니다.)

'Project > B.M.S' 카테고리의 다른 글

Junit.  (0) 2012.03.05
ERD.  (0) 2012.03.05

나름대로의 삽질을 통해 모듈별 라이브러리 정리를 하고 있다. 물론 샘플이지만 큰 그림으로 나눠서 공통으로 쓰이는 모듈..
DB는 mybatis, 또는 하이버네이트별로 모듈을 구분했고.. web쪽은 String, Struts2로 구분했다.
다 돌려보기엔 시간이 부족했고.. 하루종일 이짓만 하고 있을순 없었기에 예전에 날 괴롭혔던 하이버네이트를 먼저 돌려봤다. 역시 한번에 돌아갈리 없었고.. 라이브러리 추가 작업이 필요했다.


처음 프로젝트 관리를 이렇게 하려고 했다.
DB > Logic > Web Controller.. 이렇게 나누려고 했다.

큰 프로젝트 경험이 없어서 그런지.. 굳이 DB와 Logic을 구분해야 할지 의문이였다.

단순하게 큰 프로젝트에서는 당연히 나뉘지요. 라는 대답은 해보지 않아도 그냥 공감은 될것같은데..
저... DB단은 넘어온걸 그냥 넣기만 하는 단순 작업일텐데 1인이 DB/Logic개발을 맡아서 한다면 하나의 모듈로 개발해도 될지가 궁금했다.

......갑자기 또 떠오른게 있다. 직접 쿼리를 다루게 된다면 말이 틀려질수도 있겠구나 싶네...-_-;; 단순작업이 아닐테지..

아무튼 요즘 자꾸 내 직업에 대해 지속적인 관심을 갖고 언젠가 크게 발전하기 위해 이것 저것 해본다.
가만히 있는것 보다.. 노는것 보단 나을테니까.. 
Schema Export 보기.

이제 디비에 insert, update, del.... 간단한 테스트를 해봅니다.
해보니까 알아서 쿼리문 사용하고.. 편하긴 편한거 같은데... (뭔가 찝찝..)

일단 지저분한 테스트 코드로 데이터를 넣어봤습니다. 말그대로 Insert 하는것이고..
그냥 객체 생성해서 save하면 끝나는거 같네요. 물론 하이버네이트에는 많은 기능들이 있을테지만..
save뿐이 모르기에 ^^


테스트 돌려보니 역시나 콘솔창에서 알아서 쿼리문을 만들어서 집어넣는거 같습니다.
음.. 넘어온 파라미터들까지 볼 수 있으면 좋을텐데요.........
어딘가 그런 설정이 있을거 같은데.. 없으려나 ㅎㅎ [ Log4j 설정 보기 ]


삭제와 수정을 해보기에 앞서 DB에서 객체를 가져오는거 먼저...
(일단 매번 session을 얻어오고 transaction.. try ~ catch 해주는 중복 코드는 인터페이스와
추상클래스로 제거했습니다.)


- get : 호출 시점에서 select 쿼리 실행.
- load : 객체의 값이 실제로 필요한 시점에 쿼리 실행.

정말 간단합니다...........
나머지 수정과 삭제를 해봐야 하는데.. select 된 객체를 넣어주면 끝납니다.....


당연한 얘기지만.. 가져와서 수정을 하네요.
근데 이렇게 되면 매번 수정을 하기 위해선 select를 무조건 실행해야합니다.

그럼 이렇게 해보는건?? (사실 전 첨에 이렇게 했었습니다만..........)



결과는...


저도 되지 않을까 싶었는데.. board.hbm.xml에 설정하기를 writer 컬럼은 not-null로 설정해서
업데이트 할때에도 넣어줘야 하나보드라구요. 수정이 필요없는 데이터까지 억지로 넣어줘야 하는..
할튼 그 방법은 좀 별로인듯 싶네요.

그리고 이 방법을 쓰려면 equals 메서드를 구현해줘야 한다는거 같네요.
그건.. 예전 설정 파일에서 mata 속성을 설정했던적이 있는데 저 상태로 generation하면
도메인 객체에 저 메서드들이 오버라이딩 된다고 했었습니다.



이런식으로 오버라이딩 되서 만들어집니다.
이 메서드가 없다면 위 방식의 업데이트는 이루어지지 않습니다.



Delete부분은 Update와 같기때문에... 알아서;;

정말 기본적인 CRUD 해봤는데 아직 하이버네이트에 기능들을 다 몰라서 이정도뿐이 안되는군요.
일단 여기서는 HQL을 쓰지 않았습니다.

공부.. 해도 해도 끝이 없습니다.... ㅅㅂ;;

'Database > Hibernate' 카테고리의 다른 글

큐브리드 foreign key.....  (0) 2010.07.04
Hibernate Log4j 설정.  (0) 2009.10.24
SchemaExport.  (0) 2009.10.24
Hibernate Code Generation..  (0) 2009.10.23
Hibernate 도전!  (0) 2009.10.22
이전 맵핑 설정 / Generation 보기.

하이버네이트 설정... sessionFactory 얻어오기.. 그리고 도메인 객체까지 Generation 했습니다.
그것을 바탕으로 DB 스키마 생성을 해보도록 하겠습니다.

비교적 간단합니다.

sc.create(false, true);


첫번째 인자값은 script를 확인 할껀지..
두번째 인자값은 실제 DB에 스키마를 생성할껀지 조건입니다.



Junit으로 실행 후 실제 DB 확인 결과 앞전에 board.hbm.xml 에 설정했던대로 테이블이 생성됬습니다.



이번에는 sql문을 확인해보겠습니다.


이런식으로 콘솔창에서 확인해볼수 있습니다. 근데 각 쿼리문에 ';' 이 빠졌네요.

실행해서 확인된 쿼리문은 hibernate.cfg.xml에서 mapping resource에 등록된 맵핑 파일에 대해서만 출력합니다.

이번엔 쿼리문 확인과 그 sql 쿼리문을 파일로 저장해보겠습니다.


sc.setDelimiter(";"); // 각 쿼리문에 ';' 추가.
sc.setOutputFile("src/schema.sql"); // 저장 위치 지정.
sc.create(true, false); // DB와 상관없이 스크립트 관련해서 생성합니다.

CRUD Test.

'Database > Hibernate' 카테고리의 다른 글

큐브리드 foreign key.....  (0) 2010.07.04
Hibernate Log4j 설정.  (0) 2009.10.24
CRUD Test.  (0) 2009.10.24
Hibernate Code Generation..  (0) 2009.10.23
Hibernate 도전!  (0) 2009.10.22

+ Recent posts