'2011/10'에 해당되는 글 3건

  1. 2011.10.19 개발 할때의 트레이드오프 (1)
  2. 2011.10.15 ASP.NET MVC3 그리고 Raozr 두번째 이야기 (1)
  3. 2011.10.15 ASP.NET MVC3 그리고 Razor (1)
Think about it.2011.10.19 20:33
시간 복잡도와 공간 복잡도 라는 개념이 있습니다.

프로그램의 알고리즘이 얼마나 시공간적인 최적화가 되었는지 확인 할수 있는 방법입니다. 복잡도가 0에 가까울수록 좋은 알고리즘이지요.

예전에 컴퓨터 사양지 좋지 못할때는 최적의 알고리즘으로 만들어야 했습니다. 물론 지금이라고 대충 만들면 된다는건 아니지만 지금은 어떻게 개발하던 작은 프로그램의 연산 속도는 비슷합니다. codeguru에서 이전에 While문이 빠른지 For문이 빠른지에 대한 아티클이 생각나네요 ^^

현재는 단순한 알고리즘이 문제가 아니라 수많은 자료형, 라이브러리, 프레임웍 사이에서 최적의 조합을 찾는것이 문제입니다.

예를 들면 빠른 응답속도의 웹페이지를 만들때 캐싱을 하냐 안하냐가 엄청난 퍼포먼스 차이를 보여줍니다. 하지만 실시간으로 변하는 데이터를 캐싱 하게 되면 단순히 플랫폼에서 제공되는 캐시로는 처리하기가 어렵습니다. 더군다나 대형 웹 사이트인 경우는 WebFarm 기반이라 캐싱된 데이터의 싱크문제도 있습니다. 이런경우는 캐쉬서버를 별도로 두어서 운영하는데 실시간 데이터의 무결성을 보장하려면 데이터가 변하는 액션이 있을때 마다 캐시데이터도 갱신 해주어야 합니다.

그렇다면 빠른 퍼포먼스를 위해 캐싱을 하기위해 캐쉬서버와 통신하는 코스트를 따진다면 결코 시공간 복잡성이 높아지고 소프트웨어 품질도 나빠집니다.

이런 경우라면 차라리 쿼리튜닝과 적절한 인덱스 설계로 응답속도를 줄일수 있을것 같습니다.

지금까지 수많은 코드를 짜면서 100% 만족하는 코드를 짤수 없었습니다. 항상 이 트레이드 오프가 걸렸기 때문이죠...

iPhone 에서 작성된 글입니다.
Posted by dotnetpower
ASP.NET2011.10.15 00:44
오랜만에 불 붙었습니다.

저는 VB MVP입니다. 하지만 누구 덕분에 ASP.NET은 C#이랑 해야 한다는 어떤 정석(?)이 생겨서 VB로 할수가 없습니다. ㅠㅠ

이전에 MVC에 대해 설명을 했습니다.

저는 정말 아무도 모르는 아니, 누군가는 알겠지만 공유를 안해서 죽어라 삽질하게 만드는 이기적인 개발자들에 대해 감사하고 있습니다.

제 블로그 이전글을 보면 JAVA를 해야 하는 이유에 대한 글이 있습니다.

닷넷이 아닌 자바!!

개방을 하는 시스템을 따라갈 자는 없다고 봅니다. 특히 자바쪽은 오픈소스가 굉장히 많습니다.
물론 닷넷도 오픈소스를 많이 합니다. 하지만 자바에 비하면 아직 애기 수준이죠....

자바의 스프링, 하이버네이트, 아이바티스, 앤트

정말 훌륭합니다. CI도 정말 훌륭한 프러덕이 많습니다. 하지만 닷넷은 요즘은 많아 졌는데, 예전에 정말 없었습니다.

정정 : 이 부분에 있던 내용은 삭제 하였습니다. < 모 회사에 관련된 내용이라서 ^^;>

제가 자바에 대해 해봐야 한다고 한건, 오픈소스가 정말 잘되어 있습니다. 아직도 활발하게 진행이 되고 있으며 EJB를 무너뜨린 Spring은 벌써 3.0 입니다.

닷넷은 spring이랑 ibatis랑 붙이는데 솔직히 셋팅하는데 일주일 걸렸습니다. 그때는 정말 자료가 전혀 없었습니다. 혼자 삽질 하며 겨우 셋팅을 해 보니 구글에서 아무리 찾아도 없던 내용을 제가 등록했습니다. codeproject에 여기에 근데 Part1 밖에 없습니다.

