Làm thế nào để tăng tốc độ phát triển WPF

Question

Tôi đã phát triển với WPF trong nhiều tháng nay. Đó là một khuôn khổ tuyệt vời và tôi có thể làm những thứ tao nhã, ưa thích mà sẽ khó khăn hơn rất nhiều với WinForms.

Tuy nhiên, tôi có cảm giác rằng đối với loại ứng dụng "dòng doanh nghiệp" bình thường mà không có bất kỳ yêu cầu giao diện người dùng đặc biệt nào, nó vẫn mất nhiều thời gian hơn để mã giao diện người dùng trong XAML hơn là kéo và thả nó vào WinForms. Ví dụ, trong WinForms, tôi sẽ chỉ thả một nhãn bổ sung và một hộp văn bản bổ sung trên biểu mẫu và sắp xếp mọi thứ (sử dụng đường dây trợ giúp) cho đến khi nó trông đẹp. Trong WPF, tôi sẽ bắt đầu bằng cách tính ra các thuộc tính của nhãn và hộp văn bản hiện có thành một kiểu, vì vậy tôi có thể tái sử dụng chúng; suy nghĩ về các yếu tố bố trí phù hợp nhất, có thể refactor một số dockpanels/stackpanels vào một lưới (hoặc ngược lại); thử các giá trị khác nhau cho lợi nhuận vv Mặc dù tôi có rất nhiều kinh nghiệm trong WPF, nó vẫn mất một thời gian dài.

Tôi biết rằng tôi chỉ có thể quên "sạch XAML" và sử dụng trình thiết kế GUI trong Visual Studio 2008 (chỉ hoàn toàn định vị mọi thứ bên trong một lưới lớn), nhưng tôi sợ rằng tôi sẽ mất rất nhiều lợi thế XAML cung cấp bằng cách làm điều đó.

Bạn đã trải nghiệm điều gì đó tương tự? Nếu có, bạn đã làm gì để tăng tốc độ phát triển WPF hàng ngày?

Answer 1

Những gì tôi làm để tăng tốc độ phát triển hàng ngày WPF:

1. Bỏ qua xem và cảm nhận càng lâu càng tốt. Lý tưởng nhất, tinh chỉnh sắp xếp và lề và xác định phong cách là điều cuối cùng tôi làm.

2. Sử dụng DockPanel trước khi sử dụng Lưới và Lưới trước khi sử dụng StackPanel.

3. Khi sử dụng Lưới, hãy gắn kích thước mọi thứ. Tôi sẽ quay lại và sửa lỗi này sau, nhưng trong quá trình tạo mẫu, có một ý tưởng rõ ràng về việc có bao nhiêu hàng và cột mà Grid thực sự có là rất hữu ích.

4. Nguyên mẫu trong Kaxaml, kết thúc trong Expression Blend, kiểm tra trong Visual Studio. Tìm ra một phương pháp cho việc này đã mất rất nhiều thời gian, và nó vẫn còn rất nhiều công việc đang được tiến hành. Nhưng Kaxaml là tuyệt vời cho một cách nhanh chóng nhìn thấy như thế nào một nguyên mẫu XAML sẽ hành xử, và Blend là tuyệt vời cho việc làm ra các hình ảnh và đóng gói những thứ vào điều khiển và phong cách người dùng.

5. Khi sử dụng Blend, không tạo bố cục trong bảng vẽ, tạo chúng trong đường viền đối tượng. Khi tôi lần đầu tiên phát triển một giao diện người dùng WPF, cấu trúc phân cấp của các đối tượng là quan trọng hơn hàng trăm lần so với giao diện trên màn hình. Tôi vẫn đang học cách làm điều này, và có vẻ như có thể một khi tôi có đủ tốt ở đó, tôi sẽ không cần phải làm mẫu trong Kaxaml nữa.

6. Làm việc trên điều nhỏ nhất có thể. Điều này đòi hỏi rất nhiều kỷ luật. Tôi có một tập tin XAML phức tạp, và tôi quyết định rằng tôi cần chỉnh sửa mẫu điều khiển Việc đầu tiên cần làm là tạo một tệp XAML nhỏ với điều khiển đó trong đó và chỉnh sửa mẫu điều khiển ở đó. Sự cám dỗ để làm việc như thế này tại chỗ rất mạnh, vì việc chỉnh sửa mẫu điều khiển chỉ là một cú nhấp chuột phải. Đừng làm thế.

7. Thậm chí không nghĩ đến việc có nên phát triển mô hình xem cho ứng dụng nhỏ bé một lần của tôi hay không. Tôi nên.

