WPF so với WinForms - quan điểm của lập trình viên Delphi?

Tôi đã đọc hầu hết các chủ đề chính trên WPF so với WinForms và tôi thấy mình bị mắc kẹt trong môi trường không may mà bạn có thể rơi vào khi quyết định giữa công nghệ thử nghiệm và công nghệ thực sự trước đó (Winforms), và đó là người kế nhiệm (WPF).

Tôi là một lập trình viên Delphi kỳ cựu trong nhiều năm cuối cùng đã chuyển sang C #. Các lập trình viên Delphi đồng nghiệp của tôi ở ngoài đó sẽ hiểu rằng tôi rất vui mừng khi biết rằng Anders Hejlsberg, của danh tiếng Delphi, là kiến ​​trúc sư đằng sau C #. Tôi nghiện các thành phần tùy chỉnh VCL của Delphi, đặc biệt là những người liên quan đến việc tạo ra các Wizard và các thành phần hoạt động như một vật chứa cho các thành phần con.

Với nền tảng đó, tôi hy vọng rằng những người trong số các bạn đã chuyển từ Delphi sang C # có thể giúp tôi với quyết định WinForms so với WPF để viết các ứng dụng ban đầu của tôi. Lưu ý, tôi rất thiếu kiên nhẫn khi mã hóa và những thứ như hỗ trợ trình gỡ lỗi tự động hoàn chỉnh và đầy đủ có thể tạo hoặc phá vỡ một dự án cho tôi, bao gồm cả việc có thể tìm thấy thông tin có sẵn về các tính năng và cuộc gọi API và hơn thế nữa, cách khắc phục lỗi .

Các chủ đề và bình luận SO trong phạm vi ngày đầu năm 2009 cho tôi mối quan tâm lớn đối với WPF khi nói đến sự thất vọng tiềm tàng có thể làm mã hóa phát triển giao diện người dùng C # của tôi. Mặt khác, việc dành một lượng thời gian không đáng có để học một công nghệ API, ngay cả khi nó không bị bỏ rơi, sẽ sớm bị thay thế (WinForms), cũng gặp rắc rối không kém và tôi thấy hỗ trợ GPU trong việc trêu ngươi WPF.

Do đó sự lạc quan của tôi. Vì tôi chưa học được công nghệ nhưng tôi có một cơ hội hiếm có để có một khởi đầu mới và không phải đối mặt với đường cong "không học" lớn mà tôi đã thấy mọi người đề cập đến trong các chủ đề khác nhau khi một lập trình viên WinForms chuyển sang WPF. Mặt khác, nếu sử dụng WPF sẽ quá bực bội hoặc gây ra hậu quả tiêu cực lớn khác cho một nhà phát triển RAD thiếu kiên nhẫn như tôi, thì tôi sẽ chỉ gắn bó với WinForms cho đến khi WPF đạt được mức hỗ trợ và dễ sử dụng. Để cho bạn một ví dụ cụ thể về tâm lý của tôi với tư cách là một lập trình viên, tôi đã sử dụng VB và sau đó Delphi để tránh hoàn toàn nỗi đau thực sự của việc mã hóa với MFC, một thư viện UI Windows mà nhiều nhà phát triển phải chịu trong khi phát triển các ứng dụng Windows đầu tiên. Tôi chưa bao giờ hối tiếc về sự may mắn của mình khi tránh MFC.

Cũng sẽ rất thoải mái khi biết nếu Anders Hejlsberg nắm trong tay kiến ​​trúc của WPF và / hoặc WinForms, và nếu có bất kỳ sự khác biệt nào trong tầm nhìn sáng tạo và dễ sử dụng được thể hiện trong cả hai cơ sở mã. Cuối cùng, đối với các lập trình viên Delphi một lần nữa, hãy cho tôi biết "IDE schock" mà tôi tham gia khi sử dụng WPF trái ngược với WinForms, đặc biệt là khi hỗ trợ trình gỡ lỗi. Bất kỳ ý kiến ​​thị trường việc làm cập nhật cho năm 2011 cũng sẽ được đánh giá cao.

Nếu bạn có nền Delphi, bạn sẽ thất vọng về WinForms. Bạn sẽ cố gắng làm những việc dễ dàng trong VCL, chỉ để thấy rằng chúng rất khó, hoặc thậm chí là không thể. WPF sẽ hạn chế hơn nhiều.

