현업에서 Winform으로 개발을 할 때,
어떠한 View 패턴을 사용하여 개발하시나요?
물론 프로젝트 상황마다 다르겠지만 주로 MVP패턴을 사용할 것 같은데
MVP도 애매하다 해야 하나 그다지 Winform이랑 맞지 않는 느낌이 들어서요.
2개의 좋아요
WinForm이 말하자면 C#으로 C++ 수준의 데스크탑 어플리케이션을 개발 가능한 저수준 제어가 가능한 네이티브 프레임웍이라 그렇습니다.
저도 C++로 여러 패턴을 생각해 봤는데요.
언어와 프레임웍 레벨에서 양방향 제어가 가능한 애들은 패턴 적용이 힘들다는 결론이 나더라고요.
View Model을 나눠서 개발하더라도 애초부터 아주 쉽게 양방향 접근이 가능하고 제약이 없다보니 되려 어렵더군요.
WinForm도 결국 비슷한 이유로 애매한거죠.
3개의 좋아요
음…질문에 대한 답변이 되는건지 모르겠지만요…
지금 다니는 회사에서는 모든 폼 위에 웹뷰(CefSharp) 올려서
디자인을 웹으로 해주고 있습니다!
3개의 좋아요
메인 폼 위에 블레이저를 올리는 방법도 있는데 아직은 현업에 사용되지 않겠죠?
1개의 좋아요
제가 잘못 이해 하는지 질문은 view 처리 패턴을 물어보는데 웹뷰컨트롤을 올리는것 상관없지 않나요?
윈폼에 경우 아마 90%는 딱히 패턴이랄것이 없을것니다.
일단 binding 개념이 없고
애초에 winform context 에 ViewState가 없잖아요
그래서 일반적인 개발을 하는경우가 많을것니다.
1개의 좋아요
어느관점에서 애매하다고 표현하시는지…
1개의 좋아요
컨트롤과 비즈니스 로직을 분리하고자 하시는 것이 의도라면, Windows Forms 기본형으로는 구현하기 쉽지 않습니다.
제한적이긴 하지만 데이터 바인딩 기능을 토대로 이벤트 핸들러로 처리해야 할 부분을 줄이거나 대체하는 것을 생각해볼 수 있을 것 같고요,
이 글의 내용이 힌트가 되실지 모르겠습니다.
참고로 WPF와 MVVM에서 자주 등장하는 INotifyPropertyChanged 인터페이스는 .NET Framework 2.0때부터 도입된 인터페이스이고, Windows Forms에서도 지원하는 인터페이스입니다.
4개의 좋아요
의존성 주입 적용하여 비즈니스 로직 분리 + 바인딩으로 충분히 가능할거 같네요.
1개의 좋아요