8. Tìm hiểu Blend. Thực sự, thực sự tìm hiểu nó. Tìm hiểu tất cả các biểu tượng nhỏ bao quanh đối tượng được chọn có nghĩa là gì và chú ý đến chúng. (Đây là một phím tắt: Tôi đã không đặt lề trên điều đó, nhưng Blend đã làm. Đó là câu trả lời cho có lẽ 30% của tôi "những gì địa ngục là làm gì bây giờ?" Câu hỏi.) Sử dụng giao diện người dùng Blend ngay cả khi tôi biết sẽ nhanh hơn khi chỉnh sửa XAML bằng tay. Đây lại là vấn đề kỷ luật, chống lại sự cám dỗ để hoàn thành nó ngay bây giờ để tôi có thể cải thiện khả năng của mình để đạt được nhiều hơn về nó sau này.

Answer 2

Nếu bạn sử dụng VS2010, tôi nghĩ nhà thiết kế trực quan cho XAML giờ đây tốt hơn và tôi nghĩ sẽ mang lại thời gian phát triển phù hợp hơn với phát triển winforms cổ điển.

Nếu bạn vẫn cần nhắm mục tiêu .NET 3.5, bạn có thể thiết lập giải pháp để biên dịch thành 3,5 thay vì 4.0. Đây có thể là một lựa chọn tốt cho bạn nếu bạn chưa sử dụng VS2010.

Answer 3

Đó là kinda như nói "Táo thái lát là dễ dàng để thực hiện, nhưng bánh táo ngon hơn. Làm thế nào tôi có thể làm cho chiếc bánh táo dễ dàng như tôi có thể cắt táo?" Vâng, bạn có thể làm cho nó dễ dàng hơn bằng cách sử dụng vỏ bánh làm sẵn hoặc mua táo thái lát, nhưng nó sẽ không bao giờ được dễ dàng như vậy, bởi vì cho phép đối mặt với nó, bạn đang làm một cái gì đó phức tạp hơn và có khả năng ngon hơn.

Có vẻ như việc tạo kiểu cho bạn. Bạn có thể khởi đầu nhanh hơn nếu bạn chỉ nhập cùng một kiểu với mọi dự án. Thông thường tôi bay ngay khi tôi có tất cả phong cách của mình.

Nếu không, cách duy nhất để làm cho dễ dàng như việc kéo và thả trình thiết kế WinForms là sử dụng trình kéo WPF kéo và thả.

Answer 4

Tôi cảm thấy nỗi đau của bạn ... Mỗi lần chúng tôi thêm trường mới vào cơ sở dữ liệu, một TextBox/ComboBox khác phải được thực hiện trên biểu mẫu. Tôi đã thấy rằng việc sử dụng Expression Blend cho phép tôi sắp xếp nhanh hơn. Nhược điểm là sử dụng Blend có xu hướng tạo ra nhiều xaml hơn là viết nó bằng tay, vì vậy tôi thường kết thúc làm sạch xaml một chút.

Cuối cùng, Blend là một nhà thiết kế tốt hơn nhiều so với Visual Studio (2010 bao gồm), do đó, nó nhanh hơn nhiều để làm công việc thiết kế của bạn trong Blend, và công việc phát triển trong VS. (Chỉ cần hai xu của tôi)

Answer 5

Thách thức lớn nhất của tôi tại thời điểm này là tôi luôn nghĩ cách thức giao diện người dùng có thể được tạo động với các mẫu dữ liệu. . Ngoài ra, tôi đã trở nên nhanh hơn bây giờ mà tôi đang quen với các container khác nhau và những điều kỳ quặc của họ. Đó là một công nghệ khác biệt đáng kể mà phải mất thời gian trước khi tôi phát triển bộ công cụ tinh thần thích hợp cho các nhiệm vụ UI hàng ngày của tôi, đặc biệt vì tôi vẫn cần sử dụng WinForms thường xuyên. Tuy nhiên, tôi nghĩ nó chỉ là vấn đề thời gian, trước khi tôi có những mẫu chuẩn mà tôi có thể triển khai nhanh chóng và dễ dàng.

Answer 6

Tôi đã sử dụng WPF trong một vài năm nay - với tốc độ tối ưu, tôi vô hiệu hóa thiết kế xem, sử dụng đoạn mã, intellisense mạnh mẽ (và tất nhiên là ReSharper).

Và sau đó tôi làm mọi thứ đơn giản - tôi đã bỏ qua việc sử dụng bố cục chuẩn cho hầu như mọi thứ - tức là. bit màn hình chính -> DockPanel, ToolBar được gắn trên cùng -> đoạn mã.

