2009-02-10 46 views
14

Tôi cũng có một ứng dụng dành cho máy tính để bàn được viết bằng Windows Forms có kích thước middling (một vài chục biểu mẫu chính được hỗ trợ bởi 46 bảng trong cơ sở dữ liệu). Tôi đang nghĩ về việc viết lại giao diện người dùng trong WPF, nhưng trước khi tôi đến đó, tôi đã tò mò nếu có bất kỳ câu chuyện chiến tranh nào về việc chuyển đổi như vậy.Di chuyển từ Windows Forms sang WPF ... có đáng không?

tôi sử dụng LLBLGen để tạo ra đối tượng truy cập dữ liệu ở mức độ thấp của tôi, và tôi có một lớp logic kinh doanh trên đó. Các biểu mẫu được databound cho các đối tượng logic nghiệp vụ, mặc dù biểu mẫu chính sử dụng các đối tượng caching để giảm thiểu các chuyến đi vòng trên các tuyến điều hướng phổ biến hơn. Giao diện người dùng không bao giờ nói trực tiếp với cơ sở dữ liệu: luôn thông qua giao diện người dùng -> logic nghiệp vụ -> cấp thấp -> đường dẫn dữ liệu.

Một kiểm soát mà tôi sử dụng chủ yếu là TreeView, đóng vai trò như một hướng dẫn trực quan và công cụ điều hướng khâu dứt điểm. Cây đã được tùy biến rất nhiều với các biểu tượng, màu sắc nổi bật và nó là sự kiểm soát tôi lo lắng nhất về porting.

Có một câu chuyện mà có thể thuyết phục tôi để đi trước và chuyển đổi (hoặc ngược lại, chờ cho đến khi Microsoft là gần gũi hơn với kéo tấm thảm ra từ dưới Windows Forms)?

EDIT: Tôi đã được hỏi trong một chú thích gì động lực để chuyển đổi tôi có. Tôi có một số lo ngại về việc kiểm tra trong tương lai: Tôi có 500.000 dòng mã ban đầu là ASP và VBScript. Chúng tôi đã chuyển chức năng theo thời gian sang ASP.NET và C#, nhưng chỉ khi chúng tôi thực hiện các thay đổi đối với mã. Nhược điểm là chúng tôi đã giảm thiểu chi phí, nhược điểm là một nửa mã vẫn là ASP và VBScript. Tôi lo lắng về một tình huống tương tự phát sinh với các ứng dụng Windows Forms.

Tôi có lo lắng hôm nay về các Biểu mẫu Windows sẽ biến mất không? Thậm chí không gần với nó ... nhưng ứng dụng đang chuyển từ ASP và VBScript sang ASP.NET và C#, có chín năm lịch sử đằng sau nó, và có lẽ sẽ không được thay thế trong thập kỷ này (thay vào đó, đơn giản nó sẽ phát triển). Ứng dụng máy tính để bàn cũng tương tự như một dự án dài hạn với nhiều năm lịch sử.

+0

Rất có thể Microsoft sẽ không ngừng sử dụng WinForms trong một thời gian sắp tới. Trong thực tế, tôi sẽ mạo hiểm để nói rằng nó sẽ không bao giờ bị phản đối cho đến khi API Win32 được thay thế. – user62572

+0

Lý do bạn muốn chuyển đổi là gì? – user62572

+0