Ví dụ: đây chỉ là một vài hạn chế của WinForms mà chúng tôi gặp phải:

• WinForms không có gì sánh được với TAction, vì vậy, nếu bạn đã quen với việc mã hóa bằng hành động, chia sẻ cùng một văn bản và biểu tượng giữa một mục menu và nút thanh công cụ và menu chuột phải, tập trung logic cho phép của bạn và cập nhật trạng thái kích hoạt trong nền với OnUpdate ... bạn sẽ ghét WinForms, nơi bạn phải làm tất cả những cách khó và dễ bị lỗi.
• MainMothy cũ (.NET 1.0 vintage) của WinForms không hỗ trợ hình ảnh bên cạnh các mục menu và MenuStrip mới (được giới thiệu trong .NET 2.0) bị lỗi do Microsoft từ chối sửa (vì các lỗi có thể phá vỡ tính tương thích ngược).
• Nhiều điều khiển, ví dụ như TreeView, bị thiếu hiệu quả so với các đối tác VCL của chúng (rất chậm, không có chủ sở hữu rút ra, thiếu nhiều tùy chọn tùy chỉnh, v.v.)
• Không có gì giống với cộng đồng sôi động của các nhà phát triển kiểm soát bên thứ ba mà bạn đã quen ở Delphi. Có những thư viện kiểm soát chất lượng ngoài kia, nhưng bạn phải trả tiền cho chúng - các dịch vụ miễn phí như VirtualTreeView chỉ không có trên WinForms.

WPF là một ít xương trần hơn ở một số khía cạnh so với WinForms, nhưng nó mở rộng hơn rất nhiều.

• Bạn muốn một cái gì đó như TAction? WPF có ICommand, cũng phong phú như bạn đã từng sử dụng (nhưng hãy chắc chắn rằng bạn đã đọc bài viết MVVM của Josh Smith - thông thường bạn phải bật / tắt các lệnh của mình một cách thủ công khi trạng thái thay đổi, nhưng phiên bản của anh ấy sẽ tự động kích hoạt mã kích hoạt của bạn trong nền như bạn đã quen với OnUpdate).
• Bạn muốn hình ảnh trên menu? Nó được tích hợp sẵn (và không có lỗi nào như trong WinForms).
• WinForms loại bỏ chủ sở hữu trên một số điều khiển quan trọng, nhưng nếu bạn đang sử dụng WPF thay vào đó, bạn không cần vẽ chủ sở hữu - nếu bạn muốn các nút TreeView của bạn có văn bản màu đen theo sau là một số màu xanh trong ngoặc đơn, bạn chỉ cần đặt nó trong DataTemplate của bạn và nó hoạt động, không cần mã rút chủ sở hữu xấu.
• Bạn muốn kiểm soát của bên thứ ba? Trong nhiều trường hợp, bạn không cần chúng, bởi vì bạn có thể mở rộng những gì ở đó theo cách WinForms và, vâng, các nhà phát triển VCL chỉ có thể mơ ước.

WPF có một đường cong học tập rất dốc, nhưng nếu bạn chọn một cuốn sách hay (ví dụ " WPF 4 Unleashed "), nó sẽ giúp bạn vượt qua điều tồi tệ nhất - và bạn sẽ rất vui khi làm việc với một khung sẽ không cản trở bạn theo cách WinForms sẽ làm.

Tôi thường rất ngạc nhiên khi mọi người nói rằng họ không có trải nghiệm tốt với WPF. Tôi là một nhà phát triển đã chuyển từ C ++ / MFC sang C # / WinForms sang C # / WPF. Việc chuyển đổi từ WinForms sang WPF không phải là một điều dễ dàng bởi vì học XAML không phải là rất dễ dàng nhưng một khi bạn đã nắm bắt được nó, đó là một công nghệ tuyệt vời. Tôi, trước hết, không thể quay lại WinForms. WPF thật tuyệt vời.

Một điều khác làm phiền tôi là cách mọi người thường liên kết WPF với chỉ UI. Nó thực sự tốt hơn WinForms 100 lần theo quan điểm của tôi về thiết kế giao diện người dùng, nhưng có nhiều lý do khác khiến bạn thích sử dụng WPF:

