'ArraryCollection'에 해당되는 글 1건
2009.10.30 10:52
오랫만에 블로그 유입경로를 보다가 코리아몽키라는 분의 블로그를 알게 되었습니다.  [Actionscript 3.0] 간단하게 만들어 본 XML to arrayColection 함수 라는 글에서 제 글을 인용하셨더라구요. ;) 위의 글 말미에 코리아몽키님이 가진 의문이 있으셔서 덧글을 달다가 덧글이 좀 길어질 듯 하여, 간만에 포스팅을 하려고 합니다. ;)

'왜 XML을 Object로 파싱하여 그 데이터를 처리하고 이용하는 방법에 대해서 정리된 자료가 없는 것인가?' 라는 의문은 다른 각도로 접근해봐야 할 것 같습니다. '왜 방법이 없는가'에서 'XML을 Object로 파싱하지 않고 사용할 방법이 있는가?' 라는 것으로 말이죠. 단도직입적으로 말씀드리자면, XML 을 받은 것을 Object 로 변환해야할 필요성이 크지 않다는 것입니다(꼭 필요한 경우도 있겠습니다만). 게다가 XML 그대로 사용하는 것도 가능하고 HTTPService를 이용하면 XML을 Object로 변환 한 결과를 바로 받을 수도 있기 때문입니다.

그럼 먼저 HTTPService 를 이용하여 다양한 형태로 결과를 받는 방법에 대해서 알아보겠습니다.

HTTPService 의 resultFormat
HTTPService에는 resultFormat 이라는 속성이 존재합니다. 이는 HTTP를 호출하여 받은 결과값을 어떤 식으로 파싱할 것인지에 대해서 설정하는 속성인데, 아래의 표와 같이 총 6가지로 설정 가능합니다.

  object   ActionScript의 Object 들의 트리형식으로 XML 을 파싱하여 반환합니다. (기본값)
  array   ActionScript의 Object 들의 트리형식으로 XML 을 파싱하여 반환되나, 최상위의 Object가 Array가 아니라 새로 생성된 Array의 첫 번째 아이템이 됩니다. 만약 makeObjectsBindable 속성이 true로 설정되어 있을 경우 최상위 Array는 ArrayCollection으로 반환됩니다.
  xml   ActionScript 의 XMLNode Object로 이루어진 XML로 XML을 파싱하여 반환합니다.
  flashvars   ActionScript Object로 name과 value가 쌍으로 되어 있는(page=1) 텍스트를 파싱하여 반환합니다.
  text   받은 그대로를 text로 반환합니다.
  e4x   ECMAScript for XML(E4X)를 이용할 수 있는 ActionScript 의 XMLNode Object로 이루어진 XML로 XML을 파싱하여 반환합니다.

resultFormat를 object나 array로 설정하면 Object로 변환된 XML 데이터(서버측이 전달해준)를 전달받게 됩니다. 따로 파싱할 필요가 없는 것이죠. 물론 e4x나 xml로 설정하여  XML로 받아와서 사용할 수도 있습니다. 또는 특정 프로토콜에 의해 생성된 데이터라면 text로 설정하여 String 으로 받은 다음 프로토콜에 맞게 파싱하여 사용할 수도 있을 것입니다. (마치 구분자를 이용하여 소켓통신시 데이터 전달하는 것과 같이)

Object로 파싱하여 사용
rss 구조

rss 구조 (이미지 클릭하여 보세요.)

object로 resultFormat을 설정하여 데이터를 받아오는 예제를 한번 보겠습니다.
본 블로그의 rss를 읽어서 DataGrid에 넣어주는 예제인데, 우선 RSS 정보를 읽기 위해 구조를 먼저 보면 (우측이미지 참조) channel이라는 노드의 하위에 블로그의 정보들(타이틀, 주소, 이미지정보 등)이 있고 포스트의 정보는 item 이라는 노드들에 들어있습니다.

예제에서는 이 item 노드들을 가져다가 DataGrid에 넣어줄 것입니다.




위의 예제에서 resultHandler 메소드를 잠시 보시면 위에서 말한 item 노드들을 찾아서 DataGrid 에 넣어주는 구문을 보실 수 있으십니다. 위의 rss의 트리구조와 같이 Object 로 파싱되어 있기 때문에 동일하게 rss.channel.item 이런 식으로 item 을 읽어오고 있습니다. (하단 이미지 참조)