개발자의 가장 큰 단점인 영어가 안되어서... ㅠㅠ 제가 이 아티클을 쓰려고 일주일간 사전찾고 하며 쓴 간단한 part1입니다.

part2를 2년 만에 쓰게될지도 몰라요 ㅋㅋ

나름 MS 패턴앤 프랙티스 문서 많이 보고, 엔터프라이즈 J2EE 라는 책을 보며 최적의 패턴을 찾아서 쓴 내용입니다.

현재 실무에 제가 설계한 내용이 이 방법이고, 작년에 세미나 진행했던 내용도 이 내용입니다. 어흠.....


사실 MVC2 까지는 자바와 비교하기에는 너무 부족해 보였습니다.

뭐가 부족하나요? 라고 하시면 사실 저도 자바를 전문으로 한게 아니라 잘 모르지만, 일단 해 보시면 압니다. 라고 말씀드릴수가 있습니다. 왜냐면 MVP는 MS대변인이 아니기 때문에 분명히 말씀드립니다.

MVC2까지는 이건 뭐지? 라는 생각이였습니다.

하지만 3에서 ViewEngine 인 Razor가 나오면서 상황은 달라졌습니다.
JAVA의 Custom Tag나, JSTL를 접해보신분들은 Razor를 보시면 뭐... 비슷하게 따라했네... 라고 하실수도 있을것 같아요.

그만큰 자바쪽은 이전부터 발달이 되어 있었는데, 닷넷은 MVC3가 되면서 비슷한 느낌이 되었습니다 라고 말씀드릴수가 있습니다.


현재 랭귀지들은 굉장히 발전 되어있습니다.

자바가 1.5를 5.0으로 바꾸면서 타이거 라고 했죠 아마?

3~4년 전에 나온 자바5.0이 제가 보기엔 닷넷 4.0 과 비슷해 보입니다. 아직 닷넷 4.5는 베타입니다.

MS 관계자분들은 얘 뭐하는 놈이야? 라고 할수 있는데, 여긴 제 개인 블로그 입니다.
물론 주관적이긴 하지만 제가 느낀 언어는 그대로 전달할수 있습니다.

자바든 닷넷이든...
좋아하는 언어를 선택하시면 됩니다.

저는 사실 언어를 못합니다. 특히 국어.... 굉장히 어려운것 같습니다.
하지만 JAVA, C#, VB 는 동시통역(?) 할수 있습니다.

그만큼 비슷하다는 이야기 이지요~ ^^;


그러면 제가 왜 MVC3가 좋은지에 대해 설명할 차례인것 같네요.

우선 웹폼 기반 개발하시는 분들이 봤을땐, MVC는 페이지 개념이 없습니다. 예전에 MS에서 자주 PT자료로 내 놓았던것 중 하나가 털남 남자는 디자이너고, 이쁜 여자는 개발자...

상호 협력을 잘할수 있다라는건데.. 국내 뿐만 아니라 해외에서도 개발자와 디자이너 사이에 문제가 좀 있나 봅니다. ㅋㅋ

MVC로 하면 View는 디자이너 또는 퍼블리셔가 주는 html 그대로 사용할수 있습니다.

xxxToolkit 다 버리십시오. 이런거 쓰지 말고, 퍼블리셔가 주는 화면 그대로 사용하면 됩니다.

특히 jQuery와 통합되었기 때문에 jQuery 문법 조금만 알면 스크립트는 금방 합니다.

문제는 한국에선 화면에 출력되는걸 중요시 힙니다. 이건 까칠한!!! 퍼블리셔 몫입니다.
개발자는 요청에 맞는 응답을 잘 처리해 주면됩니다.

그럼 Razor는 왜? 타이틀에 붙어 다니는가?
Razor는 제가 생각하기에 정말 최상의 ViewEngine입니다.

흔히 말하는 골뱅이(@) 하나로 끝납니다. ㅋㅋ

그 예제는 다음에 보여드리겠습니다. :)
Posted by dotnetpower
ASP.NET2011.10.15 00:08

ASP.NET MVC3로 프로젝트를 진행하고 있습니다.
MVC2에서 부족한 부분들을 3에서 많이 채워 주었습니다.

대표적인 예로 View Engine인 Razor 지원이 됩니다.

