오랜만에 다시 본 애니프레임

얼마만에 살펴보는 건지 모르겠지만, 많이 발전한 것 같은 느낌입니다. OSAF를 공개하고나서 프레임워크 공개가 얼마나 쉽지 않은 일인가.. 얼마나 챙길 것이 많은지를 몸소 채험하고 있는 와중에 애니프레임을 보니까 뭔가 느낌이 새롭습니다. 깔끔한 홈페이지부터 잘 정리되어 있는 문서화가 정말 부러웠습니다. 크게 Core랑 Web이랑 Tool과 예제가 있고, 그 중에서 Core, Web을 봤더니 다시 메이븐으로 세세 하게 다시 나눠 두었습니다. 보면서 몇 가지 놀라웠던 걸 정리하겠습니다.

1. 프레임워크 외적인 요소.

깔끔한 홈피와 다량의 문서화가 부러웠습니다. 사용자와 그들의 피드백을 받고 있다는 것두요. 이것도 어쩌면 일종의 피드백을 드리는 것이오니.. 제가 지금 뭘 하고 있는거죠? ㅋㅋㅋ OSAF 홈피 가꿔도 모자랄 판에 지금 애니프레임 리뷰를 해주고 있다니 ㅠ.ㅠ 그래도 괜찮습니다. 많이 배웠거든요.

2. 하이버네이트 학습 테스트

가장 놀랜건 hibernate 모듈이었습니다. HQL을 XML에서 읽어오는 서비스였습니다. 해당 기능을 제공하는 서비스 인터페이스와 구현체 하나씩을 제공하는 모듈입니다. HQL 변경하기도 쉽고 담당자가 일괄적으로 관리하기 편하겠죠.


왼쪽에 패키지 명들을 쭉 보면.. 감탄만 나옵니다. 거기에 테스트 클래스를 작성한 걸 보면 코드 뿐만이 아니라 테스트 하고자 하는 시나리오를 적어 둔 걸 볼 수 있습니다. 남을 고려한 코드가 바로 저런게 아닌가 싶더군요. 저도 개인적으로 하이버네이트 학습을 하면서 만든 학습 테스트들이 쫙 있는데 요즘은 시간이 지나서 찾아 보려고 해도 해당 테스트가 뭘 테스트 했는지 천천히 코드를 읽어보기 전까진 알기 힘든데.. 정말 좋은 방법인 것 같습니다. 한 수 배웠습니다. 하이버네이트 RI 프로젝트를 진행할 땐 저런식으로 해야겠습니다.

3. 코드 원 저자 표시 분명해짐


제가 예전에 봤을 때는 유겐이나 로드 존슨의 이름도 없이 그들이 작성한 코드를 여러 곳에서 발견할 수 있었습니다. 그걸 보고 감정이 상해서 글을 좀 겪하게 썼었는데요. 이번에는 그런 코드가 없는 것 같습니다. 이런 원저자 표기는 시각적으로, 이성적으로, 감정적으로도 여러 긍정적인 효과를 준다고 생각합니다. OSAF아직 원 저자를 표시해 줄만한 코드가 없다보니 전부 Author Toby, Whiteship 입니다.

4. private static Log(X)


이것도 역시 지난 번에 지적했었던 문제 같은데 고쳐졌습니다. 수정하신 분인 임수연님 이신듯 한데요. 이 분이 애니프레임워크에서 hibernate를 포함하여 상당히 많은 부분에 기여(?라고 하긴 좀 그런가요.ㅎㅎ) 하신 것 같네요. OSAF도 이 부분은 일찌 감치 사부님의 지시하에 private static을 사용했었죠. 그래서 저는 한동안은 원래 private static으로 하는 거구나.. 로 알고 있었습니다.ㅋㅋ
이 부분은 http://wiki.apache.org/jakarta-commons/Logging/StaticLog 이 글 혹은 http://whiteship.me/1637 이 글을 참조해서 수정이 필요합니다.

5. 애스팩트도 사용하는 구나…


사용 예제 뿐만 아니라 프레임워크에서 제공하는 Aspect도 있습니다. 성능 모니터링에 사용할 애스팩트 같은데 좋쵸 그런거 제공해주면.. OSAF도 지난 스프링 세미나에서 발표했던 애스팩트 중에 쓸만한 것들은 포함에서 M2 때 공개해야겠습니다.

6. 작명 규칙이 뭔가 맘에 안드네

