안녕하세요 
WPF를 좋아하고, 또 언젠가 잘해보고 싶은 한 사람입니다.
요즘 포럼에 WPF 글이 많이 올라오는 걸 보며
혼자 괜히 반갑고, 또 설레기도 했어요.
하지만 한편으론,
“나도 해보고 싶은데…”
라는 마음이
“근데 이거 너무 어려워 보이는데…”
로 바뀌는 순간도 있을 것 같아
조금은 가볍게 시작할 수 있는 글을 남겨보려 합니다.
—
WPF, 꼭 그렇게 시작해야 할까?
WPF를 하려면
XAML을 해야 하고,
MVVM을 해야 하고,
ViewModel엔 비즈니스 로직이 있으면 안 되고,
Code-behind는 절대 안 되고,
…그래야 ‘제대로 하는 거’라고들 하죠.
물론 다 좋은 권장이에요.
그런데 이게 ‘소리 없는 압박’처럼 느껴질 때도 있습니다.
사실 처음부터 다 지킬 필요는 없다고 생각해요.
Code-behind 좀 써도 되고, ViewModel이 뭐 하는지 몰라도 괜찮고,
Binding이 안 돼서 헤매는 것도 다 WPF 입문자의 통과의례 같더라고요.
그래도 하나씩 알아가면서,
아 “MVVM이 이래서 좋구나”,
“XAML도 나름 재밌네”
하는 순간이 오면,
그땐 진짜 내가 만든 UI가 살아 있는 느낌이 나기 시작하거든요.
이 글은 그냥,
WPF 시작하려는 누군가에게
“너무 잘하려 하지 않아도 돼요”
라는 말을 해주고 싶어서 썼습니다.
처음은 가볍게,
하지만 오래 갈 수 있게.
같이 해요, WPF.
18개의 좋아요
공감합니다.
3년 정도 시간 들여서 WPF 익숙해진다고 하면,
즐거운 마음으로 접근하실 수 있습니다.
4개의 좋아요
저도 소규모 앱까지 MVVM으로 만드는건 굳이? 라고 생각 합니다.
MVVM이 유지보수 편하자고 하는건데. 소규모앱일 경우 그냥 만들고 그때 그때 필요한거 수정하는것이 더 빠르고 직관적이거든요.
물론 여유가 넘친다면 공부삼아서 또는 나중에 확장될 것을 대비해서 MVVM으로 만들수도 있지만… 그게 아니라면 굳이?
4개의 좋아요
이광석
5
맞습니다.
전 오히려
위에 언급 된 MVVM에 대한 걱정을 하기보단,
- 어떻게 하면 이용자들, 사용자들한테 더 직관적으로 해석시켜줄수있을까? (사내 디자이너가 없을 경우)
- 어떻게 하면 디자이너한테 칭찬받는 결과물을 내놓을 수 있을까? (사내 디자이너가 있을 경우)
- 어떻게 하면 버그안나는 UI를 만들어낼까?
이 3개를 먼저 신경을 쓰고, 그 이후 서비스 데이터를 어떻게 가져올까?
그 이후 여유가 되니 MVVM이란 것을 도입해볼까?
생각을 했으면 합니다.
사용자 입장에서의 완료는 MVVM이 아니라 UI잖아요
6개의 좋아요
최근 WPF 프로그램을 갑자기 만드는 일이 있었는데요.
처음에는 창 하나였다가 필요에 따라 만들다 보니 3개까지 늘었습니다.
근데 갑자기 1번 창에 노출되는 텍스트를 3번 창에서 사용해야 하는 순간이 생기더군요.
근데 습관처럼 MVVM으로 구성을 해두었고 VM은 DI로 주입하는 상황이라 아주 쉽게 해결됐습니다.
마술같은 순간이었죠 
5개의 좋아요
앞으로 N개의 화면이 추가가 될거야
리드개발자도
연구소장도
대표도
심지어 의뢰한 클라이언트 조차도
예측 할 수 없는 범위의 문구…
5개의 좋아요
오 저군요 mvvm 공포증이 있습니다 ㅋㅋㅋㅋ
2개의 좋아요