WPF를 사용하여 WinForms를 구현합니까?

Question

이 질문은 동료와 점심 시간에 대화 한 결과입니다 ... WPF vs. Winforms과 같은 질문을 읽었으며 개인적으로는 이라는 장기간 WPF가 최선의 방법이라고 생각합니다. 문제/질문은 그동안해야 할 일입니다.

예, WPF에는 장점이 있습니다. GDI/USER를 기반으로하지 않는 것은 그 중 하나입니다. 그러나이 시점 (2009 년 말, VS2008 또는 심지어 VS2005 사용, 최근 출시 된 Silverlight3 및 아직 광범위하게 채택/배포되지 않음)에서 WPF는 거의 "설계 초과"솔루션 인 것처럼 보입니다. 그것이 시간에 따라 변할 것이라고 확신하지만, 오늘은 더 쉽지 않으며, 즉각적으로 (즉, < 36 개월) 미래도 없습니다.

하자면, WinForms는 이고 실제로는 간단하고 쉽습니다. 특히 MFC를 "행복하게"사용하는 많은 동료들에게 특히 그렇습니다. 그렇습니다. 매끈한 애니메이션, 3D 그래픽, 그라데이션 등을하기가 어려울 수 있습니다. 많은 사람들 (즉, C++/MFC 개발자)이 을 쉽게 이해할 수있는 매우 실용적인 해결책입니다.

그 longish 소개 - 아무도 생각/피곤/등. WPF (즉, WinForms sans GDI/USER)를 사용하여 (대부분의) WinForms을 구현할 생각인가? 나는 Control.Handle 같은 것을 주겠지 만, 100 % 다시 구현할 수는 없습니다. 그러나 많은 WinForms 컨트롤이 WPF "under the hood"를 사용하여 다시 구현 될 수있는 것처럼 보입니다. 아니면 정말로 경계선이 불가능합니까? "다시 구현"나는 내 응용 프로그램을 재 구축 (말) Microsoft.Wpf.WinForms 다음으로 대체 System.Windows.Forms에 어셈블리 참조를 제거하는 구상으로

. 그 후 필자는 비교적 적은 수의 컴파일러 및/또는 런타임 오류 (P/Win32 API 호출)를 고칠 것으로 예상됩니다.

이와 비슷한 것은 WindowsFormsHost과 같은 Microsoft의 다양한 WinForms/WPF interop 전략에 대한 좋은 보완책처럼 보입니다. 예를 들어, 개발자는 훨씬 더 점진적인 방식으로 WPF를 사용/익히기 시작할 수 있습니다.

편집 : 다양한 "왜?" 토론은 흥미 롭습니다. 그들은 기본적인 기술적 인 질문에 대답하지 않습니다 : "그렇습니다.

Answer 1

솔직히 말해서 대부분의 WinForms를 WPF로 이식 할 수있는 레이어를 구현할 수 있다고 생각합니다.하지만 그렇게해서는 안됩니다. 유추를 사용하겠습니다. WinForms에서 WPF로 이동하는 것은 명령형 언어에서 객체 지향형으로 이동하는 것과 같습니다 (또는 객체 지향에서 순수한 기능으로 이동하는 것과 같습니다). 정말 어렵습니다. 아무 것도 제대로 작동하지 않는 것 같습니다. 해결책은 이해가되지 않습니다. 모든 것이 과도하게 설계된 것 같고 ... 당신은 으로 가져옵니다. 통찰력이 뛰어나고 전구가 계속 켜져 있고 WinForms보다 작업이 더 쉽고 유지 보수가 쉬운 완전히 새로운 세상을 볼 수 있습니다.

