2014년 4월 3일 목요일

WPF는 힘들다?



예전에 올렸던 비디오에 댓글이 달린김에 그에 대해서 한마디 더...

댓글 8개:

  1. web programming 에서 쓰는 패턴은 mvc
    wpf / silverlight / windows store app 에서 쓰는 패턴은 mvvm
    blend는 visual studio express 에 포함되어 있으니 당연 공짜로 쓸 수 있고요,
    요새는 wisual studio 내에 winform 정도의 비주얼 편집 기능이 제공되고요,
    blend는 디자이너 수준의 세밀한 편집을 위한 도구로 생각하시면 될 것 같습니다.
    참고하시라고 몇 가지 코멘트를 남깁니다.

    답글삭제
    답글
    1. 감사합니다! 역시 비디오를 대충 만들고(응?) 나면 전문가들이 등장하셔서 좋은 댓글을 달아주시는군요!

      삭제
  2. 오늘은 뭔가 주제가 많군염, 메인은 뭐였죵?

    WPF를 이야기 하고자 한건지 MVVM(Model - View - View Model)을 이야기 하고자 한건지 모르겠지만, 아마도 '익숙하지 않기' 때문이 아닐까 싶네요.

    웹 쪽에서 ERP 계열의 프로그램 작업을 많이 하신 분 이라면 아마도 MVVM 패턴을 써서 프로그래밍 하는게 더 편하고 말하실 듯 하거든요. 실제로 많은 사람이 함께 작업하는 경우에 일을 가로 - 기능단위로 자르는 게 아니라 세로 - 대상단위로 잘라서 여러사람이 나누어 작업하기에 정말 좋거든요.

    예를 들자면 UI 디자이너들 - 프로그래머들 - 데이터베이스 프로그래머들 (쿼리 작업하는 사람들)로 작업군을 나누어서 일을 하는 경우에 각각 한 토막씩 나누어서 일하면 다른 작업군의 진도와 크게 상관없이 제각각 일할 수 있기 때문에 '정말 편한' 패턴일 수도 있다는 거죠

    그분이나 퐆찡이 MVVM이 어렵다고 느끼는건 데이터베이스 작업이 60~70% 정도되는 프로그래밍 일을 할 이유가 없었기 때문일 가능성이 높다고 보니당

    답글삭제
    답글
    1. 맞다, 추가로, 아무리 툴이 좋아도 '루비'가 'C#'을 넘어서기가 어렵다고 생각하는데, 그 이유중 하나는 루비 - 레일즈를 한 쌍으로 봐야 할 만큼 그 둘의 연계가 너무 강하다는 겁니다. 정확하진 않지만 - 벌써 7년전 일이기 때문에 - 레일즈는 MVC 패턴을 제공하는 프레임 워크인데, 루비가 그거 말고는 괜찮다 싶은 라이브러리 셋 이나 프레임워크를 갖고있지 않다는 것이 가장 큰 문제라는 거죠. 루비를 배우고 나서 제일 처음에 했던건 웹 인터페이스를 갖는 MVC 프로그램 이었고, 그 다음엔... 할게 없더라구요

      삭제
    2. https://www.ruby-toolbox.com

      내가 충분히 루비를 사랑해주지 않았기 때문일지도 모르겠네요
      ㅎㅎㅎ

      삭제
    3. WPF가 이래서 안좋았는데 blend써라.. 였자나요... -_-

      삭제
  3. "WPF 가 힘들다?" 는 조금더 정확히 말하면, "XAML 이 힘들다" 인듯 합니다. 저도 처음에 (물론 지금도.) WPF 의 XAML 은 너무 싫어 합니다. 개인적으로 어떤ML 들의 라인수가 한 50 을 넘어 가면 이건 인간이 보라고 만든 문서가 아닌것으로 취급을 해버립니다 (^^; 너무 비약적인가요? )

    그런데 WPF 에서, 내용이 많다 싶은 프로젝트의 XAML을 보면 오른쪽 페이지 스크롤이 손톱만해
    질때 까지 글이 많은데, 여기서 두손 두발 다 들었습니다.
    그래서 한때는 XAML 안쓰고 모든 비주얼들을 코드 레벨로 사용하였습니다. WPF 기나긴 클래스, 멤버,
    이름들 덕분에 아주 코드들이 풍성 해 지는 효과가.. (- -;)

    하지만 이런 말도 안되는 XAML 의 사용성 이면에는 몇몇 장점들이 있습니다.

    1.
    실제로 복잡한 애니메이션 들과 텍스쳐들, GUI 들, 심지어 Shader 까지 ML 로 표현하고 이것을 외부툴 격인 블랜더에서 손쉽게 수정이 가능하고, 자세히 프로젝트안의 소스를 보시면 [*.g.cs] 의 파일 형태로 포팅을 합니다. 다시 말해 XAML 에서 어떤 지랄?^^; 를 하든 본 프로젝트에 그리 크리티컬한 영향을 주진 않습니다.
    또한 책임감도 확실하죠, 안에서 생성안 객체들을 따로 관리 하지 않아도 알아서 메모리 소거 됩니다.
    (물론 약간의 버그도 있는듯 ... ) 한가지 더 붙이면 ML들 이라 잘 활용만 하면 나만의 디자인 환경을 구축하는것 또한 가능 할듯 합니다.

    2.
    두번째의 극 장점은 실시간 확인 입니다. 유니티가 확 뜬이유중에 하나는 (저만의 생각 입니다만)
    실시간으로 빌드된 화면을 확인이 가능하다는 점이 아닐까 합니다. 이것과 유사하게 비주얼 스튜디오의
    WPF 디자인 뷰 에서는 실제 하위 컨트롤들을 미리 빌드 하여 애니메이션, 색상 등등을 실시간 랜더링 해줍니다.
    그래서 구지 [F5] 로 디버깅 하지 않고서도 어느정도 화면의 모습을 예측하는것이 가능합니다.


    하지만 극, 단점도 여럿 존재 하지만 몇가지 꼽으라면

    1.
    앞서 말한 디자인뷰의 장점이 곧 단점 입니다. 이놈들이 생각보다 자주 에러가 납니다.
    그래서 전체 레이아웃 조차 확인을 못할때가 종종 있습니다.

    2.
    IDE 자체가 너무 무거워 집니다. 디자인뷰를 열때마다 자체적으로 빌드 하고 그것을 화면에 보여주니
    양이 많아 질때는 컴퓨터가 매우 힘들어 합니다 ㅎ;;

    3.
    XAML에서 동적인 변경등에서 매우 난감합니다. XAML안에 바인딩, 트리거 이라는 개념을 넣어 놓긴 했는데 제생각엔 그리 직관적이지 않아 보편적인 프로그래머가 볼때 매우 이해하기 힘든점이 있습니다.


    하지만 전 Winform 보다 WPF 가 좋습니다.
    일단 GDI 로 그리는것이 아니기 때문에 HSLS 과 비슷한 픽셀쉐이더도 사용할 수 있고, 사용되는 모든 컨트롤 (버튼, 리스트뷰 등등)도 그래픽적인 처리가 가능하여 다이나믹한 어플리케이션을 만들기 참 좋은듯 합니다.
    무엇보다 생산성이 참 좋습니다.ㅎ ;


    포프님 영상을 이번주 부터 보기 시작해서 정주행 중이긴 한데 보다 보니 WPF 가 있어서 반가운 마음에 첫 리플을 남겨 봅니다 ㅎ;

    답글삭제
    답글
    1. 오오 이리 자세한 장문의 댓글을...! 감사합니다!

      삭제