Joinc Wiki: 웹서비스 패턴 구조 : bus

Facebook Joinc 그룹 Joinc QA 사이트

현재위치 : 미니사이트>Web>Dev_framework>bus_pattern

joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.

음 글쎄요. 아주 간단한 패턴이라서, pattern이라는 이름을 붙이기가 좀 뭐하긴 하지만 굳이 bus라는 이름을 붙이기로 했습니다. 이름하여 bus pattern.

누구나 알만한 구조에, 이름을 붙인 이유는 기억해내기 쉽고, 다른 사람과 아이디어를 공유하기가 수월할 것 같아서 때문입니다. 이름이 하는 역할이기도 하구요. 그리고 있어보이기도 하잖아요 ?

유래

이 패턴을 체계적으로 정리해보려고 생각하게 된건, moniwiki를 다루면서 부터입니다. moniwiki는 지금의 대다수의 wiki구현들이 그러하듯이, 모듈적재방식의 개발환경을 제공하고 있습니다.

moniwiki의 모듈을 개발하면서, 이러한 개발방식을 잘 체계화하면, 매우 훌륭한 웹서비스 개발환경을 만들 수 있을 거라고 생각했습니다. 거기에, 웹서비스쪽을 보아하니 MVC모델이라는게 있더군요. 있더군요 ? 그걸 이제야 알았냐고 하신다면, 사실 그렇습니다. MVC가 아마도 사용자 애플리케이션제작에서 모델과 뷰를 분리시키기 위한 개발방법론인걸로 알고 있는데, 사용자 애플리케이션을 만들어 본 경험이 전혀 없었거든요. 웹서비스에도 꽤 오래전부터 적용되어 왔었지만, 웹은 지금있는 joinc 사이트를 유지하는 정도로만 해왔으니, 역시 MVC를 이해할 필요도 없었구요.

해서, 대충 MVC 모델을 훑어보게 되어고, 이왕이면 (비록 완전하지는 못하다고는 하더라도) MVC모델을 따르도록 해봐야 겠다라고 생각하게 되었습니다.

bus 구조

bus 구조는 이미 잘 알려져 있습니다. 주로 computer 하드웨어에서, 하드웨어를 구성하는 각종 기기를 연결시키기 위한 구조로 사용됩니다. 각종 기기가 선로에 메달리는 구조가 'bus손잡이 구조와 비슷하다고 해서, bus구조라고 이름짓게 되었습니다. 이 선로는 데이터 흐름의 경로가 될겁니다. 이제, 필요한 기기들을 bus구조에 메달리게 하는 정도로 하드웨어와 결합을 시킬 수가 있됩니다. 기기들의 컴포넌트화를 이루게 되는 거죠.

bus방식은 많은 기기들이 붙을 경우, 한정된 선로에 많은 데이터가 흐름으로써, 병목현상이 나타난 다는 문제를 가지게 됩니다. 하지만 그럼에도 불구하고, 기기의 컴포넌트화가 용이하기 때문에, 지금까지도 주요한 컴퓨터 하드웨어 구조로 사용되고 있습니다. 마땅한 다른대안이 있는지는 하드웨어 전문가가 아니라서 잘은 모르겠습니다.

웹서비스에서의 버스 구조

애초에 bus가 컴포넌트화 - 모듈화 -를 잘 지원하는 구조이다 보니, moniwiki와 같은 모듈기반의 웹서비스 개발환경을 만드는데에도 유용한 구조가 될 수 있을 거라고 생각했습니다. 게다가 물리적인 선로를 이동해야 하는 하드웨어와는 달리, 소프트웨어에서는 물리적간격이 존재하지 않기 때문에, 병목현상을 최소화할 수 있다는 장점도 덤으로 가지고 있습니다. PHP5 이상이라면, 레퍼런스를 사용할 수도 있죠. 일단 다음과 같은 구조를 가지는 개발환경을 만들기로 했습니다.

bus구조를 만들어서 모듈이 달라붙게 만든거죠. 2개의 선로를 준비했는데, 하나는 전역 데이터가 흘러갈 선로이고 다른 하나는 각 모듈과 클라이언트가 생성한 데이터가 흘러갈 선로입니다.

이제 이들 선로를 제어할 수 있는 controller가 필요하게 되겠죠. 그래서 controller를 만들어서 붙였습니다.