하지만 먼저 그것을 grok해야합니다. WPF에서 WinForms 스타일로 코딩을 유지하는 것은 정말 쉽기 때문에 자신을 강요하거나 다음 단계를 밟지 않아야합니다. 깨끗한 슬레이트에서 시작하여 MVVM을 적용하는 방법을 익히고 Prism을 살펴보고 몇 가지 간단한 앱을 만든 다음 WPF 방식의 복잡성을 관리하는 방법을 탐구하도록 강요하십시오. WPF에서 WinForms를 구현할 수도 있지만 WPF에서 WinForms를 코딩하는 사람들 만있을 것입니다. 기본적으로 모든 클래스를 모든 정적 메서드로 단일 클래스로 만드는 (명령형 -> OO 일) 것과 동일한 결과를 얻습니다. 당신은 WPF를 "사용"하고 있을지도 모르지만, 당신 (그리고/또는 당신의 동료)은 그 단계를 지나서 결코 성장할 수 없을 것입니다.

귀하의 상황에서 무엇을 수집 할 수 있는지 알려 드리겠습니다. 아니요, 작은 팀원으로 새 응용 프로그램을 작성하지 않는 한 WPF로 전환 해보십시오. 그렇게되면 결국 작은 팀이 변화의 핵이 될 수 있습니다. 조직의 한 사람이 전구를 가져 오면 전구가 그 곳을 돌아 다니기 시작할 때까지 다른 사람들에게 가르 칠 것이기 때문입니다. 그것이 우리가 현재 조직에서 한 일이며, 지난 6 개월 동안 모든 사람들이 진행 한 진전 상황을 되돌아 보면 엄청난 것입니다. 동료에 대한

Answer 2

WindowsFormsHost이라고하는 것은 초기에 움직이는 컨트롤을 도와 줄 수 있습니다. 그러나, 나는 그것이 꽤 느린 것으로 나타났습니다. WPF를 배우고 처음부터 모든 것을 작성하고 기능, 특히 데이터 바인딩을 활용하는 시간을 보내는 것이 훨씬 낫습니다!

Answer 3

우선, WPF는 "over engineered"가 아닙니다. 복잡한 구성, 풍부한 데이터 바인딩, 2D 및 3D를 단일 플랫폼에서 지원하는 UI 프레임 워크를 구현하는 것은 매우 복잡한 노력이기 때문에 완벽하게 설계된 것이라고 말할 수 있습니다.

WPF는 약간의 학습 곡선이 있지만 매우 가파르 지 않으며 단계적으로 발생합니다. 그것으로 2 일을주고, 당신은 결코 되돌아 보지 않을 것입니다. WinForms는 쉬운 일을하기 쉽습니다. WPF는 무엇이든 쉽다. 광범위한 구성 가능성과 데이터 바인딩을 통해 얻을 수있는 기능은 WinForms를 가장 기본적인 앱보다 더 복잡한 것으로 수치스럽게 만들 것이다.

WinForms 컨트롤이 다시 구현되면 ... 필요가 거의 없습니다. WinForms 컨트롤의 UI를 사용자 지정하는 것이 얼마나 어려울 까 때문에 제 3자가 사용할 수있는 매우 복잡한 WinForms 컨트롤이 많이 필요합니다.WPF를 사용하면 모든 OOB 컨트롤을 향상시키는 것이 쉽고 거의 무한합니다.

대상 하드웨어가 WPF를 렌더링 할 수없는 경우가 아니면 UI 플랫폼을 선택하는 것이 좋습니다.

Answer 4

저는 여러분의 질문을 이해할 수 없습니다. WPF 라이브러리를 Winforms와 같은 방식으로 사용할 수 있습니다. (XAML이없는 코드에서 모든 것을 어셈블합니다.) 대부분의 일반적인 Winforms 컨트롤에는 직접 WPF 아날로그가 있습니다. .

진짜 질문은 왜하고 싶습니까? WPF 데이터 바인딩 및 템플릿 기술을 사용하면 Winform 응용 프로그램 개발의 많은 어려움을 쉽게 해결할 수 있습니다.

그리고 저는 심지어 시각적 효과에 대해서 말하고 있지도 않습니다. 시각적 효과는 winforms에서 너무 많이 작동하지만 단순히 컬렉션의 임의 항목 목록을 시각화하는 것과 같습니다.