제가 실용적인 강좌가 많이 없다고 많은 분들께 이야기 하고 다녔습니다. 저 또한 실용적인 강좌를 만들지 못하고 있지만 정말 실무에서 필요한 내용이 무었인지 여러분들과 조금이나마 공유했으면 좋겠다는 생각에 지극히 개인적인(?) 아티클을 남겨 봅니다.

MVC(Model-View-Controller) 는 사실 명명이 잘못되었다고 생각합니다. CMV가 되어야 하는데, MVC죠...

이야기처럼 봐 주세요 ^^;

웹은 요청(Request)가 있어야 응답(Response)을 합니다.

요청을 받는 녀석은 Controller(C) 이죠. 요청을 받으면 요청한 내용을 보여주기 위해서 Model(M)에서 필요한 내용을 꺼냅니다. 그리고 View(V)를 통해서 보여주게 되는것이죠.

그럼 기존 WebForm기반이랑 뭐가 다른가요?

WebForm도 마찬가지입니다. 요청(Request)에 대해 응답(Response)를 하는데, 단지 Page기반의 처리방법이 MVC와 차이가 있는것입니다.

현재 우리 팀원이 자주 질문하는것이 새로운 요청일 경우 Controller를 어떻게 다르게 만들어야 하는지가 궁금한가 봅니다.

Controller는 단지 요청(Request)을 받아들이고 Model을 통해서 어떻게 View에게 보여줄것인가 하는 녀석이니까 작은 Doamin 으로 나눈다면 특정한 Business Logic에 대해서는 하나만 존재 하면 됩니다.

그러면 기존에 웹폼 기반에 수많은 페이지들은 어떻할것인가?

도메인 모델로 구분짓고 적절히 나누면 되는것입니다.
예를 들어 Twitter와 같은 시스템을 설계를 한다고 할때에는 TimeLine을 위한 Controller 하나, 팔로워, 팔로잉을 하는 사람들을 위한 Controller 하나, 그리고 쪽지와 같은 특수한 기능을 하는 기능적인 Controller하나, 마지막으로 설정에 관련된 Controller 하나, 이렇게 4개만 있으면 됩니다.

그럼 이렇게 의문을 가지시는 분들이 있을것 같습니다.
"그럼. 팔로워, 팔로잉 페이지를 따로 만들어야 하는데, 그걸 컨트롤러 하나로 만들면 어떻할껀데? 기존 웹폼은 전부 따로 만들어서 유저컨트롤로 쪼개어서 SP만 따로 호출하면 되는거 아니냐?"

그런분들은 그냥 웹폼으로 열심히 만드십시오. 라고 하겠습니다.

MVC의 장점은 M-V-C를 명확하게 나눌수 있는점입니다.

요즘에 퍼블리셔와 같이 일하지 않습니까? 퍼블리셔가 주는 페이지들은 View 입니다. Controller가 아닙니다.

??????

예... Controller는 요청(Request)을 받기 위한것이지 응답(Response)을 하기 위한것이 아닙니다.
그 페이지들을 View에 만드는겁니다.

그런데!!!
실용적인 강좌에 대해서 제가 서두에 언급을 했습니다. 실용적이란 이런걸 말씀드리는것입니다.

Controller는 도메인 모델에 대해 크게 나누어진것 이고, WebForm에서 MVC로 넘어오시려는 분들이 생각하시는 페이지는 View입니다.


"그래서 어쩌라고?" 하시는 분들...

자...

요청을 받았습니다. 응답을 위해 기존에 흔히 말하는 DAL을 통해서 페이지에 뿌려준다?

MVC에서는 그게 아닙니다.

MVC에서는 Controller로 받은 응답을 요청하기 위해서 View에 필요한 데이터를 Model에 요청해서 뽑아내고
ViewBag, ViewData 에 넣어서 단지 View로 넘겨주기만 하면 됩니다.

그러면 View에서 정말 멋진 Razor로 보여주면 되는것입니다.

뭐... 작업 하시다가 사파리에서 화면이 틀어진다? 망할놈의 IE6에서 깨진다? 그건 고귀한 퍼블리셔님들이 해야 할 몫입니다.

대략 어떤건지 감이 오시나요?

다음 강좌에 계속하겠습니다.



!!! 혹시나 제가 틀린 부분이 있으면 얼마든지 댓글남겨 주십시오. 정보 공유는 올바른 정보공유로 부터 시작이 됩니다.

감사합니다.
Posted by dotnetpower