새 GUI를 만들 때 Windows Forms보다 WPF가 더 선호됩니까?[닫은]

https://stackoverflow.com/questions/57909

09-06-2019
|

문제

Windows 양식의 대부분의 제한 사항과 트릭은 대부분의 프로그래머에게 공통적입니다.그러나 .NET 3.0부터는 Windows Presentation Foundation이라는 WPF도 사용할 수 있습니다.이를 사용하면 "섹시한 응용 프로그램"을 더 쉽게 만들 수 있으며 .NET 3.5 SP1을 사용하면 실행 속도가 크게 향상됩니다.

그러나 반면에 WPF에서는 많은 것들이 다르게 작동합니다.더 어렵다고 말하지는 않겠지만 처음부터 "모든 것"을 배워야 합니다.

내 질문:새로운 GUI를 생성해야 하고 프로젝트에 대한 시간적 압박이 없을 때 이 추가 시간을 투자할 가치가 있습니까?

해결책

WPF를 사용하면 놀라운 일을 할 수 있습니다. 정말 마음에 듭니다...하지만 개발자들이 나에게 새로운 기술로 전환해야 할지 여부를 물을 때마다 나는 항상 내 추천 사항을 검증해야 한다는 의무감을 느낍니다.

귀하의 개발자는 WPF를 효과적으로 사용하는 방법을 배우는 데 시간을 할애할 의향이 있습니까(가급적이면 EAGER)?MFC, Windows Forms 또는 관리되지 않는 DirectX에 대해 이렇게 말할 생각은 전혀 없었지만 팀이 일반 개발 과정에서 WPF를 "선택"하는 것을 원하지 않을 것입니다.배송상품의 주기!

최소한 한두 명의 개발자가 디자인 감각을 갖고 있고, 최종 디자인 권한을 가진 개인이 개발 문제에 대해 어느 정도 이해하고 있는지 확인하여 WPF 기능을 활용하여 "다채로운" 것이 아니라 실제로 더 나은 것을 만들 수 있습니다. , 무료 애니메이션이 포함되어 있습니까?

목표 고객 기반 중 일부가 계획했던 기능을 지원하지 않을 수 있는 통합 그래픽 칩셋을 사용하고 있습니까? 아니면 여전히 Windows 2000을 사용하고 있으므로 고객이 될 수 없습니까?어떤 사람들은 귀하의 고객이 실제로 향상된 시각적 요소에 관심이 있는지 묻습니다. 그러나 90년대 초반 내부 회사의 "우리 비즈니스 고객은 색상과 그림에 관심이 없습니다"라는 논쟁을 겪어본 결과 경쟁업체의 잘 설계된 솔루션이 있다는 것을 알고 있습니다. 진짜 질문은 그들이 지금 관심을 갖도록 만들 무언가를 제공할 수 있는 조건이 올바른지 여부입니다.

프로젝트에는 호환되지 않는 레거시 스캐폴딩에 연결하려고 시도하는 추가적인 복잡성을 피하기 위해 적어도 프레젠테이션 계층에 대한 기초 개발이 포함됩니까(Win Forms와의 Interop은 원활하지 않음)?

귀하의 관리자가 4~6개월 동안 개발자 생산성이 크게 저하되는 것을 받아들일 수 있습니까?

이 마지막 문제는 제가 WPF의 "FizzBin" 특성이라고 생각하는 것 때문에 발생합니다. 작업을 구현하는 10가지 방법이 있고 특정 접근 방식을 다른 접근 방식보다 선호할 뚜렷한 이유가 없으며 작업을 수행하는 데 도움이 되는 지침이 거의 없습니다. 선택.어떤 선택을 하든 단점은 프로젝트 후반에야 분명해질 뿐만 아니라 프로젝트의 모든 개발자가 다른 접근 방식을 채택하게 되어 유지 관리에 큰 어려움을 겪게 됩니다.가장 실망스러운 점은 프레임워크를 배우려고 할 때 끊임없이 문제를 일으키는 불일치입니다.

내 블로그 항목에서 더 자세한 WPF 관련 정보를 찾을 수 있습니다.

http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx

다른 팁

3개월 동안 망치질을 시도한 끝에 사업 분야 (LOB) 응용 프로그램을 WPF에서 사용하면서 프로젝트를 위해 Windows Forms로 다시 전환하는 것을 고려하게 되었고 다른 사람들의 의견을 조사하던 중 이 스레드를 발견했습니다...

그렇습니다. WPF는 뛰어난 기술이며 단순히 눈에 띄는 것 이상의 이점을 가지고 있습니다.템플릿 작성 및 바인딩 기능이 좋은 예입니다.전체 개체 모델은 더 많은 유연성과 더 넓은 가능성을 제공합니다.그러나 이것이 향후 LOB 애플리케이션을 위한 사실상의 플랫폼이 되는 것은 아닙니다.