코드 Winforms 스타일의 모든 것을 어셈블하는 경우 디자인 타임 편집 지원을받지 못합니다.

Answer 5

정말 당신이 만드는 응용 프로그램의 수명의 장기적인 관점에서 봐야합니다. WPF는 Windows Forms만큼 성숙하지는 않지만 프로그래머는 디자인 (XAML)과 논리 (C#/VB)를 분리 할 수 ​​있습니다. WPF에서 Windows Forms 스타일로 컨트롤을 만드는 것이 좋을 것이라고는 생각하지 않습니다. 앞으로 XAML에 모든 것을 다시 놓을 것을 상상해보십시오!

실제로 Windows Forms의 컨트롤을 WPF에 가져 오려는 경우 완전히 가능합니다. WindowsFormsIntegration에 대한 참조를 추가하고 코드에 적절한 네임 스페이스를 추가하고 XAML에 WindowsFormsHost 태그를 추가하기 만하면됩니다. 내 의견으로는, 이것을 사용하는 것은 일시적이어야합니다 (잠시 느린 것입니다). 다른 한편, 미래의 프레임 워크는 WPF를 훨씬 더 좋아지게 할 것입니다 (내 생각에 4.0을 가짐).

지금 WPF 학습은 아마도 당신이 할 수있는 최선의 방법 일 것입니다. 자신의 방법을 알고 WPF Toolkit을 사용하여 Windows Forms의 일부 누락 된 컨트롤을 사용하는 것은 Windows Forms와 다른 몇 가지 사항 (컨트롤 사용자 지정 및 데이터 바인딩을 염두에두고 있기 때문에)이 처음에는 약간의 시간이 걸릴 수 있습니다.

Windows Forms를 계속 사용하는 경우 WPF의 새로운 기능을 사용하면 개발 속도가 빨라집니다. 예를 들어 설계 작업을 수행하는 사람들과 디자인과 논리의 분리가 두드러지기 때문에 사람들은 응용 프로그램의 논리 측면에서 작업하게 할 수 있습니다.

Answer 6

비유 :

, 더 나은 자동차 또는 말과 마차

?

1. 자동차는 말과 버그만큼 성숙한 기술이 아닙니다. 말과 버기는 2000 년이 넘은 200 년 전의 자동차입니다.

2. 자동차는 지나치게 설계되고 매우 복잡합니다. 말과 버기는 간단합니다.

3. 세계의 많은 지역 사람들은 자동차 운전 방법을 모르지만 말과 버기에 능숙합니다.

질문 : 그들은 고삐에 의해 제어되도록 우리는 우리의 자동차를 단순화 할 수 있습니다, 건초를 먹고, 수의사 및 캐리지 업체에 의해 수리?

여기에서 요점은 WPF는 매우 성숙한 기술이며, WinForms보다 훨씬 강력하고 사용하기 쉽고 배우기도 어렵지 않다는 점입니다. "국가 드라이브"및 기타 특수한 목적을 제외하고는 선택의 수단이어야합니다.

다른 방법들과 마찬가지로 WinForms와 비슷한 방식으로 WPF를 사용하는 것이 쉽기 때문에 그렇게 배우고 싶다면 큰 학습 곡선이 필요하지 않지만 새로운 방법을 사용하는 것은 낭비입니다. 패러다임.

주 응용 프로그램에서 WPF 구현을 지연해야한다고 동의하지 않습니다. 단일 응용 프로그램에서 WinForms 및 WPF 내용을 혼합하는 것은 매우 쉽고 간단합니다. 나는 뭔가를 만질 필요가있을 때까지 WPF에서 새로운 조각을 만들고 WinForms에서 오래된 조각을 남기는 것이 좋습니다. 기존 응용 프로그램이 기본 C++ 인 경우에도 관리 코드에서 데이터에 쉽게 액세스 할 수있는 한 WPF를 사용하는 것이 여전히 쉽습니다.