Object로 받아온 데이터

Object로 받아온 데이터



XML 그대로 사용하기
Flex의 DataGrid, Tree 와 같이 자주 사용하는 컴포넌트의 설계적 특성상 Object 혹은 XML 중 어떤 하나가 더 빠르다는 이야기는 둘째 치고라도 위의 예제같은 경우는 XML을 그대로 사용하시는 것이 오히려 개발 시에는 편할 수도 있습니다. 왜냐하면 resultHandler에 구현된 로직때문인데, resultFormat 속성을 e4x로 설정하여 결과로 받은 XML은 E4X를 사용할 수 있기 때문입니다. E4X에 대한 설명은 생략하도록 하겠습니다. 간단한 E4X에 대한 예제는 여기를 참고하세요.




resultFormat 속성을 e4x로 설정하고, resultHandler 메소드에서 e4x를 사용하여 간단하게 item을 DataGrid에 넣도록 구현하였습니다. 위의 예제와 비교하여 보셔도 크게 다른 것은 느끼지 못하실 것입니다. 오히려 위의 예제에서는 item 노드를 찾기가 훨씬 쉽게 되어있죠.

XML로 받아온 데이터

XML로 받아온 데이터



개발자 마다 스타일에 따라 차이는 있겠습니다만, 저의 경우는 HTTPService를 이용하는 어플의 경우 XML을 기반으로 데이터를 운용하고 있고, RemoteObject의 경우에는 VO를 기준으로 데이터를 운용하고 있습니다. 아무래도 HTTPService를 사용하는 경우는 서버와 주고받는 데이터를 XML기반으로 움직이는 것이 E4X 때문에 무지 편한 느낌이라.. ;^)

다른 분들은 어떻게 데이터를 운용하시는지 저도 궁금하네요. ;^) 트랙백 부탁드립니다.

신고
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.10.30 16:22 신고 | PERMALINK | EDIT/DEL | REPLY
난 이 의견 반댈세
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.10.30 17:07 신고 | PERMALINK | EDIT/DEL | REPLY
외부 서버로부터 받은 데이터를 가공하지 않고 그대로 쓰는 건, 결합도를 높이는 지름길..
(이 주제는 예전에 구글톡에서도 한 번 의견을 나누었던것 같은데.. -_-;)

물론, 테스트용 어플리케이션, 프로토타입 등에선 나도 저런식으로 그냥 E4X로 긁어다 쓰긴 하는데, 딱 그 범위만 넘어서도, 기능이 한두가지만 엮여도, 별도의 객체 구조를 가져가는게 사용하기 편함..

결합도 vs 간편성은 항상 논란의 여지가 많은 부분이긴 한데,
최근 몇 년간의 추세는, 간편성도 매우 중요하지만, 결합도가 우선시되어야, 또는 선행되어야 한다는 쪽 우세하니까..

또 내 경험으로도, XML을 가공하는데 드는 비용은 그리 크지 않은 편이고, 반면에 깨끗한 코드를 유지할 수 있다는 이점은 참 버리기 아까운 부분..
Favicon of http://blog.handkstory.net BlogIcon 제주소년 | 2009.10.31 14:35 신고 | PERMALINK | EDIT/DEL
아.. DB와의 종속성을 없애기 위해 ORM을 사용하는 원리와 비슷한건가요?ㅎ
하긴 외부 서버의 데이터를 바로 사용한다면 결합도가 크게 상승하겠네요..
Flex용 ORM이 나와도 좋을듯.. =ㅅ=ㅋ
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.11.08 06:26 신고 | PERMALINK | EDIT/DEL
예, 비슷한 맥락입니다. :')
내용을 조금 더 보태자면, 결합도 문제는, 일반적으로 일정 기간이 지난 후에야 불거지는 성향이 있어, 개발 시에는 잘 고려하지 않는 부분이기도 합니다.
또한, 개발이 된 후 한참 뒤에야 발견되는 문제이기에, 오히려 심각성이 더 크기도 하지요. 이슈가 될 시점 즈음에는 코드를 잘 알고 있는 사람이 아무도 남아있지 않기 때문에.. ㅎㅎ
Favicon of http://minsangk.com BlogIcon 민상k | 2009.11.01 10:25 신고 | PERMALINK | EDIT/DEL | REPLY
저도 찬익님 의견처럼 결합도 때문에 Object-XML / XML-Object 간 변환 루틴을 힘겹게 만들었던 기억이 납니다.
그러나 결국 만들어보니 xml feeder 가 제 자신이라면 저런 결합도를 위한 노력이 아무 짝에도 쓸모 없음을 깨달았습니다 ㅋ
resultFormat 을 object 로 하는건 생각못했네요. resultFormat="e4x" 에 너무 익숙해져 있었나 봅니다.