비즈니스 논리에서 GUI를 분리하는 측면에서 WPF가 해결하는 "문제"는 올바른 아키텍처와 사고 방식으로 시작하는 것만으로는 Windows Forms에서 쉽게 해결할 수 없는 문제가 아닙니다.WPF의 개체 경로 바인딩 기능도 몇 가지 매우 간단한 도우미 클래스를 사용하여 Windows Forms에서 재현할 수 있습니다.WPF의 데이터 템플릿 기능은 매우 훌륭하지만 Windows Forms의 특정 부분에서 어떤 개체를 나타낼지 정확히 알 수 없는 드문 경우에 Windows Forms에서 시뮬레이션할 수 없는 것은 아닙니다. 화면.

Windows Forms가 앞서는 부분은 성숙도 측면입니다.누군가가 Windows Forms 문제를 해결해 준 블로그를 방문하지 않고는 Google에서 죽은 고양이를 휘두를 수 없습니다.반면에 WPF는 상대적으로 사용 가능한 학습 리소스가 적고 사용 가능한 사용자 지정 컨트롤도 적으며 초기 문제가 많이 해결되지 않았습니다.

WPF와 Windows Forms를 결정하는 가장 중요한 단계는 개발 환경의 성숙도입니다.Windows Forms 편집기는 매끄럽고 반응이 빠르고 직관적입니다.오류에 대한 피드백은 즉시 전달되고 해결 방법은 일반적으로 명확하며 Windows Forms의 컴파일->디버그->편집 주기는 매우 빠릅니다.

반면에 WPF 응용 프로그램은 오류가 처음 발생하면 디자인 보기가 너무 준비가 되어 있어 상대적으로 한심한 디자인 시간 지원을 제공하며 종종 디자이너가 시작하기 전에 수정 후 프로젝트 빌드가 필요합니다. 다시.전혀 작동하지 않거나 완전히 비직관적인 결과를 산출하는 광범위한 상황을 고려할 때 도구 상자에서 구성 요소를 끌어서 놓는 것이 지원되지 않을 수도 있습니다.WpfToolkit의 약속에도 불구하고 적절한 성능이나 디자인 시간 친화성을 제공하는 사용 가능한 WPF용 DataGrid는 아직 없습니다.

WPF 애플리케이션 디버깅은 다음과 약간 비슷합니다. 오래된 ASP.NET 디버깅 패러다임...때리다 F5 -> 대기 -> 실행 -> 오류 -> 중지 -> 수정 -> 히트 F5 -> 대기 -> 실행 -> 오류 -> 신음 소리 -> 중지 -> 수정 -> 히트 F5....프로그램이 실행 중인 모든 XAML이 잠겨 있으며 XAML 관련 문제를 추적하는 것은 종종 지루한 일입니다.

간단히 말해서, Windows Forms용 개발 도구를 사용하면 WPF 응용 프로그램보다 훨씬 짧은 시간에 프런트 엔드를 처리할 수 있다는 것입니다. 특히 대부분의 LOB에 있는 인터페이스와 같은 마스터-세부 그리드 또는 스프레드시트를 생성하는 경우.Windows Forms를 사용하면 이미 완료된 작업의 90%로 시작할 수 있습니다.

저는 WPF 아키텍처의 열렬한 팬입니다.디자인 타임 도구 세트가 알파 이전 디버그 빌드처럼 느껴지지 않았으면 좋겠습니다.

편집하다:이 답변은 .NET 3.5 + Visual Studio 2008에 대해 게시되었지만 Visual Studio 2010이 포함된 .NET 4.0에는 WPF 데이터 그리드가 함께 제공됩니다.새로운 WPF 개발 환경에 많은 개선이 이루어졌지만 여기에 대한 제 대답은 변함이 없으며 다음 제안을 추가하고 싶습니다.

급하게 할 일이 있다면 라드 개발하려면 Windows Forms를 사용하세요.잘 설계되고 유지 관리 가능하며 확장 가능하고 리소스가 풍부한 다중 사용자 LOB(기간 업무) 응용 프로그램을 생성하려는 경우 ASP.NET MVC + HTML 5 + jQuery를 고려하세요.이러한 기술을 사용한 내 프로젝트는 고객에게 더 나은 결과를 더 빨리 가져왔습니다.MVC는 WPF와 동일한 템플릿을 모두 제공하며 jQuery는 애니메이션과 복잡한 상호 작용을 가능하게 합니다.더 중요한 것은 ASP.NET MVC + jQuery 솔루션을 사용하려면 최종 사용자에게 적절한 그래픽 하드웨어를 갖춘 최신 데스크톱이 필요하지 않다는 것입니다.

저는 이제 고객의 핵심 시스템이 된 WPF를 사용한 지 7개월이 되었습니다. 비즈니스 프레젠테이션 플랫폼으로 WPF를 배우고 사용한 경험에 대해 더 많은 생각을 여러분과 공유하고 싶습니다.

