WPF 대 WinForms-델파이 프로그래머의 관점?

WPF와 WinForms의 주요 스레드 대부분을 읽었으며 시도한 기술과 진정한 이전 기술 (Winforms) 사이를 결정할 때 발생할 수있는 불행한 분위기에 빠져 있으며 후임자 (WPF)입니다.

나는 수년간 베테랑 델파이 프로그래머이며 마침내 C #으로 뛰어 들었습니다. 필자의 동료 델파이 프로그래머들은 델파이의 Anders Hejlsberg가 C #의 설계 자라는 것을 알게되어 기쁩니다. Delphi의 VCL 사용자 정의 구성 요소, 특히 하위 구성 요소의 컨테이너 역할을하는 다중 단계 마법사 및 구성 요소를 만드는 데 관련된 구성 요소에 중독되었습니다.

그 배경을 바탕으로 델파이에서 C #으로 전환 한 사람들이 초기 응용 프로그램 작성에 대한 WinForms 대 WPF 결정에 도움이되기를 바랍니다. 코딩 및 완전한 자동 완성 및 적절한 디버거 지원과 같은 것들이 API 기능 및 호출에 대한 정보를 쉽게 찾을 수 있고 버그에 대한 해결 방법을 포함하여 프로젝트를 만들거나 깨뜨릴 때 매우 참을성이 있습니다. .

2009 년 초 날짜 범위의 SO 스레드와 의견은 C # UI 개발 코딩을 손상시킬 수있는 잠재적 좌절에 대해 WPF에 대해 큰 우려를줍니다. 반면, API 기술을 배우는 데 많은 시간을 소비하지만, 포기하지 않더라도 곧 교체 될 것 (WinForms)도 똑같이 문제가되며 WPF 무두질에서 GPU 지원을 찾을 수 있습니다.

그러므로 나의 모호함. 어느 기술도 아직 배우지 않았기 때문에 새로운 시작을 할 기회가 거의 없으며 WinForms 프로그래머가 WPF로 전환 할 때 사람들이 다양한 스레드에서 언급 한 큰 "학습"곡선에 직면 할 필요가 없습니다. 반면, WPF를 사용하는 것이 나 자신과 같은 초조 한 RAD 개발자에게 너무 실망 스럽거나 다른 주요 부정적인 결과를 초래한다면 WPF가 같은 수준의 지원과 사용 편의성에 도달 할 때까지 WinForms를 사용합니다. 프로그래머로서의 심리학에 대한 구체적인 예를 들기 위해 VB와 Delphi를 사용하여 많은 개발자들이 초기 Windows 앱을 개발하는 동안 겪었던 Windows UI 라이브러리 인 MFC로 인한 코딩의 실제 고통을 완전히 피했습니다. 나는 MFC를 피하는 내 행운을 결코 후회하지 않았다.

또한 Anders Hejlsberg가 WPF 및 / 또는 WinForms 아키텍처를 담당하고 있는지, 그리고 코드 기반에 구현 된 창의적 비전과 사용 편의성에 차이가 있는지 아는 것도 위안이 될 것입니다. 마지막으로, 델파이 프로그래머들에게 WPF를 사용할 때, 특히 디버거 지원과 관련하여 WPF를 사용할 때 얼마나 "IDE schock"인지 알려주십시오. 2011 년에 업데이트 된 모든 고용 시장 의견도 감사하겠습니다.

델파이 배경이 있다면 WinForms에 실망 할 것입니다. 당신은 VCL에서 쉬운 일을하려고 노력할 것입니다. 그것들은 고통스럽고 어렵거나 불가능하다는 것을 알기 위해서입니다. WPF는 훨씬 덜 제한적입니다.

예를 들어 다음은 우리가 겪은 몇 가지 WinForms 제한 사항입니다.

• WinForms에는 TAction과 비교할만한 것이 없으므로 작업을 코딩하고 메뉴 항목과 도구 모음 단추와 마우스 오른쪽 버튼 메뉴간에 동일한 텍스트와 아이콘을 공유하고 활성화 논리를 중앙 집중화하며 활성화 된 상태를 업데이트하는 데 익숙하다면 OnUpdate와 함께 백그라운드에서 ... 당신은 WinForms를 싫어할 것입니다.
• 윈폼 '오래된 (.NET 1.0 빈티지) MAINMENU 메뉴 항목 옆에 이미지를 지원하지 않으며, MenuStrip (.NET 2.0에서 소개) 새로운입니다 버그 투성이 마이크로 소프트가 수정을 거부 합니다 (버그 수정 이전 버전과의 호환성을 깰 수 있기 때문에).
• TreeView와 같은 많은 컨트롤은 VCL에 비해 성능이 저하되어 있습니다.
• Delphi에서 익숙한 타사 컨트롤 개발자의 활기찬 커뮤니티와 비슷한 것은 없습니다. 거기에는 품질 관리 라이브러리가 있지만 VirtualTreeView와 같은 무료 제품은 WinForms에 없습니다.

