@javax.persistence.Entity @javax.persistence.Table(name = "game") @org.msgpack.annotation.Message public class Game implements Serializable { private static final long serialVersionUID = -6305522860872314804L; // 채널 아이디 (패킷에서 제외) @javax.persistence.Id @org.msgpack.annotation.Ignore public String channelId = ""; // 이름 (패킷에서 제외) @org.msgpack.annotation.Ignore public String nickName = ""; // 마켓 (패킷에서 제외) @org.msgpack.annotation.Ignore public int marketId = 0; // 푸쉬 아이디 (패킷에서 제외) @org.msgpack.annotation.Ignore public String pushId = ""; // 로그인 블록 상태 public int loginBlock = 0; // 메시지 블록 상태 public int mailBlock = 0; // 푸쉬 블록 상태 public int pushBlock = 0; // 운영 보상 아이디 public int lastRewardId = 0; (생략) // 쪽지 (MySQL, Couchbase, Redis, 패킷에서 제외) @javax.persistence.Transient @org.msgpack.annotation.Ignore @com.fasterxml.jackson.annotation.JsonIgnore public Mapmails = new HashMap (); public Game() { } }
위와 같이 게임 서버에서 사용 중인 각각의 라이브러리에서 제공하는 Annotation을 Game 클래스에 적절히 적용하면 Game 클래스 하나를 가지고 다양한 용도에 사용이 가능하다.
위의 그림은 현재 진행 중인 프로젝트의 구성도 중 일부이다. 각각의 블록을 잇는 모든 선은 다양한 형태의 데이터로 변환된 동일한 Game 클래스 객체 데이터의 흐름이다. 이와 같은 설계의 가장 큰 장점은 MySQL, Couchbase, Redis와 같은 Persistence 계층과 Game Server와 같은 Controller 계층, 게임 사용자와 같은 Present 계층이 모두 같은 클래스를 공유할 수 있어서 각 계층 간 데이터 전환을 위한 DTO가 필요하지 않아 간결한 코드를 유지할 수 있었다. 예외적으로 GWT로 만들어진 운영툴의 경우 GWT 서버-클라이언트 코드 간에 MySQL에서 읽어들인 Game 클래스 객체 교환이 불가능하기 때문에 (Hibernate가 Game 클래스 객체를 POJO가 아닌 객체로 동적 변경을 하므로 변경된 부분을 클라이언트 Java Script 코드로 생성이 불가능하기 때문에) 반드시 DTO를 생성해야만 했다.
댓글 없음:
댓글 쓰기