1. UI, tất nhiên.
2. Ràng buộc. Chỉ đơn giản là ma thuật. Tính năng mạnh mẽ nhất sau UI. Các ứng dụng LOB được hưởng lợi từ điều này nhiều nhất.
3. Các lệnh.
4. Tách biệt mối quan tâm. Nhà thiết kế làm việc về thiết kế, lập trình viên lập trình.
5. Tài sản đính kèm. Bạn có thể mở rộng chức năng của các điều khiển bên thứ ba mà không cần mã nguồn (mặc dù điểm này cũng có thể là một phần của điểm đầu tiên).
6. Dễ dàng chuyển đổi sang Silverlight (Cả web & WP7)

Bạn có thể không đồng ý với tôi về điểm cuối cùng là lý do để bạn học WPF, nhưng nếu bạn hỏi tôi, đó là một trong những điểm lớn nhất. Bạn học WPF, bạn có thể dễ dàng chuyển sang Silverlight. Silverlight đang phát triển lớn, và nó cũng là một công nghệ tuyệt vời.

Và lý do lớn nhất là, đó là tương lai. Nó có thể được hợp nhất với Silverlight nhưng các kỹ năng sẽ vẫn như cũ.

Vì vậy, tôi sẽ khuyên bạn nên đi theo con đường WPF.

Rõ ràng WPF là cách để suy nghĩ trong tương lai. Làm chủ nó là khó, nhưng nền tảng được kiến ​​trúc rất tốt và linh hoạt.

Một vài lời khuyên:

• Bắt đầu dễ dàng: Đừng cố thực hiện dự án đầu tiên của bạn bằng cách chỉ sử dụng MVVM hoặc hình động ưa thích. Bắt đầu đơn giản với các cửa sổ, nút và danh sách.
• Tận dụng lợi thế của DataBinding.
• Mua cuốn sách WPF Unleashed của Adam Nathan.

Trước tiên tôi nên lưu ý rằng tôi chủ yếu là một nhà phát triển asp.net, mặc dù tôi đã sử dụng winforms rất nhiều trước đây. Việc chuyển sang WPF không lớn như bạn đang thực hiện (imo) sau một tuần hoặc hơn (hơn 40 giờ), hầu hết là bản chất thứ hai một lần nữa.

Dù sao, tôi tin rằng Anders Hejlsberg là một trong những kiến ​​trúc sư đằng sau WPF, ít nhất là theo các nhà xuất bản của cuốn sách này->

“ Là một trong những kiến trúc sư đằng sau WPF, Chris Anderson khéo léo giải thích không chỉ là 'như thế nào,' mà còn là 'lý do tại sao.' Cuốn sách này là một tài nguyên tuyệt vời cho bất cứ ai muốn hiểu các nguyên tắc thiết kế và thực hành tốt nhất của WPF. Tiêu chíAnders Hejlsberg, đồng nghiệp kỹ thuật, Tập đoàn Microsoft

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

Winforms rất gần giống với phát triển Delphi. Và, tất nhiên, có một lý do cho điều đó. Giống như mô hình đối tượng Delphi / Object Pascal ảnh hưởng lớn đến C #, do đó hệ thống biểu mẫu ảnh hưởng đến Winforms.

WPF dường như là hướng mà mọi thứ đang hướng tới; người ta nói rằng giao diện người dùng VS2010 (tuyệt đẹp!) dựa trên WPF, không giống như các thế hệ trước được xây dựng trên Winforms.

Nếu bạn muốn ở trong vùng thoải mái của bạn, hãy đi với winforms. Nếu bạn muốn theo kịp những gì mới nhất và tuyệt vời nhất, hãy đắm mình vào WPF.

Tôi không phải là lập trình viên Delphi, nhưng vâng, tôi đã làm việc trên cả WinForm (nặng) và WPF (dưới mức trung bình). Tôi đồng ý với bạn ở một mức độ nào đó về mức độ thất vọng đối với một người nào đó sẽ thực hiện chuyển đổi từ WinForm sang WPF vì tôi đã ở trong tình huống đó, nhưng chỉ cho đến khi tôi quen với nó. Tìm hiểu và xem mức độ tuyệt vời và linh hoạt với WPF được so sánh với WinForm. Nó có đường cong học tập nặng nề, ít nhất là đối với một người đến từ nền tảng Delphi chứ không phải Winform. Đối với bạn, nó chắc chắn đáng để tiến tới WPF hơn là WinForm và đáng để bạn dành thời gian.