거기에 MVC모델을 적용한다고 했던 기억이 나는군요. C는 이미 구현이 되어있습니다. controller가 있으니까요. 이 controller는 C가 하는 데이터의 입출력제어 역할을 하게 됩니다. 데이터를 module로 전달하고, model과 view의 리턴값을 받아서, 다른 model로 넘기거나 클라이언트에게 보내는게 주 역할입니다. 이렇게 하고 보니, MV까지 구현이 되는군요. 전체적으로 MVC 모델이 완성이 되었습니다. V를 완전하게 구현하기 위해서는 템플릿을 쓰네 XSLT를 쓰네 하는등의 이슈가 있지만, 모양새는 갖추게 되었습니다.

이론상으로 볼적에, 이 bus구조를 따르도록 환경을 만든다면, 완전한 컴포넌트기반의 웹서비스 개발 환경을 충분히 만들 수 있을 지도 모른다는 생각을 할 수도 있겠죠 ? 구조는 그럴듯 하니까요 !?

DMF 프로젝트

그래서, 이걸 현실화 하기 위해서 PHP기반의 프레임워크를 하나 만들어 보기로 했습니다. 흠.. 이미 만들어진 다른 웹 개발 프레임워크를 경험해보지 않은 상태에서 왠지 허접스러운 결과물이 나오지 않을까 하는 걱정이 들긴하더군요. 그럼에도 불구하고, 잠시 재미를 주는 정도는 되겠지라는 생각과 실패도 도움이 될 것이다라는 생각, 만들다 보면 다른 프레임워크들도 보게 되겠지라는 안일한 생각하에 일단 진행해보기로 했습니다.

얼추 뼈대는 만든것 같고, 이제 ajax 라이브러리 주워다가 대충 붙이고, 전체적으로 다음으면 뭔가 나올것 같다는 안일한 생각이 듭니다.

프로젝트 홈페이지는 [http]

여기입니다. 괜찮할것 같은가요 ? 프로젝트 홈페이지는 물론 DMF기반하에서 만들어지고 있습니다.

Cache Error

