해쉬맵의 활용 전략(map dto, dto factory)

정확치 않은 이해를 스케치 하는것임을 주의!

목적:

서버,클라간 요청/응답 횟수를 줄이고, do들과 dto들 사이의 의존성 줄임

전제:

클라의 ui에 표시되는 데이터들은 서버측 데이터를 이용해 초기화된다.

서버측에 여러 do들의 모임..(게임이라면.. 캐릭터정보do, 맵정보do, 아이템정보do, 몬스터정보do등등)

을 관리하는 객체가 있다면 (facade 세션빈.. 메디에이터)

요놈에 대해 정보를 요청할때.. 전체 정보를 요청할 것인가? 아니면 개별 do정보를 요청할 것인가?

개별 do중 각각의 어트리뷰트를 요청할 것인가에 대해..

컨셉:

1.클라측에서 해당 유스케이스A에 해당하는 dto를 요청(캐릭정보중 a,b 맵정보중 a,b 몬스터정보중 a,b)

2.서버에선 유스케이스별로 dto를 해쉬맵에 구성해둔후 맵을 통채로 클라에 전달

물론 이작업 역시.. 팩토리 클래스가 담당

글고 여기서 제네릭 엑세스 패턴이 활용.. 컨셉은 전체 집합에서 찾아낼 집할을 의미하는 키값의 집합을 매개

변수로 get메서드를 호출하면.. 내부에서 전체 조회를 통해 일치하는 키에 해당하는 집합을 새로이 해쉬

맵으로 구성해 리턴하는 전략.. 컨테이너의 생성자등 메서드의 매개변수로 다른 컨테이너를 받는 의미가

이러한 의미임!

아참.. 타입을 제너릭하게 사용시..Object 타입들이 왔다 갔다 하니..  형변환이란 노가다 작업이 필요해지긴하

다.. 큰 목적을 이루기 위해 이정도 수고쯤음 -_-a

제네릭 엑세스 인터페이스 형태

public interface AttributeAccess

{
  public Map getAttributes(Collection attributeKeys);

  public Map getAllArrtibutes();

  public void setAttributes(Map attributes); //셋과 비교해 맵의 장점 = 덮어쓰기 가능!(예전에 맵의 put을 잘못 이해했었지..)

}

글고.. dto에 맵적용 패턴활용시 타입점검의 기능이 약해짐.. 단순하게 구성하면.. key도 object형이기 

때문에.. 해당 맵엔 모든 타입(do)들이 들어갈수 있음.. 이걸 방지하려고.. 상위 타입을 만들고 key값에

<? extends BaseA>가 가능하긴 하지만.. 이렇게 되면.. 너무 복잡해질듯.. 직접 구현할 레벨이 안되기 

땜에.. 막연한 느낌이랄까..?

컨테이너들이 직렬화를 구현한 이유는 원격 송수신 이란.. 기본 전제가 있기 때문임.. 스윙의 컴포넌트

들.. 역시.. bean 형태로서 직렬화및, 각종 셋/겟지원.. + key/value로서 내부에 해쉬셋을 가지고 있다는

점.. (프로퍼티란 데이터 타입은 해쉬셋의 일종으로 키와 값을 문자열로 다룬다는 점만 특이점임.. 문자열

타입의 집합은 xml과 연동이 쉽고..)

추가로 키값을 개발자가 알지 못할 경우를 위해 해당 컨테이너(빈클래스,스윙컴포넌트) 클래스에선

static final String XXXX = "xxaasasa"; 처럼 키값을 지원함..  예전에 워드 + 포맷 객체 프로젝트 진행시

포맷 객체를 외부에서 생성후 전략 패턴을 사용했지만.. 내가 생각했었던.. 즉..외부에서 type을 지정해

주고.. 내부에서 switch case..  사용시 word객체.(Format.NORMAL, "안녕하세요") 처럼.. 요렇게 사용할

수 있게끔.. 타입(key)를 지원해주는것임.. 

물론 타입 안정성을 더욱 엄격히 해주려면.. 예전에 구상했던.. 채팅 프로그램에서 메세지를 계층

구조화 한것처럼.. enum을 사용해서.. 정확한 구현은 기억안나지만.. enum KeyType{A,B,C}로..

구현하고 위에서 생각한 것처럼.. 매개변수를 받을때 extends 상위 타입 또는 매개변수의 타입을 KeyType

으로 .. 요게 될런지는 모르겠음..

3.클라에선 해당 맵에서 알아서 꺼내씀.. 캐릭정보라면.. dto객체에 get("character")해서 캐릭터 해쉬맵

을 얻고, 캐릭터 정보중 상태정보를 원하면.. 캐릭터 해쉬맵에 대해 get("status")를 해서 상태정보(이걸

do로 구분할지, 어트리뷰트로 구분할진..모르겠음) 해쉬맵을 얻고.. 캐릭터의 hp가 필요하다면.. -_-;; 

int hp = statusMap.get("hp"); 요런식으로 ??  하여튼.. 모든 어트리뷰트에대해 set/get 추가가 불필요하

단.. 장점이 있음.. 

(주의할게.. bean managed  vs container managed 에서 전문가들은 cmp를 권하는 것의 의미를 상기해

야함.. ejb 패턴.. 너무너무 복잡하고.. 개념이 명확히 서질 않고 혼동되고 잇음 ㅠㅠ DTO Factory패턴과

DTO hashmap 패턴이 짬뽕이 된듯.. 이책은 3번쯤 읽어봐야 감좀 잡을듯;; 내수준에 너무 벅참;;)

2번에서 유스케이스별(몬스터와 싸우다 = 캐릭터 정보, 몬스터정보, 아이템정보, 지형정보등) 필요한 데이터를

이뮤터블로서(원본/사본) 묶어준후에.. 클라에 전송하면.. 클라는 필요한 정보를 뽑아내서 사용하면 될테고..

중요한 판정,유효성 검증등은 서버측에 맡기고.. (이것도 애매함.. 서버와 클라간 통신 횟수를 줄이는게 주요

목적인데.. 데이터를 받는게 아닌, 판정및 유효성을 맡기는 것이라.. 게임을 예로 들기엔 이상하단 느낌..OTL)

1.클라측의 ui가 계좌 거래 화면이면.. 일단 서버측에서 계좌정보란 do를 얻어와야 할것이고(로그인등 인증 생략)

.. 이것을 do통채로 전달하냐, dto로 필요정보만 추출하냐, 또는 계좌외 다른 do의 정보도 추가로 필요하냐에 따라 

dto용 데이터를 구성한후..(물론 dao를 통해 얻어온 데이터로) 클라에게 전달하고 클라는 잔고,이체가능액수

기타등등을 뿌려줄것이고

2.클라측에선 해당 계좌 정보를 사용자에게 비쳐주며.. 사용자의 유스케이스(이체,조회,출금...)를 선택받으면..

서버에 이체란 사용자의 커맨드를 전달하고. 서버는 세션빈 + 비지니스를 의미하는 엔티티빈 등을 이용해..

아.. 생각이 막혔다.. 나중에 다시 정리..