Có thể trùng lặp của [WPF so với Windows Forms] (http://stackoverflow.com/questions/202079/wpf-versus-windows-forms) –

Trả lời

3

WPF thật tuyệt. Nó đặc biệt tốt cho việc mở rộng các điều khiển như TreeView với các tùy chỉnh. Bạn có thể thêm một chuỗi như một mục trong TreeControl. Bạn cũng có thể thêm một bảng nhỏ có chứa hình ảnh và một số văn bản trong nhiều phông chữ và màu sắc khác nhau. Hoặc bạn có thể thêm các nút hoặc bất kỳ thứ gì bạn thích. Nó có một hệ thống composability hoàn toàn chung. Tương tự như đối với ListBox, ComboBox, Button, vv Tất cả nội dung hoặc mục con của chúng có thể đơn giản như một chuỗi hoặc phức tạp như trình xem tài liệu nhiều trang với các nút thu phóng (nếu bạn muốn).

Nhưng cách duy nhất để tìm hiểu là thử chuyển một trong các biểu mẫu của bạn. Nó không phải là quá khó khăn để làm cho một cửa sổ WPF mở từ bên trong ứng dụng hiện tại của bạn. Tôi bắt đầu sử dụng WPF bằng cách tạo các bảng GUI mới được lưu trữ bên trong ứng dụng C++ Win32. Cuối cùng, WPF là con đường để chúng tôi chuyển đổi và tạo ra lớp vỏ ngoài WPF, với một số hộp thoại cổ vẫn được thực hiện bởi mã C++ cũ, nơi chúng tôi không thể làm phiền để viết lại chúng (có lẽ chính xác là những gì sẽ xảy ra với Visual Studio 2010).

+0

Tôi thích ý tưởng của các điều khiển được lưu trữ: nó làm cho một cách miễn phí đau đớn để thử các điều khiển WPF mà không yêu cầu viết lại hoàn chỉnh và giữ các trang giao diện người dùng được mã hóa nhiều hơn theo cách gây hại. – Godeke

+0

Cũng không cảm thấy bạn phải làm mọi thứ trong XAML. Có rất nhiều hype xung quanh trình bày tách và mô hình, nhưng đối với nhiều ứng dụng điều này là không cần thiết hoặc thậm chí có ý nghĩa. Ngoài ra, bạn sẽ phải thuê một nhà thiết kế có kỹ năng XAML. Nếu bạn không định sử dụng, hãy sử dụng ngôn ngữ bạn quen thuộc nhất. –

9

Đối với tôi, WinForms vs quyết định WPF là một đơn giản một - nếu người bình thường sẽ sử dụng nó, giao diện người dùng có thể tạo sự khác biệt giữa một người chiến thắng và người thua cuộc.

Đó chắc chắn là một đường cong học tập dốc. Nhưng tôi đã KHÔNG BAO GIỜ nhận được thực hiện với một ứng dụng WPF đẹp trai và nói "Man, tôi nên đã sử dụng WinForms".

tôi muốn nói đầu tư vào các nỗ lực để làm cho giao diện người dùng của bạn tốt hơn bất cứ khi nào có thể cho khách hàng của bạn, vì vậy có cho WPF nếu đó là trường hợp.

+0

Điều gì làm cho giao diện người dùng WPF vượt trội hơn một giao diện người dùng WinForms trong kinh nghiệm của bạn? I.e, điều gì sẽ là một nơi tốt để chỉ ra làm trình điều khiển ROI? – Godeke

+0

Đồ họa chất lượng cao hơn (độ dốc trên mọi thứ, độ trong suốt, v.v.) và Bảng phân cảnh. Về cơ bản hãy suy nghĩ về việc giảm thiểu một cửa sổ - nếu nó chỉ biến mất và "bay xuống thanh tác vụ". Hoạt ảnh giúp giao tiếp chức năng. – Brandon

+1

Hmmm. Tôi đang ở trong lĩnh vực bảo hiểm: đồng đô la trả về chức năng giao tiếp. Gradients, minh bạch và "cửa sổ bay" giao tiếp quá nhiều glitz và thời gian miễn phí :) – Godeke

8

WPF có đường cong học tập cực kỳ lớn. Nó rất có thể sẽ yêu cầu bạn viết lại nhiều hơn bạn nghĩ chỉ thay đổi giao diện người dùng. Ngoài ra, rất nhiều tính năng mà sẽ làm cho WPF đẹp hơn để sử dụng chỉ không được thực hiện hoặc bao gồm trong WPF được nêu ra. Unlike routeNpingme, tôi đã viết các ứng dụng WPF đẹp và đã nói, "Thật là phí thời gian, tôi nên sử dụng Windows Forms và hoàn thành trong thời gian ít hơn 70%".

CHỈNH SỬA: Ngoài ra, trừ khi Microsoft tìm ra cách để làm cho WPF dễ học hơn, tôi không thấy nó bắt kịp với công chúng. WPF có thể làm một số điều rất hay, nhưng một chút nỗ lực để làm cho nó dễ hiểu hơn thay vì ném đồ vật lên tường sẽ đi một chặng đường dài. Nó sẽ không làm tôi ngạc nhiên một chút khi thấy Microsoft thả WPF cho một cái gì đó dễ dàng hơn để làm việc với trong tương lai không xa. Vì vậy, đừng thay đổi ứng dụng Windows Forms của bạn chỉ vì mục đích thay đổi nó.

+0

Có một khía cạnh cụ thể của đường cong học tập bạn lưu ý (các công cụ thiết kế, databinding chính xác, hiệu suất ... cái gì khác)? – Godeke

+1

XAML và tất cả các sắc thái nhỏ là rào cản chính. Nếu bạn làm hỏng XAML, công cụ hỗ trợ cực kỳ yếu trong việc giúp tìm ra các vấn đề. Thông thường bạn chỉ nhận được một tin nhắn văn bản cho bạn biết có một lỗi nhưng không có dấu hiệu nào cho biết lỗi có thể ở đâu. – Dunk

1

