WPF có phải là lựa chọn tốt cho việc phát triển dòng giao diện người dùng doanh nghiệp không?

Question

Chúng tôi đang tranh luận xem việc phát triển giao diện người dùng Windows trong tương lai của chúng tôi có nên là WinForms hay WPF hay không. Làm thế nào có một số bạn đưa ra quyết định này? Hầu hết các ứng dụng của chúng tôi là các ứng dụng LOB, và tôi không chắc rằng tôi thấy một lợi ích rõ ràng và áp đảo đối với WPF đối với các loại ứng dụng này. Tuy nhiên, kiến ​​thức của tôi về WPF bị hạn chế. Tôi cũng hơi lo ngại rằng WPF sẽ thịnh hành trong vài năm nữa và sau đó Microsoft sẽ cảm thấy mệt mỏi với nó và thúc đẩy một cái gì đó khác vào chúng tôi. Tôi đoán một đối số chống lại điều này là một thực tế là Visual Studio 2010 là một ứng dụng WPF.

Cảm ơn.

Answer 1

Có rất nhiều yếu tố cần xem xét ở đây.

lý do không chọn WPF:

• Nó hiện đang có ít sự ủng hộ hơn WinForms cho các điều khiển LOB phổ biến như hái ngày, widget nhập số, và như vậy, mặc dù điều này đang được cải thiện thông qua WPF Toolkit, trong WPF 4 và thông qua các nhà cung cấp kiểm soát của bên thứ ba.
• Công cụ không phù hợp để hôn khởi động của Windows Forms. (Mặc dù công bằng một phần là do công cụ này phải đối phó với nhiều cách tinh vi hơn để xây dựng các quan điểm. Và Blend chắc chắn đang đến đó.)
• Một mô hình tinh thần rất khác với Windows Forms. Để có được những lợi ích thực sự từ WPF, bạn cần phải suy nghĩ theo cách rất khác với những gì bạn đã quen. Vì vậy, có thể có một đường cong học tập đáng kể - không chỉ về mặt học tập công nghệ, mà còn về nội dung hóa các thành ngữ và khuôn mẫu (mặc dù hiện nay có rất nhiều tài nguyên cộng đồng xung quanh WPF thành ngữ hơn trước đây).

LÝ DO LỰA CHỌN WPF:

• hỗ trợ kiến ​​trúc Decent. WPF (nếu bạn làm điều đó đúng) có một sự phân chia khá tốt về mã và giao diện người dùng được tích hợp sẵn, làm cho các ứng dụng WPF dễ dàng hơn nhiều trong việc kiểm tra và phát triển.
• Tính linh hoạt cao hơn. Ví dụ, nếu bạn cần một bản đồ hiển thị đơn giản, bạn có thể xây dựng nó trong một vài giờ từ một ListBox, thay vì phải nghiên cứu và mua một thành phần của bên thứ ba hoặc viết một điều khiển bản đồ từ mặt đất lên. Hiển thị dữ liệu đơn giản là một tính năng sát thủ cho WPF.
• WinForms là một kết thúc chết. Nó sẽ không nhìn thấy bất kỳ cải tiến nào từ Microsoft, và các nhà cung cấp điều khiển đã bắt đầu chuyển sang WPF như là thị trường bão hòa của WinForms.
• Hầu hết các trải nghiệm WPF của bạn có thể được chuyển sang Silverlight, (a) cho phép bạn mang các ứng dụng của mình đến trình duyệt và điện thoại, và (b) mang lại cho bạn thêm sự tự tin rằng Microsoft sẽ không mất lãi nếu họ nhận được "mệt mỏi" của WPF, họ đã thể hiện một cam kết rất mạnh mẽ với Silverlight.

Cá nhân, nếu tôi bắt đầu ứng dụng Windows trên máy tính để bàn ngay bây giờ, tôi sẽ chọn WPF. Tuy nhiên, tôi đã leo lên đường cong học tập. Đối với một nhóm không có kinh nghiệm WPF, chi phí lấy nó phải là một yếu tố lớn hơn nó là dành cho tôi.

Answer 2