그렇다고 좋은 것만 눈에 띄진 않았습니다. 인터페이스를 표기할 때 I(영문 대문자 아이)를 붙이기로 한 것 같은데 저에게는 저런 표기가 좀 낯설어서 그런지 코드 보기가 불펴했습니다. IPropertyService = 아이프로퍼티서비스. 그럼 구현체는 그냥 PropertyService인가… 아니요. PropertyServiceImpl 입니다. 그럼 그냥 인터페이스는 PropertyService라고 하고 구현체는 뒤에 Impl을 붙이는 걸로 구분하는게 낫지 않았을까 싶은데.. 뭐 개발팀에서 정할 일이니 모르겠습니다. 기왕 스프링 기반 프로젝트면 스프링 작명 스타일을 따르는게 좋치 않을까 하는 개인적인 소망입니다. OSAF는 스프링 작명을 따르고 있습니다.

7. 예제 코드의 수많은 설정 파일

자바 1.5 미만 프로젝트를 지원하기 위해서겠지만, 설정 파일이 정말 많네요. 이건 뭐.. 어찌해야 될런지.ㅋㅋ;;; 새삼 OSAF는 설정 파일이 정말 없는거구나 하는 생각이 들더군요.


예제 코드의 applicationContext만 저정도… OSAF는 물개선샌님께서 설정 파일이 없어서 어디서 설정한 건지 알 수가 없었다는… 후훗. 애노테이션이 다 그렇쵸 뭐.ㅋㅋ 장단점이 있는 것 같습니다. 애노테이션으로 하면 설정을 한 군대에서 볼 수 없으니 답답하고, 세부 내용이 기본값 등으로 숨겨져있을 수 있어서 뭔가 명시적이지가 않은데, 설정 파일 수는 줄어 들고 소스코드랑 그와 관련된 설정이 한 군대에 있으니까 소스 코드 보면서 설정 보기도 편한데 반면.. XML은 블라블라브라ㅡㅏ브ㅏ..

8. 웹 예제.. 좀 짱인듯

웹 예제를 보니까 스프링 시큐리티, 재스퍼 리포트, Flex, Ajax, 캬오.. 너무 많은 내용이 하나의 예제에 들어가있는것이 아닌가 싶었습니다. 돌려보진 않았습니다. parent 폼을 못찾아서 지금 모든 프로젝트가 다 빨간 불이거든요.ㅋㅋ OSAF와 비교해 보면 태그 파일이 전혀 없습니다. 커스텀 태그는 몇 개 보이던데 OSAF가 제공하는 화면 컴포넌트 같은 것은 없습니다. JSP는 여전히 노가다로군요. 이 부분에 대한 프레임워크 지원은 미약했습니다. 화면 컴포넌트는 OSAF가 짱입니다.

9. 약간 아쉬운 거 ‘틀’

DAO 구현에 어떤 틀이 있는가? 조금 애매합니다. 그냥 일반적인 스프링을 사용한 DAO 구현처럼 보이기도 하는데, 쿼리를 보내는 부분은 애니프레임이 제공하는 쿼리 서비스를 사용해서 합니다. OSAF와는 정반대의 모습니다. GenericDAO라는 확실한 틀을 제공하고 쿼리는 자율에 맡기고 있습니다.

Service 구현에도 어떤 틀은 없네요. CRUD같은 반복적인 코드도 DAO와 마찬가지로 직접 일일히 구현해야 합니다. 예제를 보니까 DAO와는 달리 서비스 쪽은 인터페이스를 사용해서 만들고 있습니다. 흠~ 인터페이스를 쓰려면 DAO도 쓰고 안 쓰려면 Service도 쓰지 말지 왜 그렇게 했을지 좀 의아했습니다. 어쨋든 어떤 틀 같은 건 없었습니다. OSAF는 GenericService를 제공하죠. 두 종류의 GenericService를 제공하는데 하나는 Context가 있는 것(다른 것에 종속하는 것)이고, 하난 없는 것(독립적인 것)입니다.

컨트롤러 구현에는 어떤 틀이 있습니다. 위에서 본 코드 중에 하나인 AnyframeFormController 같은 것을 상속하여 컨트롤러를 만들고 있습니다. OSAF도 두 종류의 GenericController를 제공하여 컨트롤러 구현을 매우 간편하게 할 수 있도록 멋진 기능을 제공하고 있죠. 애니프레임이 제공하는 컨트롤러를 쓰더라도 상당 부분의 코드느는 스프링을 그냥 썼을 때와 비슷해 보입니다.

결론적으로.. 애니프레임의 프레임이라는 것이.. 조금 불투명해 보인다는 것입니다. OSAF 처럼 확실한 틀이 안 보입니다.

10. 발전한 모습에 정말 놀랐습니다.

몇 개월 전에 봤던 그 프레임워크가 맞나 싶을 정도로 많이 발전한 모습이고 코드 곳곳에서 노력하신 흔적을 볼 수 있었습니다. 샘날 정도로….

이것으로 상당히 긴 애니프레임 리뷰를 마치겠습니다. 몇 달 전엔 죄송했습니다. (__)/