Team G.HARD :: cult of hard-corder

이번에는 자바 웹 어플리케이션을 구현할 때 각 Layer별로 사용하는 오픈 소스 프레임 웍에 대해 알아보겠다. 자바의 대부분 오픈 소스 프레임 웍은 Apache Project에서 유지보수 및 업데이트 된다. 종종 Apache Project 사이트에 가보는 것도 현재의 개발상황등을 보는 것도 재미있다.

* Controller
 : 최근에 각광받고 있는 컨테이너 중 하나인 Spring을 주로 Controller Layer에서 사용한다. xml을 이용하여 단순한 bean Class 선언 부터 다양한 라이브러리를 통합 관리할 수 있다. 또한 Interface와 implement를 나눌 수 있기 때문에 (decoupling) 디자인 패턴을 적용하기에도 용이(IoC)하다. 자바 웹 어플리케이션 뿐만아니라 자바 프로그래머가 되려면 어떤 오픈 소스인지는 알고 있는 것이 좋다. (해외의 많은 회사들이 이 spring 기반으로 어플리케이션을 만든다.)

* Model - Dao
 : Model Layer라기보다는 Controller에서 DB 사이에 존재하는 Dao 역할을 하는 프레임웍인 iBatis가 있다. sql문을 하드 코딩하는 것이 아니라 xml 파일로 빼내어 따로 관리할 수 있고, 적절하게 Model에 DB 데이터를 매핑시킬 수도 있다. 복잡한 JDBC 프로그래밍을 간단히 할 수 있다. 역시 알아둬야하는 프레임웍이다.

* View
 : 보통 jsp 및 servlet 프로그래밍시에 문제는 jsp 파일안에 <%~%>로 자바 코딩이 들어간다는 것이다. 이는 곧 View의 UI가 변경되면 소스 코드까지 건드려야한다는 위험요소가 발생하게됨을 의미한다. 최근에는 Servlet과 UI부문을 분리하기 위해 여러 오픈 소스가 사용된다. Servlet단은 Struts를, View에는 Velocity를 적용해서 사용한다. struts는 너무 큰 기능때문에 무거워 사장되어 가고 있고, 현재 struts2의 베타 버전이 발표된 이후 다시 한번 기대를 모으고 있다. 앞으로 정식 릴리즈이후의 충분한 검증을 거치면 서비스에서 써보려는 개발자들이 꽤 있다.
Velocity는 Servlet단에서 넘어온 request의 데이터들을 스크립트 언어 방식으로(정말 스크립트 언어로 보인다. 하지만 자바로 파싱된다) UI를 표현한다. 그다지 무겁지도 어렵지도 않으므로 앞단에서 많이 사용된다.

다음에는 아주 간단한 웹 어플리케이션을 만들어 로컬에서 테스트 해보겠다. (서버가 없으므로 각자가 로컬에서 테스트해야할 듯)

p.s 여기에 소개된 건, 현재 내가 프로젝트에서 주로 쓰는 프레임웍이다. (여기 소개된 것들 말고도 좋은 프레임웍이 참 많다. 한번씩 찾아보길...) 물론 서비스 자체가 이벤트성으로 가볍고 한번 쓰고 버릴 것들은 이렇게 프레임웍 쓰는 자체가 무모한 짓이다. 좋다고 해서 무조건 소 잡는 칼로 닭을 잡아서는 안되는 것이다.

계속적인 유지보수가 요구되고, 어느 정도 큰 규모의 서비스에서 적절하게 필요한 프레임웍을 넣고 어플리케이션을 만들어 나가는 것이 곧 실력이 아닐까?
Posted by xHuro
teQnical/Java dev. l 2007. 1. 14. 21:16

댓글을 달아 주세요

  1. Favicon of http://ghard.tistory.com BlogIcon oveRock  댓글주소  수정/삭제  댓글쓰기

    typeD군의 포스트 시리즈를 Java dev.라는 하위 분류로 세분화하여 이동했습니다.
    이용에 착오 없으시길 바라며, typeD군은 멍석 깔아놨는데 연재중단하는 사태가 없길 바랍니다 :-P

    2007.01.15 12:31 신고

* MVC
 : MFC 프로그래밍을 해봤으면 많이 들어봤겠지만, 일반적으로 어플리케이션은 3 layer로 나누어서 프로그래밍한다. 웹 어플리케이션 역시 구조가 나누어진다.
  Layer를 나누어 프로그래밍하면 솔직히 더 많은 클래스, 인터페이스가 생기고 복잡한 메소드들도 추가되는데 왜 이렇게 나누려고 하는가?라고 의문이 들것이다.
  나 역시 그런 의문이 들었었고, 서비스를 하나씩 개발하면서 알게되었다. 이렇게 명시적으로 나누어 둠으로서 각 Layer간의 결합도를 낮출 수 있으며, 무엇보다 고객의 요구사항으로 인해 한 Layer에서 변경사항이 생기더라도 그 여파가 다른 Layer에게 많이 미치지 않게할 수 있다(ripple effect). 이론상으로 OOP 관점에서 잘 만들어진 Object들끼리의 결합일 경우에는 말이다. (자자... OOP 프로그래머가 할꺼라면 디자인 패턴을 공부해보자.)

* Model
 : 모델 객체. 보통 DB의 특정 테이블을 읽어와서 매핑한다. 자바의 모델 객체는 setter/getter 메소드와 property의 field로 이루어져 있다. 데이터를 담는 것외의 역할은 하지 않는다.

* View
 : 웹 어플리케이션에서는 Servlet 클래스를 View단이라고 한다. 혹 front end라고도 한다. 사용자에게 데이터를 보여주거나, 데이터를 입력받는 역할을 한다.

* Controller
 : Business Logic, 데이터로 수많은 operation을 처리하고 View로 데이터로 넘기거나 Model을 가지고 DB에 저장하는 역할의 Layer이다.

다음에는 실제적으로 자바 웹 어플리케이션에서 MVC 각 Layer에서 사용하는 Open Source Frame work에 대해 간략하게 알아보겠다.
Posted by xHuro
teQnical/Java dev. l 2007. 1. 13. 20:58

댓글을 달아 주세요

  1. Favicon of http://ghard.tistory.com BlogIcon oveRock  댓글주소  수정/삭제  댓글쓰기

    '이론상으로' 라는 말이 웬지 슬픔 -_ㅠ

    2007.01.13 23:09 신고
    • Favicon of https://ghard.tistory.com BlogIcon xHuro  댓글주소  수정/삭제

      이론상이라고 해서 실전에서는 전혀 다르다는 건 아니니. 슬퍼하지 말거라...
      단지, 요구 사항의 변화가 너무 한 Layer에서 끝나는 것이 아니라, DB 구조가 변경되어야 한다던가 하면 어플리케이션의 구조가 전체적으로 바뀔 수 밖에 없는 상황이 훨씬 많으니...
      그렇다고 미리 예측해서 다 만들어둘 수 있는 것도 아니고... 머 그런거 아니겠어?

      2007.01.14 21:20 신고

1 

카테고리

분류 전체보기 (32)
G.HARD bunker (4)
daily routine (18)
rumor says... (0)
teQnical (7)
projeKt (2)

달력

«   2021/10   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
tistory!get rss Tistory Tistory 가입하기!