일반적으로 위에서 언급한 의견은 여전히 유효합니다.WPF에 대한 디자인 타임 지원은 아직 제공되지 않습니다.리치 클라이언트 응용 프로그램을 출시하기 위해 급하게 서두르고 있다면 Windows Forms를 선택하세요.기간.Microsoft는 GDI/Windows Forms 플랫폼 중단을 서두르지 않으므로 앞으로도 공정한 시간 동안 좋은 지원을 받으실 수 있습니다.

WPF는 마스터하기 쉽지 않습니다, 하지만 WPF 학습에 시간과 에너지를 투자할지 여부를 결정하는 데 있어서는 안 됩니다.현재 성숙도가 부족함에도 불구하고 WPF는 몇 가지 유용하고 현대적인 개념을 기반으로 구축되었습니다.

예를 들어 WPF에서는 올바른 유효성 검사 논리를 사용하여 잘 작성된 비즈니스 개체에 대한 투자가 확실한 투자입니다.Windows Forms와 달리 WPF의 데이터 바인딩에는 인터페이스 컨트롤이 잘못된 사용자 입력에 반응할 수 있도록 하는 기능이 풍부합니다. GUI 코드를 작성하지 않고 해당 오류를 감지합니다.이것은 가치 있는 일입니다.

WPF의 스타일 지정 및 템플릿 기능도 가치 있는 것으로 입증되었습니다.스타일링과 템플릿의 유일한 용도는 화면에 눈요기를 만드는 것이라는 일반적인 오해에도 불구하고, 사실 이러한 기능은 풍부한 피드백을 제공하는 사용자 인터페이스의 코딩을 크게 단순화합니다. 기본 비즈니스 논리 계층의 상태 또는 커서 아래 개체의 상태를 기반으로 텍스트를 지능적으로 찾는 도구 설명 등

이것들은 모두 "아무것도 화려하지 않은" 것을 위한 믿을 수 없을 만큼 귀중한 기능을 추가합니다. 비즈니스 애플리케이션, 이는 단순히 기본 데이터와 일치하는 인터페이스를 유지하기 쉽기 때문입니다.

간단히 말해서:

Windows 양식에서는 사용자 인터페이스를 설계 한 다음 해당 사용자 인터페이스를 구동하기 위해 코드를 작성하며 일반적으로 데이터 객체를 구동하는 코드도 포함됩니다.
WPF에서는 데이터 개체를 구동하는 비즈니스 계층에 투자한 다음, 듣는다 귀하의 데이터 객체에.

겉으로는 미묘해 보이지만 코드를 재사용하는 능력에는 큰 차이가 있습니다.질문을 던집니다."Windows Forms와 WPF에 대한 질문은 실제로 투자 결정입니까?"

(이것은 내가 가장 좋아하는 스레드가 된 것 같습니다.)

WPF를 사용해야 하는 강력한 이유가 있나요?

전적으로!WPF는 정말 놀랍습니다!Windows Forms에는 부족한 기능과 기능이 너무 많기 때문에 거의 모든 프로젝트에 큰 이점이 될 것입니다.

비즈니스 애플리케이션의 가장 큰 승리는 다음과 같습니다.

환상적인 데이터 바인딩과 템플릿이 가장 큰 차이를 만듭니다.적절한 데이터 모델이 구축되면 몇 번의 클릭만으로 데이터 템플릿을 생성하고 사용할 수 있습니다. 표현 혼합 드래그 앤 드롭을 사용하여 개체가 어떻게 보일지 정확하게 구성합니다.그리고 색상이나 모양 같은 것에 바인딩하는 것은 사소한 일입니다.
화면 레이아웃은 놀라울 정도로 유연합니다.WPF의 모든 항목은 컨테이너 크기 및 모양 변경에 맞게 원활하게 조정될 수 있을 뿐만 아니라 항목을 간단하게 확대 및 회전할 수 있으며 포함된 프레임 외부로 확장할 수도 있습니다.
일반 개체는 원하는 방식으로 표시할 수 있고, 다양한 화면에서 쉽게 다른 표시를 할 수 있으며, 표시를 공유할 수 있고, 데이터 값의 변경에 맞게 표시를 조정할 수 있습니다.
인쇄해야 하는 경우 프린터로 렌더링하는 것은 간단합니다.적절하게 구성되면 WPF는 크리스탈 리포트 또는 SQL Server 보고 서비스 (SSRS) 어린이 장난감처럼 보입니다.
사용자 인터페이스는 마우스를 위에 놓을 때 움직이는 버튼과 같은 멋진 기능을 포함하여 훨씬 더 역동적으로 보이고 느껴질 것입니다.

유틸리티와 게임의 경우 다른 장점이 가장 중요합니다.