Bạn có thể muốn xem xét các liên kết dưới đây để bắt đầu:

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

Tôi đã thực hiện một số công việc Windows Forms (chủ yếu trên Pocket PC), cộng với một số môi trường không phải .NET khác sử dụng các nguyên tắc tương tự. Khi tôi chuyển đến WPF khoảng ba năm trước, trong vài tháng đầu tiên tôi đã chửi rủa nó. Cuối cùng, nó chỉ "nhấp chuột" và tôi đã không nhìn lại - thực tế tôi sẽ bị đánh bại nếu dự án tiếp theo của tôi yêu cầu tôi quay lại Windows Forms.

Lần cuối cùng Windows Forms được cập nhật là vào năm 2005 (VS 2005.) Nó vẫn ở đó nhưng không còn được Microsoft cải tiến. WPF là đứa trẻ mới trong khối ứng dụng dành cho máy tính để bàn, vì vậy nếu bạn sẽ chuyển sang nền tảng .NET bằng các công cụ MS, thì tôi sẽ nói đó là đặt cược an toàn. Một số người đẩy Silverlight như một giải pháp máy tính để bàn, nhưng khi tôi xem nó như một khả năng, tôi thấy rằng nó có quá nhiều hạn chế (có thể có ý nghĩa trong bối cảnh web, nhưng không nhiều trên máy tính để bàn.)

Điểm mấu chốt: Có một đường cong học tập dốc, và tôi vẫn đang học nó. Nhưng đó là tất cả các giá trị nó. Đó là rất nhiều niềm vui.

Nếu bạn định viết các ứng dụng mới từ đầu, sử dụng WinForms sẽ là một sai lầm. Về cơ bản là chết từ góc độ đầu tư. Microsoft sẽ giữ nó trong một thời gian dài, nhưng bạn sẽ không nhận được bất kỳ tính năng mới hoặc hỗ trợ mới, v.v. WPF là hướng đi rõ ràng cho các ứng dụng máy tính để bàn cho tương lai trên nền tảng MS.

Từ góc độ nghề nghiệp, bạn cũng biết nhiều hơn về WPF so với WinForms. Vì những lý do tương tự ở trên. Ngoài ra, bạn sẽ có một cơ hội tốt khi học Silverlight. Có rất nhiều sự chồng chéo giữa hai nền tảng đó.

Và cuối cùng, WPF chỉ đơn giản là vui hơn. Và mạnh mẽ hơn.

Đường cong học tập dốc hơn, tôi cho bạn điều đó. Nhưng nó là phần thưởng nhiều hơn cuối cùng.

Một xem xét bổ sung cần được đề cập là không có kế hoạch hỗ trợ WPF trong đơn . Tôi nhận ra rằng bạn không nêu bất kỳ mối quan tâm nào đối với hỗ trợ đa nền tảng (đơn), nhưng có thể có một cơ hội cho điều này trong tương lai của bạn (nếu bạn đi với Winforms). Có lẽ, hỗ trợ cho WPF trong đơn (hoặc tương tự) sẽ xuất hiện.

chỉnh sửa: Như liên kết tôi cung cấp đã chỉ ra và nhận xét của Gul Sơn được nhấn mạnh, Moonlight là một nỗ lực nguồn mở được dẫn dắt bởi nhóm đơn nhân để cung cấp hỗ trợ Silverlight đa nền tảng .

Tôi đã rất phấn khích khi nghe về WPF, ý tưởng này nghe có vẻ hay, và mọi thứ tôi thấy nó đều rất đẹp. Tuy nhiên, khi tôi sử dụng nó trong Visual Studio 2008 (phải thừa nhận là bản beta), tôi thấy thật khó chịu và kỳ quặc khi làm việc với nhà thiết kế / IDE.

Tôi đã đăng một thông tin nhỏ trên blog của mình tại thời điểm đó:
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

Tôi đã không thử nó vào năm 2010, mặc dù tôi đã nói chuyện với một vài người có, và có vẻ như nó vẫn hơi phức tạp / khó chịu để nắm bắt.

Tôi nghĩ rằng ứng dụng của bạn chắc chắn sẽ trông / cảm thấy tốt hơn trong WPF, nhưng tôi cũng nghĩ rằng nó sẽ khiến bạn mất nhiều thời gian hơn để xây dựng và bạn sẽ đập đầu rất nhiều trên đường đi.