Một điều cần ghi nhớ là Silverlight. Có thể bạn sẽ muốn viết ứng dụng của mình để chạy từ trình duyệt trong tương lai hoặc thậm chí từ thiết bị Windows Phone 7? Trong khi Silverlight và WPF không hoàn toàn giống nhau, chúng cực kỳ giống nhau. Đây sẽ là đối số chính trong tương lai của tôi ủng hộ WPF.

Cá nhân tôi thích mô hình thành phần của WPF - cũng như cách khai báo đại diện cho giao diện người dùng và hệ thống bố cục tốt hơn WinForms. Không phải là tôi là một anh chàng giao diện, thực sự.

Answer 3

WPF sẽ thiết lập để thay thế Winforms, ít nhất là trên các thiết bị Windows Mobile, với sự phát triển trong tương lai tập trung xung quanh Silverlight (một spinoff WPF) và XNA.

Trong một thị trường mở, có ý nghĩa để trang trải WPF nếu bạn muốn giữ cho mình hấp dẫn với thị trường tuyển dụng rộng hơn.

Answer 4

Tôi đã tự hỏi bản thân mình. Nhưng thực tế là VS2010, giống như bạn nói, làm cho rất nhiều sử dụng trong WPF nói với tôi rằng Microsoft đang cố gắng nói với thế giới rằng nó không chỉ là một mốt nhất thời của MS, nhưng nó sẽ ở lại một thời gian.

Answer 5

Tôi nghĩ MS đang gửi một thông điệp rõ ràng rằng WPF và Silverlight là hiện tại và tương lai. Các Winforms PM đã nói nhiều. Ngoài ra, WPF và Silverlight dự kiến ​​sẽ hội tụ trong tương lai.

Chúng tôi đã trải qua tình trạng khó xử tương tự này khoảng 6 tháng trước tại văn phòng của tôi. Chúng tôi đã bắt đầu một ứng dụng LOB lớn và không có ai trong nhóm có nhiều kinh nghiệm trong WPF hoặc Winforms. Đó là trường hợp, chúng tôi không thể tìm thấy một lý do áp đảo để đi với Winforms và chúng tôi cảm thấy rằng WPF cung cấp cho chúng tôi một tách sạch hơn nhiều mối quan tâm. Chúng tôi quyết định đi với WPF và sử dụng PRISM làm khung ứng dụng. 6 tháng sau, tôi nghĩ chúng tôi đã lựa chọn đúng.

Answer 6

Vì chúng về cơ bản đã bỏ điện thoại di động cho Windows Phone 7, điều này sẽ chỉ sử dụng WPF và XNA làm lớp giao diện người dùng chính của tôi, tôi sẽ phải nói có. Người ta thậm chí có thể xem xét di chuyển này như là một expiriment cho hệ điều hành Windows được triển khai rộng rãi hơn nhiều. Điều đó và hầu hết người dùng yêu thích mờ mắt kẹo IMHO.

Answer 7

Biết cả hai, tôi thực sự hy vọng rằng WPF là tương lai. Windows Forms có các điểm đau đáng kinh ngạc, ví dụ: liên quan đến Ràng buộc dữ liệu và đó là một bộ phim .NET khá mỏng trên rất nhiều nội dung hiện có. Khi tôi phải gỡ lỗi vào các lớp như BindingSource, nó làm tôi sợ hãi. Bây giờ, tôi không biết làm thế nào các lớp WPF nhìn vào bên trong, nhưng Microsoft đang bị ràng buộc để đã học được điều gì đó từ năm 2001 đến năm 2006.

Tôi yêu WPF vì

• styling
• mẫu dữ liệu
• dữ liệu lớp xuất sắc và lần đầu tiên hỗ trợ ràng buộc
• UI declarative thiết lập
• tính atached
• ...

Tôi chỉ có thể hy vọng rằng Microsoft sẽ sử dụng nhiều hơn trong nội bộ công nghệ giao diện người dùng này, do đó làm giảm điểm yếu của nó mà chủ yếu là để thực hiện với hiệu suất. WPF là khá đòi hỏi. Trong VS2010, tôi hy vọng sẽ thấy các nhà thiết kế thể hiện sức mạnh của giao diện người dùng (trình thiết kế Lược đồ XML trong bản Beta đã có vẻ khá hữu ích). Tôi nghĩ rằng một ứng dụng như MS Word sẽ có lợi nhuận rất nhiều từ tất cả các khả năng chuyển đổi của WPF.