외부 편집기를 사용하지 않고도 애플리케이션에 모양, 선 및 임의의 그림을 쉽게 추가할 수 있습니다.이들의 모든 구성 요소는 데이터 바인딩 및 애니메이션화되거나 코드로 제어될 수 있습니다.Windows Forms에서는 일반적으로 많은 작업을 수행하려는 경우가 아니면 비트맵을 가져와서 있는 그대로 사용하면 됩니다.
애니메이션이 멋지다!과용하지 않는 한 사용자는 정말 깊은 인상을 받을 것입니다.또한 사람들이 무슨 일이 일어나고 있는지 확인하고 강조할 필요성을 줄이는 데 도움이 될 수 있습니다.예를 들어, 개체를 끌 때 대상에 애니메이션을 적용하여 개체를 놓으면 어떤 일이 발생하는지 보여줄 수 있습니다.
색상, 그라데이션 채우기, 브러시, 멋진 글꼴, 개체 회전, 타일 브러시 등그래픽으로 원하는 것은 무엇이든 요청하면 됩니다.
놀라울 정도로 맞춤설정 가능합니다.한 가지 용도로 철로를 그려서 그 위에 기차를 떨어뜨려야 했습니다.몇 시간 후에 나는 다음을 사용하여 화면 어디든 그릴 수 있는 철로를 갖게 되었습니다. 베지어 곡선, 그들은 자동으로 가입하고 전환합니다.

결론적으로 Windows Forms에서 구축할 수 있는 상당한 크기의 GUI는 3분의 1(또는 그 이하)의 노력으로 WPF에서 구축할 수 있으며 훨씬 더 좋아 보입니다.

WPF에는 더 많은 리소스(특히 RAM)가 필요합니까?

Windows Forms에 비해 가격이 비싸지만 가격은 작습니다.

RAM은 구현에 따라 증가하거나 감소할 수 있습니다.WPF는 데이터를 더 효율적으로 저장하므로 개별 개체는 더 작아집니다. 그러나 Windows Forms보다 WPF에 개체가 더 많은 경향이 있으므로 균형을 이루고 둘 중 하나가 먼저 나올 수 있습니다.
Windows Forms에 비해 CPU가 올라갑니다.내 경험에 따르면 화면상의 WPF 개체를 실제로 업데이트하는 데는 일반 Windows Forms 렌더링보다 CPU가 두 배 정도 더 많이 사용됩니다.응용 프로그램이 화면을 업데이트하는 데 대부분의 시간을 소비한다면 WPF가 적합하지 않을 수 있습니다.하지만 이 경우에는 Windows Forms도 사용하지 않을 것입니다.대부분의 진지한 게임은 다음에 직접 작성됩니다. 다이렉트X.
WPF는 Windows Forms보다 훨씬 적은 코드를 사용하므로 디스크 사용량이 약간 적습니다.물론 데이터의 크기는 동일합니다.

CPU 사용에 대한 추가 참고사항:애니메이션 및 변환(모션, 변환 등)은 유지 모드 저장소로 인해 실제로 Windows Forms보다 WPF에서 더 효율적입니다.더 느린 것은 거기에 있는 물체를 처음으로 가져오는 것입니다.

유지관리 간접비

WPF는 거대한 유지 관리 측면에서 Windows Forms보다 우위에 있습니다.이전보다 1/5의 코드로 모든 작업이 완료되므로 유지 관리할 부분도 1/5로 줄어듭니다.또한 모든 상용구 항목이 사라졌으므로 실제로 작업을 수행하는 코드에 집중할 수 있습니다.

XAML의 이점

XAML WPF의 핵심입니다.WPF는 XAML 없이도 사용할 수 있지만 XAML을 사용하면 매우 쉽게 사용할 수 있습니다.XAML에는 사용자 인터페이스를 쉽게 지정할 수 있는 HTML 기능이 있지만 XAML의 기본 제공 태그는 훨씬 더 강력하며 사용자가 직접 쉽게 정의할 수 있습니다.(사실 그렇게 하는 것이 정상입니다.)

XAML의 몇 가지 구체적인 장점은 다음과 같습니다.

전체 UI는 사용자와 도구 모두 쉽게 읽고 조작할 수 있는 텍스트 파일로 정의됩니다.
MarkupExtensions를 사용하면 명확하고 간단한 방법으로 바인딩을 지정할 수 있습니다.
유형 변환기를 사용하면 복합 유형의 속성을 쉽게 지정할 수 있습니다.예를 들어 Brush="Green"이라고 말하거나 3개의 정지점이 있는 방사형 그라데이션 브러시를 지정할 수 있습니다.
자신만의 요소를 만들 수 있습니다.
WPF의 강력한 "부속된 속성"을 쉽게 활용할 수 있습니다.

기타 통찰력

저는 수년 동안 WPF와 같은 것을 꿈꿔왔습니다.많은 사람들이 이 기능의 일부를 구현했지만 이 모든 기능을 한 곳에서 이 정도 가격($0)으로 얻을 수 있다는 것은 놀라운 일입니다.

WPF는 Windows Forms의 패러다임을 크게 변화시켰으며 익숙해지는 데 시간이 좀 걸리지만, 이를 배우는 데 드는 시간은 몇 배의 보상을 받을 것입니다.