뇌자극 QA 뇌자극 에러 및 수정목록 총 페이지 수 : 3224 전체 함수/용어사전 구글검색방법 구글 맞춤검색	Facebook Joinc 그룹 Joinc QA 사이트 현재위치 : 미니사이트>Web>Dev_framework>bus_pattern Tweet joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다. 음 글쎄요. 아주 간단한 패턴이라서, pattern이라는 이름을 붙이기가 좀 뭐하긴 하지만 굳이 bus라는 이름을 붙이기로 했습니다. 이름하여 bus pattern. 누구나 알만한 구조에, 이름을 붙인 이유는 기억해내기 쉽고, 다른 사람과 아이디어를 공유하기가 수월할 것 같아서 때문입니다. 이름이 하는 역할이기도 하구요. 그리고 있어보이기도 하잖아요 ? 유래 이 패턴을 체계적으로 정리해보려고 생각하게 된건, moniwiki를 다루면서 부터입니다. moniwiki는 지금의 대다수의 wiki구현들이 그러하듯이, 모듈적재방식의 개발환경을 제공하고 있습니다. moniwiki의 모듈을 개발하면서, 이러한 개발방식을 잘 체계화하면, 매우 훌륭한 웹서비스 개발환경을 만들 수 있을 거라고 생각했습니다. 거기에, 웹서비스쪽을 보아하니 MVC모델이라는게 있더군요. 있더군요 ? 그걸 이제야 알았냐고 하신다면, 사실 그렇습니다. MVC가 아마도 사용자 애플리케이션제작에서 모델과 뷰를 분리시키기 위한 개발방법론인걸로 알고 있는데, 사용자 애플리케이션을 만들어 본 경험이 전혀 없었거든요. 웹서비스에도 꽤 오래전부터 적용되어 왔었지만, 웹은 지금있는 joinc 사이트를 유지하는 정도로만 해왔으니, 역시 MVC를 이해할 필요도 없었구요. 해서, 대충 MVC 모델을 훑어보게 되어고, 이왕이면 (비록 완전하지는 못하다고는 하더라도) MVC모델을 따르도록 해봐야 겠다라고 생각하게 되었습니다. bus 구조 bus 구조는 이미 잘 알려져 있습니다. 주로 computer 하드웨어에서, 하드웨어를 구성하는 각종 기기를 연결시키기 위한 구조로 사용됩니다. 각종 기기가 선로에 메달리는 구조가 'bus손잡이 구조와 비슷하다고 해서, bus구조라고 이름짓게 되었습니다. 이 선로는 데이터 흐름의 경로가 될겁니다. 이제, 필요한 기기들을 bus구조에 메달리게 하는 정도로 하드웨어와 결합을 시킬 수가 있됩니다. 기기들의 컴포넌트화를 이루게 되는 거죠. bus방식은 많은 기기들이 붙을 경우, 한정된 선로에 많은 데이터가 흐름으로써, 병목현상이 나타난 다는 문제를 가지게 됩니다. 하지만 그럼에도 불구하고, 기기의 컴포넌트화가 용이하기 때문에, 지금까지도 주요한 컴퓨터 하드웨어 구조로 사용되고 있습니다. 마땅한 다른대안이 있는지는 하드웨어 전문가가 아니라서 잘은 모르겠습니다. 웹서비스에서의 버스 구조 애초에 bus가 컴포넌트화 - 모듈화 -를 잘 지원하는 구조이다 보니, moniwiki와 같은 모듈기반의 웹서비스 개발환경을 만드는데에도 유용한 구조가 될 수 있을 거라고 생각했습니다. 게다가 물리적인 선로를 이동해야 하는 하드웨어와는 달리, 소프트웨어에서는 물리적간격이 존재하지 않기 때문에, 병목현상을 최소화할 수 있다는 장점도 덤으로 가지고 있습니다. PHP5 이상이라면, 레퍼런스를 사용할 수도 있죠. 일단 다음과 같은 구조를 가지는 개발환경을 만들기로 했습니다. bus구조를 만들어서 모듈이 달라붙게 만든거죠. 2개의 선로를 준비했는데, 하나는 전역 데이터가 흘러갈 선로이고 다른 하나는 각 모듈과 클라이언트가 생성한 데이터가 흘러갈 선로입니다. 이제 이들 선로를 제어할 수 있는 controller가 필요하게 되겠죠. 그래서 controller를 만들어서 붙였습니다. 거기에 MVC모델을 적용한다고 했던 기억이 나는군요. C는 이미 구현이 되어있습니다. controller가 있으니까요. 이 controller는 C가 하는 데이터의 입출력제어 역할을 하게 됩니다. 데이터를 module로 전달하고, model과 view의 리턴값을 받아서, 다른 model로 넘기거나 클라이언트에게 보내는게 주 역할입니다. 이렇게 하고 보니, MV까지 구현이 되는군요. 전체적으로 MVC 모델이 완성이 되었습니다. V를 완전하게 구현하기 위해서는 템플릿을 쓰네 XSLT를 쓰네 하는등의 이슈가 있지만, 모양새는 갖추게 되었습니다. 이론상으로 볼적에, 이 bus구조를 따르도록 환경을 만든다면, 완전한 컴포넌트기반의 웹서비스 개발 환경을 충분히 만들 수 있을 지도 모른다는 생각을 할 수도 있겠죠 ? 구조는 그럴듯 하니까요 !? DMF 프로젝트 그래서, 이걸 현실화 하기 위해서 PHP기반의 프레임워크를 하나 만들어 보기로 했습니다. 흠.. 이미 만들어진 다른 웹 개발 프레임워크를 경험해보지 않은 상태에서 왠지 허접스러운 결과물이 나오지 않을까 하는 걱정이 들긴하더군요. 그럼에도 불구하고, 잠시 재미를 주는 정도는 되겠지라는 생각과 실패도 도움이 될 것이다라는 생각, 만들다 보면 다른 프레임워크들도 보게 되겠지라는 안일한 생각하에 일단 진행해보기로 했습니다. 얼추 뼈대는 만든것 같고, 이제 ajax 라이브러리 주워다가 대충 붙이고, 전체적으로 다음으면 뭔가 나올것 같다는 안일한 생각이 듭니다. 프로젝트 홈페이지는 여기입니다. 괜찮할것 같은가요 ? 프로젝트 홈페이지는 물론 DMF기반하에서 만들어지고 있습니다. Cache Error