Màn hình bật lên -> DockPanel, thanh công cụ được gắn trên đế, phần cố định được cập nhật dưới cùng (nút Lưu và Hủy) - thuộc tính của chế độ xem -> UserControl với lưới, nhãn và thuộc tính.

Để tạo kiểu - trước tiên hãy làm điều đó khi tôi có ít nhất 3 màn hình cho mỗi loại - tạo từ điển tài nguyên cho từng loại. Xác định kiểu chữ phổ biến - Tiêu đề chặn văn bản, v.v. Nhập ResourceDictionary trong mỗi màn hình và áp dụng kiểu.

Áp dụng màu, lề, đệm, v.v. trong App.Xaml với kiểu không có khóa.

Tôi không thể nghĩ ra cách nào nhanh hơn. Ít nhất là đối với tôi, tôi không thực sự cần suy nghĩ khi làm theo cách này (vì vậy, tôi có thể sử dụng trí tuệ của mình sau này cho những thứ phức tạp) - và nó mang lại một "cái nhìn LOB" nhất quán tương đối dễ dàng để tạo kiểu, chủ đề và thay đổi sau này. Về cơ bản nó là vấn đề đánh máy.

Answer 7

Lời khuyên về VS2010 rất tốt; nhà thiết kế trực quan của nó thực sự hữu ích, so với thiết kế XAML của VS2008, vốn kém hơn vô dụng.

Máy PR của Microsoft đẩy mẫu "Model-View-ViewModel" rộng rãi cho các ứng dụng line-of-business, đến mức chúng thực sự đề xuất những thứ có thể lãng phí thời gian của bạn.

Làm không dành hàng giờ cố gắng giầy mọi thứ vào XAML, trừ khi công ty hoặc khách hàng của bạn có quy trình yêu cầu. Nếu bạn có thể viết mã nhanh hơn trong VB hoặc C# và mã vẫn có thể duy trì, có thể kiểm tra và có thể đọc được, hãy thực hiện.

Làm không trở thành thuần túy MVVM; thậm chí không phải Microsoft đã tìm ra sự cân bằng thích hợp cho mô hình này, và thậm chí với các công cụ Silverlight 4, họ đã không đưa ra một bộ công cụ phát triển hay thực tiễn tốt nhất cho mô hình, mặc dù bây giờ đã gần 5 năm kể từ nó được đề xuất đầu tiên; vẫn có những lý do rất hợp lệ để từ bỏ ICommand và INotifyPropertyChanged có lợi cho việc chỉ gọi một phương thức trên ViewModel của bạn từ mã phía sau. Ngoài ra, không có chuyên gia WPF/Silverlight không phải của Microsoft mà tôi đã nghe trong vài tháng qua đã không nói, "Tôi không chắc về MVVM, tôi không phải là người thuần túy".

Tìm số dư và sử dụng XAML cho những gì phù hợp với bạn và C# hoặc VB cho những gì phù hợp với bạn. MS devs trên blog của họ rất thích gọi XAML "đánh dấu", và C# hoặc VB là "mã, không may". Vâng, nếu bạn đang gõ nó vào hoặc đặt nó ra, đó là tất cả các mã, và sự thật là tất cả những gì XAML được giải thích và sau đó biến thành C# hoặc VB trong các tập tin bạn không thể nhìn thấy hoặc dễ dàng chỉnh sửa, trước khi nó được biên dịch xuống . (Ví dụ: Application.g.vb được tạo từ Application.xaml dưới dạng một phần.)

Có cấu trúc XAML như hoạt ảnh và bảng phân cảnh có nhiều dòng để bố trí trong XAML, nhưng trong ngôn ngữ thủ tục chỉ có thể lấy một hoặc hai dòng mã và thực sự dễ đọc hơn, đặc biệt nếu hoạt ảnh phản hồi sự kiện chỉ trong một số điều kiện nhất định. Làm những gì hoạt động tốt nhất.

Ngoài ra, nếu bạn đang mã hóa và tiếp tục nhấn ngoại lệ thời gian chạy không có ý nghĩa, hãy lùi lại một bước, tìm câu trả lời thay thế để bạn hoạt động và thực hiện nó. Hầu hết các lỗi XAML không thể bị bắt bởi Intellisense hoặc trình biên dịch. Có thể đập đầu bạn trong vài tuần để chống lại một vấn đề XAML, có thể được mã hóa trong C# hoặc VB với sự ràng buộc sớm trong một thời gian ngắn hơn tương đối.

Tóm lại, hãy thư giãn và viết mã theo các phương pháp hay nhất của riêng bạn, sử dụng các công cụ VS2010 và bạn có thể tăng tốc độ.