WPF에는 5년이 지난 지금도 여전히 몇 개의 사마귀가 있지만 일단 경험해 보면 WPF의 위력은 완전히 놀라게 될 것입니다.누군가가 Windows Forms로 다시 끌어오려고 하면 발로 차고 비명을 지르게 될 것입니다.

팁:- 개발을위한 표현식 블렌드 사본을 얻으십시오 - 때때로 XAML을 손으로 편집하십시오 - 처음에는 이상하게 보일 때 포기하지 마십시오.

WPF에는 Windows Vista 또는 Windows XP SP2가 필요합니다. 이는 번거로운 요구 사항은 아니지만 관련성이 있는 요구 사항입니다.Windows 2000(아직도 그렇게 하고 있음)에서 실행하려는 경우에는 WPF가 작동하지 않습니다.

WPF는 최신 기술이며 Windows Forms만큼 입증되지 않았으므로 특히 대규모 응용 프로그램의 경우 덜 위험한 옵션으로 Windows Forms를 선택할 수 있습니다.

그렇다면 WPF는 미래입니다.Visual Studio 2010은 WPF로 다시 작성되고 있으며 이는 아마도 현재까지 가장 큰 WPF 응용 프로그램이 될 것이며 기술에 대한 실제 테스트가 될 것입니다.

분명히 레거시 Windows Forms 응용 프로그램은 올바른 선택인 또 다른 상황이 될 것입니다.

다른 사람들이 말했듯이, 여기로 가려면 장점과 단점이 있습니다.다른 사람들이 말했듯이 WPF의 장점은 다음과 같습니다.

매우 풍부한 UI를 만드는 능력 비교적 용이하게.
더욱 쉬워진 애니메이션과 특수 효과
고유한 확장성(WPF 애플리케이션 및 Windows Forms 애플리케이션에서 Windows Vista 돋보기 도구 사용:WPF 애플리케이션에서는 모든 벡터 아트의 크기가 아름답게 조정됩니다.
(OPINION ALERT) WPF에서 문서 지향 시스템을 수행하는 것이 "더 쉽다"고 생각합니다.

그러나 Windows Forms가 가장 먼저 나오는 WPF에는 단점이 있습니다.

WPF의 기본 제공 컨트롤 제품군은 Windows Forms의 컨트롤 제품군보다 훨씬 더 제한적입니다.
Windows Forms에 대한 타사 제어 공간에 대한 지원이 더욱 강화되었습니다.(물론 변화하고 있지만 생각해 보세요.Windows Forms는 2001년부터 사용되었습니다.WPF는 불과 몇 년만입니다.시간이 지나면서 Windows Forms는 커뮤니티에서 더 많은 지원을 받게 됩니다.)
대부분의 개발자는 이미 Windows Forms를 알고 있습니다.WPF는 새로운 학습 곡선을 제공합니다

마지막으로, 작업을 수행하거나 올바른 타사 도구를 사용하면 두 도구 모두에서 훌륭하고 매력적이며 매력적인 UI를 만들 수 있다는 점을 명심하세요.결국, 모든 상황에서 어느 쪽도 반드시 더 나은 것은 아닙니다.프로젝트에 적합하다고 생각되는 것을 사용하십시오.

WPF의 프로그래밍 모델은 Windows Forms보다 더 개방적이고 유연하지만 ASP.NET MVC와 마찬가지로 Model-View-ViewModel 패턴을 올바르게 구현하는 측면에서 좀 더 엄격한 원칙이 필요합니다.

내 첫 번째 맥없이 걷다 WPF를 사용한 응용 프로그램은 결국 완전한 실패로 끝났습니다. 최종 사용자의 저가형 노트북이 중단되는 리소스를 많이 소비했기 때문입니다...이는 결국 제가 WPF +를 사용했기 때문입니다. LINQ에서 SQL로 그리고 좋은 결과가 있기를 기대합니다..이것이 바로 WPF가 Windows Forms와 크게 다른 점입니다.Windows Forms에서는 그런 일을 피할 수 있습니다.WPF는 Windows Forms보다 리소스가 훨씬 더 무겁기 때문에 응용 프로그램을 간결하게 설계하지 않으면 결국 800파운드의 고릴라가 됩니다.

WPF를 부끄러워하지 마세요...그것을 탐험해보세요.그러나 Windows Forms 코딩의 허용 가능한 죄는 WPF에서 좋은 결과를 낳지 않는다는 점에 유의하십시오.이들은 근본적으로 다른 엔진으로, 근본적으로 다른 코딩 패턴에 적합합니다.

마지막 단어:WPF를 사용하려면 목록 및 그리드와 함께 사용할 수 있는 데이터 가상화에 대해 잘 숙지하세요.간단한 데이터 바인딩된 ListItem 또는 GridCell은 결국 WPF에서 엄청난 논리적 + 시각적 개체 그래프가 되며, 가상화 방법을 배우지 않으면 응용 프로그램이 대규모 데이터 세트에서 제대로 작동하지 않습니다.

WPF에는 매우 가파른 학습 곡선이 있으므로 먼저 확실한 책을 구하는 것이 좋습니다(아담 네이선, 판매/그리피스, 그리고크리스 앤더슨) 및 블로그 (조쉬 스미스, 등.).이에 대비하고 프로젝트에서 WPF를 배울 수 있는 시간을 허용하는지 확인하세요.

기술을 배우는 것 외에도 WPF 애플리케이션을 구성하는 데 사용되는 패턴을 배우는 데 시간을 투자하세요. 모델 보기 ViewModel (MVVM)이 많은 호응을 얻은 것 같습니다.

개인적으로 저는 WPF가 그만한 가치가 있다고 생각하지만 미리 주의해야 합니다.또한 사용자를 Windows XP SP2+ 및 Windows Vista로 효과적으로 제한한다는 점에 유의하세요.우리는 그러한 결정을 내렸지만 귀하의 요구 사항은 다를 수 있습니다.

두 기술 모두 장단점이 있습니다."클래식" UI를 사용하는 대규모 애플리케이션에서는 Windows Forms를 사용합니다.풍부한 사용자 인터페이스(스키닝, 애니메이션, 사용자 인터페이스 변경)가 필요한 응용 프로그램에서는 WPF를 선택합니다.기사를 확인해주세요 WPF 대윈도우 폼 WPF와 Windows Forms를 비교합니다.

UI 디자인의 유연성 외에도 WPF에는 몇 가지 기술적인 이점이 있습니다.

1.) WPF는 GDI 개체에 의존하지 않습니다. 글쎄, 내 생각엔 창 자체의 인스턴스에 2개의 GDI 개체를 사용하는 것 같지만 실제로는 아무것도 아닙니다.저는 매우 큰 규모의 내부 Windows Forms 응용 프로그램에 어느 정도 참여해 왔습니다.우리 사무실 직원들은 가끔 3~4개의 인스턴스를 동시에 실행하기도 합니다.문제는 Windows 2000, XP 및 Vista에 고유한 10,000개의 GDI 개체 제한에 자주 부딪힌다는 것입니다.그런 일이 발생하면 전체 OS가 응답하지 않게 되고 시각적 아티팩트가 나타나기 시작합니다.이를 정리하는 유일한 방법은 응용 프로그램을 종료하는 것입니다.

