WPF 개발을 위해 MVVM은 필수일까요?

안녕하세요.

얼마전 C#과 WPF 공부를 시작하여 막 기초를 뗀 학생입니다.
제가 이해한 기초라 함은 XAML이 어떻게 구성되는지, code behind가 뭔지, 이벤트는 어떻게 연결하는지 등과 기본적인 컨트롤을 가지고 놀아보는 정도의 정말로 피상적인 개념들을 공부한 상태입니다.

개발에 있어 가장 좋은 공부법은 막힐 때 마다 필요한 것을 공부하는 top-down 방식이라 생각하여 이제부턴 제가 목표로 했던 앱을 만들며 직접 부딪혀보려합니다.

다만, (반년정도 안에) 최종적으로 이를 상업적인 앱으로 내놓는 것이 목표인 상황입니다. 이런 경우 MVVM 디자인 패턴까지 익히고 개발에 들어가는 것이 좋을까요? 그냥 개인적인 토이 프로젝트 였다면 고민 없이 막 개발 해봤을텐데, 저 혼자하는 것이 아닌 다른 분들(개발자는 아닙니다)과 협업하여 장기 서비스를 목표로 구상한 것이라 나중에 유지보수까지 생각을 하니 고민이 됩니다.

조금 더 시간이 걸리더라도 MVVM을 기반으로 하는 것이 맞을까요?
현업자분들의 고견을 들려주신다면 감사하겠습니다.

1개의 좋아요

기초를시작하시는거면 아예 차라리 mvvm이 아닌 코드비하인드에 때려박는 구식 윈폼스타일로 한번 개발해보시고
그 이후에 WPF의 UI를 공부하신 다음에
그다음으로 MVVM을 공부해보시면

아 이래서 MVVM 해야하는구나를 이해하면서 몸소 체험하실껍니다.

4개의 좋아요

MVVM이 필수는 아닙니다. 그리고 상업용 앱이 WPF여야만 하는 것은 아닙니다. 윈폼으로 해도 되고 아니면 더 최신인 WinUI3로 하셔도 되고요. 지금 배우기 시작하시는 것이라면 상황에 따라서는 윈폼을 선택하는 것은 권장되지 않기는 합니다.

3개의 좋아요

반년이라는 다소 타이트한 기간이 주어졌다면, 빠르게 릴리즈를 해보고 반응을 보겠다인거 같아보입니다. 새로 지식을 습득해서 적용하기보단 알고 있는 지식을 최대한 활용해서 구현을 목표로 하고 앱에 대한 반응이 좋다면 그 때 유지보수를 위한 투자를 하는게 맞다는 개인적인 생각입니다. (하지만 본인이 얼마나 하느냐에 따라 다르겠죠)

유지보수의 용이성을 가져간다는 것은 그만큼 설계에 공을 들인다는 것이고 그에 따라 학습과 패턴을 준수하기 위한 노력을 하기 때문에 개발 속도도 늦춰질 수밖에 없을거라 생각됩니다.

3개의 좋아요

MVVM이 상당한 러닝 커브가 따르기 때문에 어려운 점이 있긴 하지만, CommunityToolkit 등을 이용해서 사용법을 익히고 난 후에는 확실한 장점이 생깁니다. 다만 충분히 집중해서 살펴보고 연구할 만한 여유가 있어야 추천을 드립니다.

그렇지 않고 다른 분들과 함께 MVVM을 사용할 수 있는 분위기 조성이 어려울 경우 코드 비하인드 방식으로 목적지에 빠르게 도착하는데 일단은 집중하시되, MVVM 기반의 아키텍처에 대한 내용을 팀 내에 전파할 수 있는 방법에 대해서 따로 분리해서 다룰 필요가 있지 않나 생각합니다.

참고로 Windows Forms (.NET 8.0 이상) 역시 최근에는 ICommand 같은 인터페이스를 직접 바인딩하는 기능이 추가되어, WPF 수준은 아니지만 Windows Forms와 WPF가 뷰 모델을 공유하는 시나리오도 가능해졌습니다.

3개의 좋아요

@디노티아 @rkttu @밀수나라 @helpandplay
조언해주신대로 일단 먼저 코드비하인드 방식으로 빠르게 개발한 후에, 추후 추가적인 코스트가 발생하더라도 필요시 MVVM으로 전환하는 방식을 택하려합니다. 친절한 답변 모두 감사드립니다!

2개의 좋아요

상업적인 서비스를 염두해 두신다면, MVVM 이 아니라 M에 집중하시기를 권해드립니다.

WPF는 윈도우 전용 프레임워크입니다.
이 프레임워크가 요구하는, 그것도 선택적으로 요구하는 패턴 기법을 추구하는 것은 들어가는 정성에 비해 외연의 확장에는 아쉬운 측면이 있습니다.

닷넷은 현대 상업 서비스가 요구하는 거의 모든 워크로드를 지원한다고 할 수 있습니다. 이 모두를 관통하는 것은 M 입니다.

이 포럼에는 윈폼 => WPF 로의 마이그레이션에 어려움을 토로하는 글들이 심심치 않게 올라 옵니다.

그 원인은 부실한 M일 확률이 높습니다.
M이 부실하면, WPF 를 다른 워크로드로 마이그레이션할 때 동일한 어려움을 겪을 것입니다.

M을 제대로 설계하는 것은 지금까지 배운 OOP의 모든 기술을 다 투사하는 것입니다.
이 것을 잘 해내는 것은 OOP 개발자의 평생 숙제와도 같습니다.

제대로 설계된 M은 MVVM, MVC, MVP 등 M을 요구하는 어떠한 디자인 패턴에도 아무런 코드 수정없이 즉시 채택될 수 있습니다.

부실한 M의 특징을 간단히 나열하자면,

  • 데이터 베이스의 데이터 모델과 거의 일치
  • 불변 객체 추상화에 등한 시
  • public set 의 남발
  • 불완전 생성의 용인
  • 기본 자료형 속성만 수두룩
  • BCL 이 아닌 외부 모듈에 의존

등등입니다.

마지막으로, 협업을 고려한다면, 시스템의 요소들은 폴더가 아닌 프로젝트 단위로 구분하는 것이 좋습니다.

모델은 당연하고, 특히 아래와 같이 인터페이스 소비자와 인터페이스를 동일 모듈에 두는 우를 범하면 안됩니다.

public interface IWorker;
class WorkerClient(IWorker worker) { }
3개의 좋아요

현실적인 조언 감사드립니다. 초보로써 전혀 생각지 못했던 관점입니다. 많은 도움이 되었습니다.

2개의 좋아요