Answer 8

WPF là một trò chơi thay đổi đối với tôi. Ứng dụng hàng đầu của công ty tôi là một chương trình WinForms có giao diện người dùng đang xây dựng động tại thời gian chạy từ siêu dữ liệu. Đó là khoảng sáu tháng nỗ lực, tất cả đã nói, để có được giao diện người dùng ngay cả ổn định, hãy để một mình hấp dẫn. Vẫn còn một số lỗi mà tôi không thể khắc phục được, phần lớn là vì mã UI là vô vọng và không thể tránh khỏi gắn liền với mã mô hình dữ liệu.Và đừng khiến tôi bắt đầu với tay cầm cửa sổ.

Bây giờ hệ thống đã được sản xuất trong một năm hoặc lâu hơn, khách hàng đến với tôi với các yêu cầu như "Chúng tôi muốn có thể sắp xếp lại thông tin trên màn hình này bằng cách kéo và thả" và "Có thể chúng tôi có được thông tin này để hiển thị trong lưới trên phần này của tab này không? " và - yêu thích của tôi - "Chúng tôi có thể kiểm tra chính tả và tự động nhắn tin không?" Những yêu cầu đi vào một backlog đó là nhận được khá damn dài.

Tôi mất một lượng thời gian hợp lý để tìm ra cách cấu trúc lại thiết kế của ứng dụng sao cho nó có thể hỗ trợ giao diện người dùng WPF. Tôi đã vật lộn với điều này và trong một năm rưỡi, và tôi chỉ bắt đầu nhận được lực kéo vào nó một khi tôi đã thoát ra khỏi các cuốn sách WPF tôi đã làm việc từ và học MVVM .) Một khi tôi đã làm, kết quả là ngoạn mục.

Mã đơn giản hơn rất nhiều. Có ít logic hơn để gỡ lỗi. Mọi thứ trong giao diện người dùng là nhiều hơn nhanh hơn, điều quan trọng vì toàn bộ lý do đây là ứng dụng dành cho máy tính để bàn ngay từ đầu là chúng tôi cần một giao diện người dùng rất nhạy. Chương trình của tôi có thể tạo hàng nghìn điều khiển giao diện người dùng mà không phải lo lắng về việc xử lý cửa sổ. Sự dễ dàng mà tôi có thể thay đổi giao diện của chương trình là hàm rơi.

(Ví dụ: Giao diện người dùng trình bày DataRow s với nhiều mẫu khác nhau. Vì một màn hình nhất định có thể có hàng chục hàng và con trỏ nhỏ, rất hữu ích để người dùng có thể biết, trong nháy mắt, những gì hàng con trỏ được in Nó đã cho tôi mười phút để thực hiện các phong cách mà bây giờ làm cho khả năng hình ảnh này có sẵn ở khắp mọi nơi trong ứng dụng của tôi. thêm nó vào ứng dụng WinForms của tôi. Cấp, nó sẽ mất nhiều thời gian hơn nếu nó không thể được thực hiện bằng cách thêm hai phong cách. WPF là nghiêm túc không phải là ma thuật.)

Có nhược điểm không? Như cô Palin thích nói, bạn betcha. Duyệt qua một số câu hỏi tôi đã hỏi trên SO - câu hỏi về how a no-op value converter changed the behavior of data binding là một câu hỏi hay. Toàn bộ cách tiếp cận chà xát-bụng-trong-khi-đầu-đầu-đầu-bạn của bạn để gỡ lỗi ràng buộc là khá bực bội, đặc biệt là vì nó rất dễ dàng để có lỗi ràng buộc và thậm chí không biết nó. (Bây giờ tôi vẫn giữ cửa sổ Output trên màn hình mọi lúc để nếu có bất kỳ lỗi ràng buộc nào trong khi tôi đang thử nghiệm, chuyển động của các thông điệp được ghi lại sẽ bắt được mắt của tôi.) Sẽ rất tuyệt khi có thể nhận được một dấu vết ngăn xếp thực sự khi cửa sổ của bạn ném một số XamlParseException. Đừng bắt đầu nói chuyện, tôi có thể nói chuyện suốt đêm.