2.) WPF는 GPU를 활용합니다. 일부 UI 처리를 GPU로 오프로드하는 WPF의 기능은 훌륭합니다.나는 이 부분이 시간이 지나면서 좋아질 것이라고 기대한다.전 OpenGL 프로그래밍 취미 생활자로서 저는 GPU에서 나오는 성능을 높이 평가했습니다.내 말은, 내 100달러 비디오 카드에는 각각 1.5GHz에서 실행되는 112개의 코어가 있다는 것입니다(그리고 이는 결코 최고 수준이 아닙니다).이러한 종류의 병렬 처리 능력은 쿼드 코어 CPU를 부끄럽게 만들 수 있습니다.

그러나 WPF는 여전히 매우 새로운 것입니다.Windows 2000에서는 실행되지 않습니다.실제로 새로 재부팅한 후 WPF 애플리케이션 시작 속도가 느려질 수 있습니다.나는 내 블로그에서 이 모든 것에 대해 이야기합니다.http://blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html

WPF를 배울 가치가 있다고 생각합니다.속도를 익히면 양식에 대한 디자인 작업이 훨씬 쉬워집니다. IMHO.나는 '섹시한' 것에는 별로 걱정하지 않을 것이다.이것의 대부분은 단지 유행일 뿐입니다.WPF에서는 '일반' Winforms 스타일 애플리케이션을 매우 빠르고 쉽게 만들 수 있습니다.

전체 개념은 IMO 설계를 더 쉽게 해줍니다.

나는 여기에 있는 답변 중 일부에 동의하지 않습니다.WPF는 정말 적합합니다. 사업 분야 (LOB) 애플리케이션.(개구리 디자인 LOB 클라이언트가 가장 좋은 예입니다.)UI를 눈에 띄게 만들 수 있는 모든 가능성(비즈니스 애플리케이션에서는 필요하지 않음) 외에도 WPF는 더 많은 기능을 제공합니다.

데이터 바인딩 및 템플릿 기능은 Windows Forms보다 우수합니다.또한 코드와 프리젠테이션을 분리하는 훨씬 더 나은 방법을 제공합니다.우리는 개발자가 2~3명 이하인 팀에서 2개의 LOB 애플리케이션에 대해 WPF를 성공적으로 사용했습니다.

직면하게 될 가장 큰 문제는 아마도 WPF에 익숙하지 않은 개발자의 개발 속도를 저하시키는 WPF의 가파른 학습 곡선(Windows Forms에 비해)일 것입니다.