WPF는 WinForms보다 약간 더 베어 본이지만 확장 성이 뛰어납니다.

• TAction과 같은 것을 원하십니까? WPF에는 익숙한만큼 풍부한 ICommand가 있지만 Josh Smith의 MVVM 기사 를 읽으십시오. 보통 상태가 변경되면 명령을 수동으로 활성화 / 비활성화해야하지만 그의 버전은 자동으로 활성화 코드를 시작합니다 OnUpdate와 익숙한 배경에서).
• 메뉴에 이미지를 원하십니까? 그것은 내장되어 있으며 WinForms와 같은 버그가 없습니다.
• WinForms는 중요한 컨트롤에 대한 소유자 그리기를 생략하지만 대신 WPF를 사용하는 경우 소유자 그리기 가 필요 하지 않습니다. TreeView 노드에 검은 색 텍스트가 있고 괄호 안에 파란색 숫자가 표시되도록하려면 그것을 DataTemplate에 넣으면 추악한 소유자 그리기 코드가 필요하지 않습니다.
• 타사 컨트롤을 원하십니까? 많은 경우에 WinForms가 존재하는 방식으로 확장 할 수 있고 VCL 개발자가 꿈꾸는 것만으로도 확장 할 수 있기 때문에 필요하지 않습니다.

WPF의 학습 곡선은 매우 가파르지만 좋은 책 (예 : " WPF 4 Unleashed ")을 선택하면 최악의 상황을 극복하는 데 도움이됩니다. WinForms의 방식을 방해하지 않습니다.

나는 사람들이 WPF에 대한 좋은 경험이 없다고 말하는 것에 보통 매우 놀랐습니다. C ++ / MFC에서 C # / WinForms로 C # / WPF로 전환 한 개발자입니다. XAML을 배우는 것이 쉽지는 않지만 WinForms에서 WPF 로의 전환은 쉽지 않았지만 일단 익히면 멋진 기술입니다. 나는 WinForms로 돌아갈 수 없습니다. WPF는 대단합니다.

나를 귀찮게하는 또 다른 것은 사람들이 일반적으로 WPF와 UI 만 연결하는 방법입니다. UI 디자인이 쉽다는 점에서 WinForms보다 100 배 더 낫지 만 WPF를 사용하는 다른 이유는 여러 가지가 있습니다.

1. 물론 UI.
2. 바인딩. 그냥 평범한 마술. UI 다음으로 가장 강력한 기능입니다. LOB 응용 프로그램이 가장 큰 이점을 제공합니다.
3. 명령.
4. 우려의 분리. 디자이너는 디자인, 프로그래머 프로그램에서 일합니다.
5. 첨부 된 속성. 소스 코드없이 타사 컨트롤의 기능을 확장 할 수 있습니다 (이 시점은 첫 번째 포인트의 일부일 수 있음).
6. Silverlight로 쉽게 전환 (웹 및 WP7)

WPF를 배우는 이유로서 마지막 요점에 대해 저에게 동의하지 않을 수도 있지만, 저에게 묻는다면 가장 큰 것 중 하나입니다. WPF를 배우면 Silverlight로 쉽게 전환 할 수 있습니다. Silverlight가 크게 성장하고 있으며 멋진 기술이기도합니다.

그리고 가장 큰 이유는 미래입니다. Silverlight와 병합 될 수 있지만 기술은 동일하게 유지됩니다.

그래서 WPF로 가라고 강력히 권합니다.

분명히 WPF는 미래에 생각하는 길입니다. 마스터하기는 어렵지만 플랫폼은 매우 잘 설계되고 유연합니다.

몇 가지 조언 :

• 쉬운 시작 : MVVM 또는 멋진 애니메이션 만 사용하여 첫 번째 프로젝트를 구현하지 마십시오. 창, 버튼 및 목록으로 간단하게 시작하십시오.
• DataBinding을 활용하십시오.
• Adam Nathan 이 쓴 WPF Unleashed 책을 구입하십시오 .

먼저 winforms를 많이 사용해 왔지만 주로 asp.net 개발자라는 점에 주목해야합니다. WPF 로의 전환은 일주일 정도 (40+ 시간) 후에 (imo) 만드는 것만 큼 크지 않으며, 대부분은 두 번째 자연입니다.

어쨌든 Anders Hejlsberg는 WPF의 건축가 중 하나라고 생각합니다. 적어도이 책의 발행인에 따르면

“ WPF의 설계자 중 한 사람인 Chris Anderson은 '방법'뿐만 아니라 '왜'도 능숙하게 설명합니다. 이 책은 WPF의 디자인 원칙과 모범 사례를 이해하려는 모든 사람에게 훌륭한 자료입니다. – Microsoft Corporation의 기술 담당자 인 Anders Hejlsberg

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Winforms는 Delphi 개발과 거의 동일합니다. 물론 그 이유가 있습니다. 델파이 / 오브젝트 파스칼 오브젝트 모델이 C #에 크게 영향을 준 것처럼 폼 시스템은 Winforms에 영향을 미쳤습니다.

