기본적으로 j2ee 어플리케이션에서 비즈니스 계층과 프리젠테이션 계층 사이에서 배열이나 컬렉션을 주고 받는 건 심각한 설계의 결함입니다. 더구나 resultset까지 넘긴다면 아예 퍼시스턴스 계층까지 프리젠테이션 계층에서 다루게 되는데 이는 계층을 분리하는 이유 자체를 무시하는 설계입니다. 차라리 그럴 바엔 asp처럼 jsp에서 모든 걸 처리하는게 훨씬 개발도 쉽고 디버그도 쉽습니다.
대부분 MVC적 설계에서는 배열이나 벡터에 담긴 스칼라 데이터 대신 도메인 객체나 도메인 객체의 컬렉션을 넘기게 됩니다. (경우에 따라선 도메인 객체에 대한 뷰를 만들기도 합니다).
참고로 Java 2에서 Vector나 Hashtable은 쓰지 않습니다. 각각 ArrayList와 HashMap으로 대체하는 것이 좋으며, 만일 컬렉션의 성능이 문제가 된다면 자카르타의 commons-collection의 Fast 컬렉션 시리즈를 사용하시기 바랍니다.
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
기본적으로 j2ee 어플리케이션에서 비즈니스 계층과 프리젠테이션 계층 사이에서 배열이나 컬렉션을 주고 받는 건 심각한 설계의 결함입니다. 더구나 resultset까지 넘긴다면 아예 퍼시스턴스 계층까지 프리젠테이션 계층에서 다루게 되는데 이는 계층을 분리하는 이유 자체를 무시하는 설계입니다. 차라리 그럴 바엔 asp처럼 jsp에서 모든 걸 처리하는게 훨씬 개발도 쉽고 디버그도 쉽습니다.
대부분 MVC적 설계에서는 배열이나 벡터에 담긴 스칼라 데이터 대신 도메인 객체나 도메인 객체의 컬렉션을 넘기게 됩니다. (경우에 따라선 도메인 객체에 대한 뷰를 만들기도 합니다).
참고로 Java 2에서 Vector나 Hashtable은 쓰지 않습니다. 각각 ArrayList와 HashMap으로 대체하는 것이 좋으며, 만일 컬렉션의 성능이 문제가 된다면 자카르타의 commons-collection의 Fast 컬렉션 시리즈를 사용하시기 바랍니다.
아까 글 실컷 썼다가 서버 이전 작업으로 다시 올립니다 -_-
개발 초창기에는 도메인별로 property들을 일일이 만들어서 작업했습니다.
그러다가, CachedRowSet(ResultSet을 끝까지 돌려서 Vector나 Hashtable에 저장해놓는 놈이라고 알고있습니다..)이나 그 비슷한 종류를 쓰는 사람들이 있더군요.
처음에는 MVC 모델에 맞지 않는, fender님께서 말씀하신것처럼 "이는 계층을 분리하는 이유 자체를 무시하는 설계"라고 생각되어서 이상하게 쳐다봤는데, 이런 것들이 작업시간이 모자랄때 한번 써봤더니, 편하더라구요. :oops:
물론, property들이 db 의 raw data에서 거의 변경없이, rs.getString(columnName)정도로 바로바로 써도 되는 환경에서의 작업이라서 더 편한 점도 있었고, set, get을 일일이 하지 않아도 되므로, 쓸만하구나 생각되더라구요.
이런 경우에 대해서 어떻게 생각하시는지 궁금하네요..
p.s. 이 부분..
Quote:
참고로 Java 2에서 Vector나 Hashtable은 쓰지 않습니다. 각각 ArrayList와 HashMap으로 대체하는 것이 좋으며, 만일 컬렉션의 성능이 문제가 된다면 자카르타의 commons-collection의 Fast 컬렉션 시리즈를 사용하시기 바랍니다.
에 관해서 부연설명 좀 해주시면 감사하겠습니다.
지금까지의 소스에는 Vector와 Hashtable가 난무했거든요 T_T
개발 초창기에는 도메인별로 property들을 일일이 만들어서 작업했습니다.
그러다가, CachedRowSet(ResultSet을 끝까지 돌려서 Vector나 Hashtable에 저장해놓는 놈이라고 알고있습니다..)이나 그 비슷한 종류를 쓰는 사람들이 있더군요.
처음에는 MVC 모델에 맞지 않는, fender님께서 말씀하신것처럼 "이는 계층을 분리하는 이유 자체를 무시하는 설계"라고 생각되어서 이상하게 쳐다봤는데, 이런 것들이 작업시간이 모자랄때 한번 써봤더니, 편하더라구요. :oops:
물론, property들이 db 의 raw data에서 거의 변경없이, rs.getString(columnName)정도로 바로바로 써도 되는 환경에서의 작업이라서 더 편한 점도 있었고, set, get을 일일이 하지 않아도 되므로, 쓸만하구나 생각되더라구요.
이런 경우에 대해서 어떻게 생각하시는지 궁금하네요..
2계층 설계에서는 CachedRowSet을 쓰는 경우가 있습니다. 사실 2계층 설계는 무조건 나쁘고 3계층 이상의 구조가 좋다고 말하긴 어렵습니다. 실제로 최근 CachedRowSet과 비슷한 개념을 사용해서 이를 직접 표현 계층에 스프레드 시트처럼 나타낼 수 있게 하는 제안이 JSR에 올라올 정도로 이런 쪽의 접근 방법도 여전히 사용되고 있습니다.
한편 CachedRowSet을 쓰지 않고 '범용적인' 컨테이너 객체를 만들어서 MVC 구조에서 도메인 모델과 무관하게 사용하자는 아이디어도 종종 디자인 관련 게시판에 올라오곤 합니다.
이런 방법들은 분명 개발 기간 단축이라는 장점을 가지고 있습니다만, 반면 단점도 많습니다. 우선 말씀드렸 듯이 계층간 분리를 무시하고 퍼시스턴스 계층과 표현 계층의 의존성을 만들게 됩니다.
많은 경우 데이터베이스의 스키마와 실제 그 데이터가 웹상에 표현되는 방식 사이에 차이가 있는 경우가 있습니다. 특정 속성을 합산하거나 비율을 구하거나, 아니면 특수한 방식으로 처리를 하여 보여줄 수도 있습니다. 물론 어떻게든 SQL을 복잡하게 작성하고 JSP에서 계산을 해주면 되지만 도메인 모델이나 특화된 뷰를 사용하는 것보다 손이 많이가고, 무엇보다 불필요하게 코드가 복잡해 집니다.
또한 위의 두 가지 방식 모두 표현 계층에서 해당 rowset이나 컨테이너에 저장된 데이터의 성격을 정확히 알아야 한다는 문제가 있습니다. 예를들어 컬럼이름이 무엇이고 숫자형인지 문자형인지 등에 따라 표현 계층이 바뀌게 됩니다. 쉽게 생각해서 이렇게 설계 했을 때 나중에 데이터베이스 스키마가 변경되면 퍼시스턴스 계층 뿐 아니라 jsp까지 모두 수정을 해야 하는 번거로움이 있습니다.
그리고 도메인 모델이 없을 경우 반대로 웹에서 데이터를 입력 받아 저장하는 프로세스의 경우 일일이 리퀘스트 파라메터를 파싱해서 SQL을 작성해야 하는 번거로움이 있습니다.
따라서 개인적으로 단순히 계층 수를 줄이기 위해 유지보수를 어렵게 만드는 설계 보다는 3계층 설계 기본으로 hibernate나 struts 등을 이용해 최대한 퍼시스턴스나 데이터 처리를 자동화하는 방향을 선호합니다.
특히 hibernate를 사용하면 퍼시스턴스 계층을 생략하고 비즈니스 계층에서 SQL 없이 직접 도메인 모델로 데이터 처리를 할 수 있어 상당히 코딩이 줄어 듭니다. 또한 웬만큼 개발 중에 데이터베이스 구조가 바뀌어도 (테이블 스키마 자체도 자동 생성이지만...) 표현 계층에 최소한의 영향만 주고 변경 가능한 장점이 있습니다.
최근에 나오는 O/R 매핑 솔루션 들이나 MVC 프레임워크 등등이 모두 이런 방향을 지향하고 있기 때문에 써드 파티 지원이나 툴 지원등이 상대적으로 2계층에 비해 강력하다는 강점도 있을 수 있습니다.
chocoheim wrote:
p.s. 이 부분..
Quote:
참고로 Java 2에서 Vector나 Hashtable은 쓰지 않습니다. 각각 ArrayList와 HashMap으로 대체하는 것이 좋으며, 만일 컬렉션의 성능이 문제가 된다면 자카르타의 commons-collection의 Fast 컬렉션 시리즈를 사용하시기 바랍니다.
에 관해서 부연설명 좀 해주시면 감사하겠습니다.
지금까지의 소스에는 Vector와 Hashtable가 난무했거든요 T_T
그냥 복잡하게 생각하지 마시고 Vector 쓸 자리에 ArrayList를, Hashtable 자리에 HashMap을 쓰시면 됩니다 :) 아니면 http://jakarta.apache.org/commons에 가셔서 commons-collection 패키지를 받아 각각 FastArrayList, FastHashMap 등으로 대체하셔도 좋습니다.
그럼~
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
기본적으로 j2ee 어플리케이션에서 비즈니스 계층과 프리젠테이션 계층 사
기본적으로 j2ee 어플리케이션에서 비즈니스 계층과 프리젠테이션 계층 사이에서 배열이나 컬렉션을 주고 받는 건 심각한 설계의 결함입니다. 더구나 resultset까지 넘긴다면 아예 퍼시스턴스 계층까지 프리젠테이션 계층에서 다루게 되는데 이는 계층을 분리하는 이유 자체를 무시하는 설계입니다. 차라리 그럴 바엔 asp처럼 jsp에서 모든 걸 처리하는게 훨씬 개발도 쉽고 디버그도 쉽습니다.
대부분 MVC적 설계에서는 배열이나 벡터에 담긴 스칼라 데이터 대신 도메인 객체나 도메인 객체의 컬렉션을 넘기게 됩니다. (경우에 따라선 도메인 객체에 대한 뷰를 만들기도 합니다).
참고로 Java 2에서 Vector나 Hashtable은 쓰지 않습니다. 각각 ArrayList와 HashMap으로 대체하는 것이 좋으며, 만일 컬렉션의 성능이 문제가 된다면 자카르타의 commons-collection의 Fast 컬렉션 시리즈를 사용하시기 바랍니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
[quote="fender"]기본적으로 j2ee 어플리케이션에서 비즈니스
아까 글 실컷 썼다가 서버 이전 작업으로 다시 올립니다 -_-
개발 초창기에는 도메인별로 property들을 일일이 만들어서 작업했습니다.
그러다가, CachedRowSet(ResultSet을 끝까지 돌려서 Vector나 Hashtable에 저장해놓는 놈이라고 알고있습니다..)이나 그 비슷한 종류를 쓰는 사람들이 있더군요.
처음에는 MVC 모델에 맞지 않는, fender님께서 말씀하신것처럼 "이는 계층을 분리하는 이유 자체를 무시하는 설계"라고 생각되어서 이상하게 쳐다봤는데, 이런 것들이 작업시간이 모자랄때 한번 써봤더니, 편하더라구요. :oops:
물론, property들이 db 의 raw data에서 거의 변경없이, rs.getString(columnName)정도로 바로바로 써도 되는 환경에서의 작업이라서 더 편한 점도 있었고, set, get을 일일이 하지 않아도 되므로, 쓸만하구나 생각되더라구요.
이런 경우에 대해서 어떻게 생각하시는지 궁금하네요..
p.s. 이 부분..
에 관해서 부연설명 좀 해주시면 감사하겠습니다.
지금까지의 소스에는 Vector와 Hashtable가 난무했거든요 T_T
WaitplzplzWait
[quote="chocoheim"]개발 초창기에는 도메인별로 proper
2계층 설계에서는 CachedRowSet을 쓰는 경우가 있습니다. 사실 2계층 설계는 무조건 나쁘고 3계층 이상의 구조가 좋다고 말하긴 어렵습니다. 실제로 최근 CachedRowSet과 비슷한 개념을 사용해서 이를 직접 표현 계층에 스프레드 시트처럼 나타낼 수 있게 하는 제안이 JSR에 올라올 정도로 이런 쪽의 접근 방법도 여전히 사용되고 있습니다.
한편 CachedRowSet을 쓰지 않고 '범용적인' 컨테이너 객체를 만들어서 MVC 구조에서 도메인 모델과 무관하게 사용하자는 아이디어도 종종 디자인 관련 게시판에 올라오곤 합니다.
이런 방법들은 분명 개발 기간 단축이라는 장점을 가지고 있습니다만, 반면 단점도 많습니다. 우선 말씀드렸 듯이 계층간 분리를 무시하고 퍼시스턴스 계층과 표현 계층의 의존성을 만들게 됩니다.
많은 경우 데이터베이스의 스키마와 실제 그 데이터가 웹상에 표현되는 방식 사이에 차이가 있는 경우가 있습니다. 특정 속성을 합산하거나 비율을 구하거나, 아니면 특수한 방식으로 처리를 하여 보여줄 수도 있습니다. 물론 어떻게든 SQL을 복잡하게 작성하고 JSP에서 계산을 해주면 되지만 도메인 모델이나 특화된 뷰를 사용하는 것보다 손이 많이가고, 무엇보다 불필요하게 코드가 복잡해 집니다.
또한 위의 두 가지 방식 모두 표현 계층에서 해당 rowset이나 컨테이너에 저장된 데이터의 성격을 정확히 알아야 한다는 문제가 있습니다. 예를들어 컬럼이름이 무엇이고 숫자형인지 문자형인지 등에 따라 표현 계층이 바뀌게 됩니다. 쉽게 생각해서 이렇게 설계 했을 때 나중에 데이터베이스 스키마가 변경되면 퍼시스턴스 계층 뿐 아니라 jsp까지 모두 수정을 해야 하는 번거로움이 있습니다.
그리고 도메인 모델이 없을 경우 반대로 웹에서 데이터를 입력 받아 저장하는 프로세스의 경우 일일이 리퀘스트 파라메터를 파싱해서 SQL을 작성해야 하는 번거로움이 있습니다.
따라서 개인적으로 단순히 계층 수를 줄이기 위해 유지보수를 어렵게 만드는 설계 보다는 3계층 설계 기본으로 hibernate나 struts 등을 이용해 최대한 퍼시스턴스나 데이터 처리를 자동화하는 방향을 선호합니다.
특히 hibernate를 사용하면 퍼시스턴스 계층을 생략하고 비즈니스 계층에서 SQL 없이 직접 도메인 모델로 데이터 처리를 할 수 있어 상당히 코딩이 줄어 듭니다. 또한 웬만큼 개발 중에 데이터베이스 구조가 바뀌어도 (테이블 스키마 자체도 자동 생성이지만...) 표현 계층에 최소한의 영향만 주고 변경 가능한 장점이 있습니다.
최근에 나오는 O/R 매핑 솔루션 들이나 MVC 프레임워크 등등이 모두 이런 방향을 지향하고 있기 때문에 써드 파티 지원이나 툴 지원등이 상대적으로 2계층에 비해 강력하다는 강점도 있을 수 있습니다.
그냥 복잡하게 생각하지 마시고 Vector 쓸 자리에 ArrayList를, Hashtable 자리에 HashMap을 쓰시면 됩니다 :) 아니면 http://jakarta.apache.org/commons에 가셔서 commons-collection 패키지를 받아 각각 FastArrayList, FastHashMap 등으로 대체하셔도 좋습니다.
그럼~
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
댓글 달기