현재 Windows Forms에서 WPF로 애플리케이션을 다시 작성하고 있습니다.예, 학습 곡선이 가파르고 일부 내용을 "다시 배워야" 하지만 그만한 가치가 있습니다.그리고 WCF와 결합하여 이전보다 더 적은 코드, 더 빠르고 더 강력한 코드를 작성하고 있다는 사실을 알게 되었습니다.

한동안 참아라, 읽어라 아담 네이선의 책, 을 클릭하고 계속해서 증가하는 타사 컨트롤 라이브러리를 확인해 보세요. 텔레릭 그리고 컴포넌트원.내 생각에 한 가지 부정적인 점은 디자인 도구가 표현 혼합, 사용하기 매우 불편합니다.최신 버전은 아직 베타 버전이지만 수년간 Visual Studio를 사용해 온 우리에게는 적합하지 않다고 느껴집니다.예, 주로 디자이너를 위한 것이지만 Visual Studio에서는 수행할 수 없는 작업도 있습니다.

WPF는 더 나은 UI 경험을 제공할 수 있으므로 인터페이스 디자인이 중요한 경우 WPF를 고려하십시오.그러나 Windows Forms는 수년에 걸쳐 발전해왔기 때문에 작동하는 것이 입증되었으며 해당 플랫폼에 대한 숙련된 프로그래머를 많이 찾을 수 있습니다.

또한 이식성이 문제가 될 수 있습니다. WPF는 Windows XP SP2 이상에서만 작동합니다.

또한 WPF는 학습 곡선이 가파르기 때문에 특정 WPF 경험이 없으면 고품질 제품을 제공하기가 쉽지 않습니다.

WPF는 .NET 3.0의 일부이기 때문에 한 가지 대답은 "1.1 또는 2.0을 지원해야 하는 경우"입니다.WPF에는 알려진 OS 제한 사항이 있으며 명백한 기술 문제도 있습니다.winform을 아는 개발자 팀이 있다면 강력한 코드를 만드는 것이 더 쉬울 수 있습니다. ~와 함께 윈폼.그러나 UI 코드를 많이 작성하는 경우 어느 시점부터 WPF를 선택하는 것이 좋습니다.

WPF는 또한 Silverlight와 많은 공통점을 공유하므로 양도 가능한 이점이 있습니다.

WPF는 훌륭한 데이터 바인딩 기능, 우려 분리, 디자인 분리 및 논리 등과 같은 많은 장점이 있습니다.

개발자로서 나는 Windows Forms Designer에 묶는 대신 XAML을 사용하여 UI를 정의 할 수있는 능력을 즐깁니다. 다른 디자이너에게 앱을 잘 보이게 할 수 있다는 것을 알고 기분이 좋습니다.

개인적으로 나는 이전 버전의 Windows가 지원되지 않지만 WPF의 큰 문제 중 하나는 Mono (현재/지금까지)가 아닙니다.http://www.mono-project.com) 따라서 WPF 앱은 Mac OS 또는 Linux에서 실행되지 않습니다.(Silverlight 응용 프로그램도 마찬가지입니다).

WPF 학습에 투자할 시간과 자원이 있다면 그렇게 하세요!여러 OS를 지원하기 위해 Silverlight 응용 프로그램을 작성하려는 경우에도 마찬가지입니다.

SWF를 사용하여 여러 OS 스틱에서 실행하기 위해 데스크톱 응용 프로그램이 필요한 경우.

많은 차이점이 있습니다.우리는 다음과 같은 이유로 WPF를 좋아했습니다.

프로그래밍의 선언적 스타일.
애니메이션 및 상태 전환
Expression Blend는 훌륭한 도구입니다.
좋은 스타일 지원.

그러나 우리는 다음과 같은 이유로 Windows Forms를 고수했습니다.

개발자가 이미 Windows 양식을 알고있을 때 WPF를 배우는 데 걸리는 여분의 시간.
WPF는 Windows 2000 이하에서 실행되지 않습니다.

어떤 것을 사용할지 결정할 때 가장 큰 고려 사항은 대상 고객이 어떤 .NET Framework를 설치했는지 고려하는 것입니다.더 많은 사람들이 Windows Forms만 지원하는 낮은 .NET Framework 버전을 사용하고 있지만 이는 단지 개인적인 경험일 뿐입니다.

WPF의 장점은 사용자 정의 컨트롤과 애니메이션을 사용하여 멋진 GUI를 만드는 것이 훨씬 쉽다는 것입니다.WPF는 또한 프레젠테이션 레이어와 논리 레이어를 더욱 분리하는 데 도움이 됩니다.디자이너가 있는 경우 이 작업의 95%를 비코더에게 제공하고 코더가 로직 작업을 수행할 수 있도록 합니다.단점은 Expressions Blend의 소프트웨어 비용이 들고 제대로 작동하는 Visual Studio 코드 프로파일링 도구가 부족하여 XAML을 렌더링하려고 할 때 프레임워크 호출에 걸리는 경향이 있다는 것입니다.나는 다른 사람들도 있다고 확신하지만 이것들은 우리가 실제로 본 유일한 두 사람이었습니다.