WPF는 사물을 향한 방향으로 보인다. Winforms에 구축 된 이전 세대와 달리 (거대한!) VS2010 UI는 WPF 기반이라고합니다.

안락한 구역에 머 무르려면 winforms를 사용하십시오. 최신의 최고를 따라하고 싶다면 WPF에 빠져보십시오.

델파이 프로그래머는 아니지만 WinForm (대중)과 WPF (중간 이하) 모두에서 일했습니다. 나는 그 상황에 처해있을 때만 WinForm에서 WPF로 전환하려는 사람에게는 좌절 수준에 대해 어느 정도 동의하지만, 익숙해 질 때까지만 동의합니다. WPF가 WinForm과 비교했을 때 얼마나 훌륭하고 융통성이 있는지 알아보십시오. 적어도 Winform이 아닌 Delphi 배경에서 온 사람에게는 큰 학습 곡선이 있습니다. 당신에게는 WinForm 대신 WPF로 나아가는 것이 가치가 있으며 시간 가치가 있습니다.

아래 링크를 살펴보고 시작할 수 있습니다.

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

일부 Windows Forms 작업 (주로 Pocket PC)과 동일한 원칙을 사용하는 .NET 이외의 다른 환경을 수행했습니다. 약 3 년 전에 WPF로 이사했을 때 처음 몇 달 동안 나는 맹세했습니다. 결국 그것은 단지 "클릭"했고 나는 되돌아 보지 않았습니다. 사실 다음 프로젝트에서 Windows Forms로 돌아 가야한다면 불쾌 할 것입니다.

Windows Forms를 마지막으로 업데이트 한 시점은 2005 년 (VS 2005)입니다. 아직까지는 있지만 Microsoft에서는 더 이상 개선하지 않습니다. WPF는 데스크톱 응용 프로그램의 새로운 블록입니다. 따라서 MS 도구를 사용하여 .NET 플랫폼으로 이동하려는 경우 안전한 방법이라고 말할 수 있습니다. 어떤 사람들은 Silverlight를 데스크톱 솔루션으로 사용하지만 가능성으로 보았을 때 너무 많은 한계가 있음을 발견했습니다 (웹 컨텍스트에서는 의미가 있지만 데스크톱에서는 그다지 중요하지 않습니다).

결론 : 가파른 학습 곡선이 있으며 여전히 배우고 있습니다. 그러나 그만한 가치가있었습니다. 많은 재미입니다.

처음부터 새 응용 프로그램을 작성하려는 경우 WinForms를 사용하는 것은 실수입니다. 기본적으로 투자 관점에서 죽었습니다. Microsoft는 오랫동안이를 유지해 왔지만 새로운 기능이나 새로운 지원 등은 얻지 못할 것입니다. WPF는 MS 플랫폼에서 미래를위한 데스크톱 응용 프로그램의 확실한 방향입니다.

경력 관점에서 WPF와 WinForms를 아는 것이 훨씬 좋습니다. 위와 같은 이유로. 또한 Silverlight를 배우는 데 도움이 될 것입니다. 이 두 플랫폼 사이에는 많은 중복이 있습니다.

마지막으로 WPF는 더 재미 있습니다. 그리고 더 강력합니다.

학습 곡선이 더 가파르고 있습니다. 그러나 결국 더 보람이 있습니다.

언급해야 할 또 하나의 고려 사항 은 mono에서 WPF 지원 계획 이 없다는 것 입니다. 나는 (모노) 크로스 플랫폼 지원에 관심을 보이지 않았지만, 앞으로 (Winforms와 함께라면)이 기회가있을 수 있음을 알고 있습니다. 아마도 모노 또는 이와 유사한 WPF에 대한 지원이 제공 될 것입니다.

편집 : 내가 제공 한 링크가 지적하고 Gulshan의 의견이 강조 되었 듯이 Moonlight는 모노 팀이 크로스 플랫폼 Silverlight 지원을 제공하기위한 오픈 소스 노력 입니다.

WPF에 대해 들었을 때 매우 기뻤습니다. 그 아이디어는 훌륭하게 들렸으며 제가 본 모든 것이 아름답습니다. 그러나 Visual Studio 2008에서 베타 버전을 사용했을 때 디자이너 / IDE에서 작업하는 것이 실망스럽고 기발한 것으로 나타났습니다.

당시 블로그에 작은 정보를 게시했습니다.
http://blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

나는 2010 년에 그것을 시도하지 않았지만, 나는 몇몇 사람들과 이야기를 나 and지만 여전히 이해하기가 조금 복잡하고 성가신 것처럼 들립니다.

나는 당신의 응용 프로그램이 의심 할 여지없이 WPF에서 더 좋아 보이거나 기분이 좋을 것이라고 생각하지만, 빌드하는 데 시간이 오래 걸리고 그 과정에서 머리를 많이 부딪 칠 것이라고 생각합니다.