Việc chuyển vùng là một quyết định khó khăn.Vì vậy, chỉ cần một số suy nghĩ để giúp bạn quyết định.

WinForms là OK trong khi bạn làm việc theo các quy tắc và giữ mọi thứ được vẽ như cũ. Nhưng ngay cả vẽ lại đường viền trên một số điều khiển có thể yêu cầu công việc và kỹ năng phức tạp và chính xác, như bạn đã biết từ việc tùy biến cây. Các nhiệm vụ tương tự có thể được thực hiện một cách rất thanh lịch trong WPF.

Ngoài ra, việc ràng buộc dữ liệu trong WPF giúp tôi tiết kiệm rất nhiều thời gian. Về lâu dài, bạn sẽ nghĩ về các kịch bản ràng buộc dữ liệu mà không thể có khả năng điều khiển từ xa trong WinForms mà không cần mã hóa đặc biệt.

Tôi thậm chí không xem xét WinForms cho sự phát triển mới - không có lý do gì để chi phí tùy biến.

+0

Bản vẽ tùy chỉnh duy nhất mà chúng tôi thực hiện là với TreeView và tất cả được thực hiện với bitmap, màu sắc và thay đổi phông chữ (ví dụ: gạch ngang chữ). Phần còn lại là ràng buộc dữ liệu khá đơn giản để kiểm soát chứng khoán, mặc dù tôi có một số hộp thoại "trình soạn thảo" mà tôi muốn sắp xếp hợp lý. – Godeke

5

Ưu điểm:

  • Ridiculously dễ dàng liên kết dữ liệu (phần lớn thời gian)
  • Ridiculously dễ dàng tùy biến giao diện

Nhược điểm:

  • học Rất dốc đường cong
  • Một số lỗi hoặc sự cố rõ ràng . Tương tự như NET 1.0 Windows Forms
  • Ít hoặc không có công cụ hỗ trợ

Theo tôi, WPF chắc chắn sẽ thay thế Windows Forms tại một số điểm. Tuy nhiên, ngay bây giờ các công cụ là điều chính giữ nó trở lại. Tôi không đồng ý với Dunk rằng Microsoft sẽ thả nó cho cái gì khác. Thay đổi nó có, nhưng tôi nghĩ rằng nó ở đây để ở.

Nếu bạn thay đổi ứng dụng của mình để sử dụng WPF ngay bây giờ? Không. Cảm thấy tự do để tìm hiểu WPF nhưng nếu ứng dụng của bạn hoạt động tốt hiện nay, sau đó WPF sẽ không cung cấp cho bạn bất cứ điều gì thêm. Nó chỉ làm cho những gì có thể trong Windows Forms dễ dàng hơn nhiều.

+0

Âm thanh như thời điểm thích hợp để thử nghiệm, nhưng có lẽ chưa đến lúc phải cam kết hoàn toàn. – Godeke

1

Tôi đã bắt đầu giới thiệu các phần tử WPF trong ứng dụng WinForms của mình và cho đến nay đã có rất nhiều thành công.

thành phần chính của ứng dụng là một điều khiển lưới và tôi vẫn chưa tìm thấy rendering văn bản của WPF sắc nét, đủ để trình bày một bảng dữ liệu văn bản quan trọng.

Nhưng ứng dụng có một số bảng bổ sung và phần lớn các bảng này được triển khai bằng WPF.Vì vậy, tôi sẽ cho một lai của WinForms và WPF thông qua điều khiển ElementHost.

Tôi đã tìm thấy tính linh hoạt của WPF để cho phép giao diện người dùng hấp dẫn hơn và có thể sử dụng nhiều hơn, và người dùng của tôi có vẻ rất hài lòng với nó. Trong trường hợp của tôi, nó cũng được chính trị dễ dàng hơn để giới thiệu WPF một bảng tại một thời điểm.

0

Giá trị chính của WPF đối với tôi nằm trong liên kết chứ không phải trong giao diện người dùng thú vị hơn. WPF tồi tệ nhất mà tôi từng thấy là khi mọi người sử dụng WPF chỉ vì nó mới hơn, và đặt tất cả các công việc trong đoạn mã phía sau, bao gồm cả việc không sử dụng ràng buộc. Những gì bạn nhận được là quản lý dữ liệu WinForms. Vì vậy, hãy chắc chắn rằng bạn sẽ sử dụng các ràng buộc tuyệt vời khi bạn làm WPF.

Tôi sẽ chuyển logic nghiệp vụ của OP sang một lớp doanh nghiệp để dễ bảo trì và chuyển đổi. Tôi sẽ không chuyển WinForms sang Xaml trừ khi chức năng Xaml mới là cần thiết, và tốt nhất là không cho đến sau khi chức năng được chuyển.

Các vấn đề liên quan