주요 고려 사항은 고객에게 .NET 3.0 또는 더 나은 .NET 3.5 SP1을 설치하도록 요구하려는 경우입니다.당신은 부정적인 피드백을 얻을 것입니다

WPF를 사용하면 양식 디자인 작업을 디자이너 의류 개발자가 아닌 실제 디자이너에게 훨씬 쉽게 전달할 수 있습니다.그것이 당신이 하고 싶은 일이라면 WPF가 당신의 대답입니다.클래식 Windows 스타일 버튼이 괜찮다면 Windows Forms를 사용하는 것이 좋습니다.

(여러 답변에서는 인터페이스 디자인이 "중요한" 경우 WPF를 사용해야 한다고 주장하지만 이는 매우 모호합니다.인터페이스 디자인은 항상 "중요"합니다.)

MSDN 라이선스가 있는 경우 확인하세요. 표현 도구.이는 WPF용으로 명시적으로 설계되었으며 Visual Studio로 직접 내보내며 전환을 쉽게 하는 데 도움이 될 수 있습니다.

Windows 지원에만 관심이 있고 Windows를 배우는 데 걸리는 시간이 마음에 들지 않는다면 WPF를 선택하세요.빠르고 유연하며 스킨 변경이 쉬우며 작업할 수 있는 훌륭한 도구가 있습니다.

추가 보너스로 Silverlight는 WPF를 기반으로 하며 둘 중 하나로 시작하면 다른 작업 방법을 알 수 있습니다.계속 웹 기반으로 진행되는 경우 브라우저(또는 Windows Live Mesh)로 쉽게 전송할 수 있는 사전 지식(및 기존 코드 라이브러리)이 있으면 소프트웨어 수명을 연장하는 데 도움이 될 수 있습니다.

위 답변에서 이미 설명된 장단점을 고려하여 WPF를 사용하기로 결정했다면 다음을 수행하는 것이 좋습니다. Billy Hollis의 dnrTV 에피소드

~ 안에 DotNetRocks 에피소드 315, Brian Noyes는 이에 대해 광범위하게 논의합니다.

WPF의 텍스트 렌더링에는 알려진 문제가 있습니다.많은 사용자들은 앤티앨리어싱과 픽셀 혼합을 과도하게 사용하면 텍스트가 흐려진다고 보고합니다.이는 어떤 상황에서는 큰 문제가 되며 제가 아는 한 Microsoft는 어느 정도 이를 인정했습니다.

지난 3년 반 동안 저는 두 회사에서 Windows Forms 개발을 해왔습니다.두 응용 프로그램 모두 광범위하게 사용되었으며 결국 GDI 문제가 발생했습니다.대규모 Windows Forms 응용 프로그램은 결국 GDI 리소스가 부족해 최종 사용자가 재부팅해야 합니다.

Scott이 Expression Blend에 대해 불평하고 있습니다. 개발자로서 그에게는 그것이 어떻게 이해되지 않는지.Expression Blend에 대한 나의 첫 반응은 이랬습니다.그러나 지금은 이를 매우 귀중한 도구로 보고 있지만 실제로는 귀하가 어떤 유형의 개발자인지에 따라 다릅니다.

나는 다음을 수행해야 했던 사용자 인터페이스 개발자입니다. 적분기 역할을 맡게 되었고 결국 WYSIWYG 방식으로 스타일을 만들고 템플릿을 제어하는 데 Expression Blend가 매우 중요하다는 것을 알게 되었습니다.저는 거의 항상 같은 프로젝트에서 Expression Blend와 Visual Studio를 동시에 실행합니다.

나는 또한 Expression Blend를 가지고 놀면서 XAML 뱉어내는 것은 WPF API를 배우는 훌륭한 방법입니다 ...Windows Forms에서 디자이너를 사용하고 거기에서 나오는 C# 코드를 확인하는 것은 거기에서 디자인하는 모든 것을 사용하는 방법을 배우는 데 도움이 됩니다.

Expression Blend가 도움이 됩니다.특히 애플리케이션의 시각적 작업을 하고 있다면 한 번 시도해 보십시오.

의 인용문 Mark의 이전 게시물:

Windows Forms에서는 사용자 인터페이스를 디자인한 다음 해당 사용자 인터페이스를 구동하는 코드를 작성합니다. 여기에는 일반적으로 데이터 개체를 구동하는 코드도 포함됩니다.

WPF에서는 데이터 개체를 구동하는 비즈니스 계층에 투자한 다음 데이터 개체를 수신하는 인터페이스를 디자인합니다.

저는 이것이 Windows Forms를 사용하는지 WPF를 사용하는지 여부보다는 디자인 선택에 더 가깝다고 주장하고 싶습니다.그러나 특정 기술이 특정 접근 방식에 더 적합할 수 있다는 점을 인식할 수 있습니다.

WPF 전문 지식이 없고 이에 투자하고 싶지 않은 경우에만 :)

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow