달력

102018  이전 다음

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  


최근 고민이 하나 생겼다.

회사에서 기본적으로 VS6.0에서 MFC로 Windows programming을 하는데

언젠가는 갈아타야하지 않나는 생각이 들었다.

최근 프로젝트에서 asp .net 2.0 with c# 환경에서 돌아가는 웹어플을 하나 만들었는데

이 때 사용한 툴은 vs2005이다.

유저의 요구사항의 추세가 인스톨 형태로 프로그램을 깔기는 싫어하고 기존의 리치 클라이언트 수준의 프로그램을 요구하는데 이를 만족할만한 솔루션이 마땅치가 않다.

Smart Client도 있고 ActiveX도 있고 여러가지 방법이 있겠지만 호환이니. 망해가는 솔루션이니 해서 손대기도 두렵고...

유저마다 웹에서 되게 해달라 그냥 어플로 되게 해달라 요구사항도 계속 바뀔지도 모르고..

결국 Windows Programming의 내용을 그대로 Web Programming 형태로 가져갈 수 있으면

가장 좋은 것인데...

코어 부분을 모듈화 하고 GUI(어플이든 웹이든) 파트는 따로 가져가는게 현재로썬 현명한 선택인것 같다.

기왕 하는거 c#으로 .net 환경에서 돌리면 나중에 좋지 않을까 생각도 들긴하지만..

c#이넘 그리 시원치 않은거 같기도 하고...

결국 코어는 c나 c++로 만들고 껍대기는 MFC로 꾸미고.. 다른 환경으로 바뀌면 그에 맞는

껍대기 부분을 따로 코딩하던지.. 해야될것 같다.

근데 GUI는 이 GUI 꾸미는게 엄청난 노가다인데...

ActiveX로 런처 만들고 윈어플 형태로 클라이언트 다운로드 하게 하는게 과연 좋은 선택인가?

앞으로를 봐도??

MFC를 하는데 굳이 vs6.0에서 vs2005로 옮겨타야 하는 이유가 있을까?

Windows 계열의 모든 OS에서 다 돌아가게 하는게 목적이라면 옮겨타야하나?

하여간 M$ 이넘들은 자꾸 새로운거 내놔서 사람 골치만 아프게 하니..원!!!
Posted by 알이씨

티스토리 툴바