Và các công cụ! Các công cụ trực quan của Visual Studio để xây dựng giao diện người dùng WPF hoàn toàn vô dụng đối với tôi. Tôi có Blend, và đã sử dụng nó để tái định dạng một điều khiển, nhưng nói chung tôi tìm thấy bằng cách sử dụng Blend để giống như cố gắng để chạy bộ thông qua một đầm lầy đầy hubcaps và baling dây. Tôi chắc chắn rằng nó thực sự tuyệt vời nếu tất cả các bạn biết là Blend, nhưng nếu những gì bạn học đầu tiên là mô hình đối tượng WPF và XAML, hành vi của Blend là khá bí ẩn. Các trình soạn thảo XML trong Visual Studio và Kaxaml cho tôi một chức năng đáng buồn, và chức năng WPF của Resharper là, chúng ta hãy nói, một công việc đang tiến hành. Tôi rất thích sử dụng các công cụ cho WinForms giúp tôi có thể thuận lợi và nhanh chóng xây dựng tổ quạ mã nguồn chậm, kỳ quặc, và không thể duy trì được mà tôi sắp sửa không ưa thích.

Answer 9

WPF là một khuôn khổ tuyệt vời để tạo ứng dụng. Và khi bạn kết hợp nó với một kiến ​​trúc GUI tốt như MVC, MVP hoặc MVVM, nó sẽ trở nên tuyệt vời khi tạo các ứng dụng kinh doanh thú vị với nhiều ứng dụng hơn so với ứng dụng WinForms chuẩn của bạn.

Mặt khác XAML là anh em họ xấu xí đi kèm với WPF. Vấn đề chính với XAML là công cụ. Các công cụ tồi tệ hơn không tồn tại, bởi vì chúng làm cho mọi người nghĩ rằng có một nhà thiết kế WPF như WinForms, khi những người phát triển hầu hết không biết tôi sử dụng tương đương với notepad để phát triển XAML của họ.

Vấn đề dụng cụ khác với XAML là trình biên dịch. XAML chỉ tốt hơn một chút so với dây ma thuật. Trình biên dịch không thể nhận hầu hết các lỗi bạn mắc phải trong XAML và một số lỗi sẽ không làm hỏng ứng dụng của bạn. Thay vào đó, WPF sẽ in một thông báo lỗi đến đầu ra của bạn và tiếp tục.

Answer 10

Khi đặt câu hỏi về công cụ, tôi sẽ thừa nhận rằng việc xây dựng WPF và Silverlight Apps trong thiết kế của Visual Studio 2008 đã yêu cầu khá nhiều chuyên môn để có được quyền. Tuy nhiên, tôi hy vọng bạn sẽ xem xét thiết kế cải tiến trong Visual Studio 2010 - nó có nhiều tính năng hơn mà chúng tôi hy vọng sẽ có ý nghĩa đối với nhà phát triển Windows Forms để xây dựng các biểu mẫu nghiệp vụ, cho dù trong Silverlight hay WPF.

Kiểm tra những đoạn phim này: Data Binding and Forms Tools Styling Tools Futures New Features in Beta 2

Và có được Release Candidate đây:

Nhóm nghiên cứu có một Blog mới here

Tôi hy vọng bạn tìm thấy thông tin này hữu ích - nếu bạn đã thử Visual Studio 2010, tôi rất muốn nghe phản hồi của bạn. Gửi mail cho tôi tại mwthomas tại microsoft dot com.

Cảm ơn Mark Wilson-Thomas Giám đốc chương trình , WPF & Silverlight Designer, Visual Studio

Answer 11

IMHO, Microsoft đã đưa ra một số manh mối về nó con đường tương lai bằng cách phát triển VS 2010 tại WPF.

WPF không còn nữa, không kém hơn WinForms. Nó có một cách hoàn toàn khác biệt và có thể mở rộng của thiết kế UX.