좋은 글 잘 읽고 가요.
ps: 얼마전까지도 RSS 에서 찾아 들어오면 올블릿이 바로 떠서 주소를 찍어와야 했는데 오늘은 제대로 글이 뜨네요ㅋ
Favicon of http://blog.flashplatform.kr BlogIcon 검쉰 | 2009.11.08 10:48 신고 | PERMALINK | EDIT/DEL
제 블로그 rss 주소는 http://blog.flashplatform.kr/rss 입니다. 아마 올블릿쪽 rss 을 참조하고 계신듯 하네요 ;)
방문 감사합니다.
최재영 | 2009.11.03 10:04 신고 | PERMALINK | EDIT/DEL | REPLY
결합도가 높아진다는건 이해하기 힘든 부분인데...
어차피 화면 구성은 해당 Application 에 의존적인 부분이고,
재사용 가능한 컴포넌트에서는 ICollectionView 의 사용으로
결합도하곤 상관없는듯...
결론: 그냥 e4x 를 사용한다
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.11.09 03:36 신고 | PERMALINK | EDIT/DEL
재영형 하이 ㅎㅎ
위에 언급한 결합도는 Service Architecture와의 coupling을 얘기한 것임.
예를 들면, RSS 리더라면 ATOM 등의 다른 포맷들도 지원해야하는데, 위 구조로는 추후에 포맷을 추가할 때마다 다소 진통이 있을 듯.
물론 국내의 기업용 어플리케이션들의 경우엔, '클라이언트를 위한 서버'를 개발하는 방식으로 클라이언트/서버 개발을 묶어서 진행되는 경우가 대부분이라 거부감이 없겠지만서도.. 이는 애초에 클라이언트/서버의 결합도를 100%로 놓고 시작하는거니까..

결론 : (아키텍처 상의) 컴포넌트 간 결합도에 대한 얘기였음.
Favicon of http://me2day.pe.kr BlogIcon 이태호 | 2009.11.03 21:06 신고 | PERMALINK | EDIT/DEL | REPLY
우선 뭐.. 저는. 위 최재영님 스타일과 같구요. 단, XML데이터를 별도의 class가 raw한 데이터(xml)를 머금고 있도록 하고, 밖에서는 일종의 factoring을 해다 쓰는 편입니다. 어찌보면 절충안이라고 할 수 있죠. 한마디로 1 xml에 대한 명세를 1 data container class 만 가지고 있게 합니다. 그냥 갠적인 스타일~
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.11.08 10:41 신고 | PERMALINK | EDIT/DEL | REPLY
추가적으로, 코드의 가독성도 문제가 될 수 있다는 생각..
물론 문서화로도 해결 가능하나, 모든 가독성 문제는 문서화로 해결이 가능한 반면, 아무도 문서를 읽으려하지 않으므로..

추후 서비스의 운영/유지/보수 시, 위 RSS 리더의 경우, BlogPost 라는 Class를 두고 파싱하는 경우, 클래스명만으로도 대략의 로직을 이해할 수 있으나, rssData..item과 같은 경우, 해당 로직을 이해하기 위해서는 RSS의 Specification에 대해서도 추가적인 지식이 있어야 함. 물론, RSS는 널리 알려진 포맷이라 많은 개발자들이 내용을 숙지하고 있겠지만, FOAF이나 DOAC이라면 또 다를 것이고, XMPP나 또는 기업 내부에서만 사용하는 데이터 포맷이라면 더욱 그 차이가 심해짐.

단, 유지 비용과는 관계 없이 저럼한 개발 비용을 추구하는 국내 소프트웨어 개발 업계의 실정에는 본 답글 내용이 맞지 않을 수는 있다는 의견..
Favicon of http://blog.flashplatform.kr BlogIcon 검쉰 | 2009.11.08 10:46 신고 | PERMALINK | EDIT/DEL
코드의 가독성의 문제에 대해서는 동의.
위의 RSS spec 을 숙지한 경우에는 상관 없겠으나 spec 을 모르는 상태에서의 저 코드는 대략난감이겠군.
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.11.09 04:15 신고 | PERMALINK | EDIT/DEL
흠.. 난 결합도 문제가 더 큰 문제라고 생각하는데..
최재영 | 2009.11.09 08:58 신고 | PERMALINK | EDIT/DEL | REPLY
음.. 방금도 대화했지만
이미 사용데이터는 Collection류로 추상화되어 있는데다,
서버(혹은 데이터)와의 coupling point 는
소스 데이터의 변화가 있는 경우 어차피 다시 작성되어야 함.
VO 가 있는 경우 소스데이터가 변하면 VO 도 수정해야하고..
(가독성 차원에서는 잘 생각해봐야 함. 어느 쪽이 비용이 더 적은지)
coupling point 에서의 추상화 레벨이 높아질수록,
코드 복잡도가 증가할 수록 쓸데없는 버그발생률만 높이게 되는 듯...
차라리 다른 곳에서의 재사용성을 높이는게
훨씬 더 이득이라는 생각...
(결합도 낮추기는 재사용성을 위해서 생각한거 맞지?)
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.11.15 17:01 신고 | PERMALINK | EDIT/DEL | REPLY
음.. 역시 방금 다시 대화했지만.. (메신저가 편리하긴 편리한 듯.. 로그 정리가 안되는게 흠이지만)

재사용성하고 일부 겹치는 부분이긴 한데, 일단 결합도는 Flexibility를 염두에 두고 이야기 한 것..
아직은 실력이 부족으로.. 재사용성의 이점을 누리진 못하고 있어서..

개발 단계, 또는 운영 단계에서 기능의 추가/수정이 빈번히 일어나는 경우,
코드의 깨끗함을 유지한 채 지속적으로 기능을 추가할 수 있는 구조..라면
아무래도 VO 쪽에 조금 더 점수를 줄 수 있을 것 같다는 생각.

또, 역시 메신저에서 이야기 했듯이, 하나의 예로,
외부에서 가져온 한 가지 데이터를 다수의 Visual Component에서 사용하는 경우,
만약 특정 데이터의 노드명이 변했다면 (ex. pubDate->publishDate)
데이터를 그대로 가져와서 쓰는 경우, 모든 Visual Component에서 해당 값을 바꿔줘야 하지만,
VO는 파서에서 단 한 번만 수정해주면 되니..

코드 복잡도 문제는 나중에 다시 토론..
Favicon of http://vulcan9.tistory.com BlogIcon vulcan | 2009.12.05 17:15 신고 | PERMALINK | EDIT/DEL | REPLY
저두 걘적으로다가 [외부데이터-VO 클래스] 이렇게 항상 짝으로 사용합니다. 외부데이터를 파싱해서 적절하게 변형시켜주눈 Adapter 역할을 VO 클래스에 맡기는거죠. 아직까지는 데이터가 변하더라도 Vo클래스 밖으로 변경사항이 전파되는 일은 없었던거 같네요. 홍수났을때 물길 막아주는 칸막이 역할 - VO에 한표!
카시우스 | 2010.02.03 17:49 신고 | PERMALINK | EDIT/DEL | REPLY
글잘보고있습니다 ㅋㅋㅋ 근데너무어려움... ㅠㅠ 회사괜히와써.....나에게너무많은걸바래 ㅠㅠ
marie | 2011.11.23 11:24 신고 | PERMALINK | EDIT/DEL | REPLY
flex로 .. 검색해서 블로그들왔는데 잘봤습니당~ 10%정도 알아 들었나?ㅠ _ㅠ 어려워요 엉엉 ㅠㅠ
gottdanken | 2014.11.18 18:00 | PERMALINK | EDIT/DEL | REPLY
관리자의 승인을 기다리고 있는 댓글입니다
- 덧글 좀..(굽신굽신) : 장문의 덧글은 트랙백을 이용해주세요 ;^)
Name
Password
Homepage
Secret
prev"" #1 next

티스토리 툴바