2010-09-14 30 views
5

Tôi sắp tạo ứng dụng WPF. Cho đến nay, uni cách duy nhất mà chúng tôi đã từng thực hiện GUI là có một cửa sổ chính với một tệp mã sau để xử lý các lần nhấp nút của nó, v.v.Windows form/WPF quá lớn, làm thế nào tôi có thể chia nó ra?

Vấn đề của tôi là khi ứng dụng phát triển, GUI phát triển và kích thước của mã đằng sau tệp có thể thực sự vượt khỏi tầm tay!

Tôi đã xác định được khoảng 15 trường hợp sử dụng chính cho hệ thống của mình (ví dụ: nhập chi tiết, xem chi tiết, v.v ...). Tôi đang tạo một cửa sổ chính (kích thước: 480x320) bao gồm 15 màn hình riêng biệt (một cho mỗi trường hợp sử dụng). Điều này có thể đạt được với một TabControl trung tâm và kéo dài, với 15 TabItem. Hoặc nhiều khả năng nó chỉ có thể là một loạt các container lớp, một trên đầu trang của khác (chỉ có một nhìn thấy tại một thời điểm).

Vấn đề là, với 15 màn hình riêng biệt, tập tin mã của tôi sẽ trở nên rất lớn (chưa kể đến tập tin xaml!): Juggling giữa các trạng thái - làm 14 bị sập/ẩn và hiển thị, Xử lý các điều khiển cho 15 màn hình khác nhau.

Có cách nào để có 15 biểu mẫu riêng biệt, mỗi tệp có tệp mã-đằng sau riêng của nó, thay vì 15 TabItems trên một biểu mẫu và sau đó có một công cụ chính tạo và loại bỏ chúng khi cần thiết? Ofcourse, nó sẽ xuất hiện như thể nó là một hình thức, không phải 15 pop up.

Làm cách nào để giải quyết vấn đề này? Làm thế nào bạn sẽ đối phó với vấn đề của xaml và mã-đằng sau các tập tin có hàng ngàn dòng dài?

Trả lời

5

bản năng của bạn là tốt: bạn không muốn đặt mọi thứ trong một cửa sổ. Bạn sẽ tốt hơn khi đặt từng màn hình 15 "trong tệp XAML của chính nó, dưới dạng điều khiển người dùng hoặc trang.

Nếu điều hướng kiểu trình duyệt web có ý nghĩa đối với ứng dụng của bạn, hãy xem lớp Page. Nếu bạn đặt StartupUri của Ứng dụng để trỏ đến Trang (thay vì Cửa sổ), thì bạn sẽ tự động nhận được cửa sổ có nút Quay lại và Chuyển tiếp và bạn có thể sử dụng Hyperlink s (đặt thuộc tính NavigateUri để trỏ đến Trang khác) hoặc các phương pháp của NavigationService để điều hướng đến các trang mới.

Nếu bạn không muốn nút Quay lại và Chuyển tiếp, sau đó đặt từng "màn hình" vào riêng UserControl và thêm một số logic tối thiểu vào Cửa sổ chính để hiển thị và ẩn chúng. Hoặc nếu bạn đang sử dụng MVVM, bạn có thể thiết lập một số phép thuật nơi bạn chỉ cần thay đổi Cửa sổ DataContext (hoặc tốt hơn, một thuộc tính trên ViewModel cấp ứng dụng của bạn) và nó tự động tải và hiển thị UserControl chính xác (xem DataTemplate s, hoặc xem video dưới đây). Tôi cũng khuyên bạn nên sử dụng MVVM để cố gắng viết ít mã nhất có thể (lý tưởng là không có gì cả - không phải lúc nào cũng đạt được, nhưng bạn sẽ học được rất nhiều bằng cách thử). Điều đó làm cho XAML tấn dễ dàng hơn để tái cấu trúc. Nếu sau đó bạn quyết định rằng một trong các Grids của bạn có quá nhiều thứ trên đó, bạn có thể chỉ cần cắt và dán nó vào một UserControl mới, mà không cần tốn nhiều thời gian để tháo gỡ tất cả các codebehind.

Vì có vẻ như bạn không quen với mẫu MVVM, video này có thể đi qua đầu bạn, nhưng tôi không thể đề xuất cuộc trò chuyện MIX2010 "Build Your Own MVVM Framework". Đó là một mắt mở trên những gì MVVM có thể làm, và có một số ý tưởng vững chắc về cách quản lý điều hướng giữa các UserControls khác nhau. (Nó cũng có liên kết đến một cuộc trò chuyện giới thiệu tới MVVM.)

1

Bạn nên tạo mỗi màn hình dưới dạng UserControl và tham chiếu trong MainWindow xaml của bạn.

Tuy nhiên, có vẻ như bạn có lỗ hổng thiết kế rất lớn trong ứng dụng của mình, tức là có logic trong giao diện người dùng. Các tập tin mã phía sau là không có để lái xe ứng dụng hoặc logic của bạn, nó là có để lái xe giao diện người dùng của bạn! Bạn có thể muốn xem xét mô hình MVC và Dependency Injection để giải quyết vấn đề này.

Wpf Application Framework sẽ là khởi đầu cho điều đó.

+0

+1 để đề xuất phương pháp tốt hơn –

+0

một số trình xử lý sẽ chịu trách nhiệm về mọi logic, hoặc sẽ tham chiếu dll .. tôi chỉ nghĩ rằng nó sẽ được tốt đẹp/phù hợp để cũng chia gui lên bởi các trường hợp sử dụng tôi đã đưa ra trong phân tích. – Mikey

+0

p.s. nhìn vào UserControl và cho bạn biết, cảm ơn !! – Mikey

-1

Xét về các tập tin mã phía sau, bạn có thể sử dụng các thẻ #region để cho phép bạn sụp đổ và mở rộng màn hình khác nhau ... Mặc dù, tách nó ra một cách logic là một cách tiếp cận tốt hơn nếu có thể

+1

Tôi đã gặp phải điều này trước đây và nó luôn luôn đánh tôi như là giống như quét bụi bẩn dưới tấm thảm. –

+0

Tôi không đồng ý, nó giúp bạn sắp xếp một cách hợp lý mã của bạn - nhóm các xử lý sự kiện của bạn, các thuộc tính của bạn, vv .. –

+0

các khu vực rất hữu ích khi lớp học trở nên đủ lớn, nhưng nếu nó đủ lớn đến mức các vùng là không thể thiếu, thì có thể là lớp cần tái cấu trúc. Trường hợp mà tôi gặp phải là nơi bạn mở một tệp và có vẻ như nó vừa với hai màn hình. Sau đó, bạn mở rộng một vài khu vực; được rồi, giờ có thể là một tá. Ồ, nhưng chờ đã, có những vùng bên trong những khu vực đó; trên thực tế, những màn hình 'hai' này có hàng nghìn dòng. Tất cả các mã này trong một lớp tạo ra nhiều cơ hội cho khớp nối chặt chẽ và bây giờ rất khó để kiểm tra bất kỳ một mảnh trong sự cô lập. –

-2

Bạn có thể làm cho lớp học của bạn partial và chia thành các tệp riêng biệt.

+0

'partial' không phải là không thực sự [áp dụng] (http://stackoverflow.com/q/17250559/1997232) trong trường hợp của xaml và đó là một gợi ý nghèo trong trường hợp winforms như bạn sẽ phải chăm sóc về tất cả các thành viên (ví dụ: tên trường) không gây trở ngại cho nhau (thiếu đóng gói). – Sinatr

6

Nếu bạn sắp bắt đầu sử dụng WPF, bạn chắc chắn nên xem mẫu thiết kế MVVMcommanding. Bạn cũng nên xem xét sử dụng tiêm phụ thuộc, thông qua một container IOC, nó là khá dễ dàng để thiết lập, đây là một tuyệt vời tutorial. Trong ví dụ của bạn, có thể tạo một chế độ xem (điều khiển người dùng) xuất hiện trên trang tab có liên quan, chế độ xem đó sẽ có lớp mô hình chế độ xem có liên quan riêng cung cấp dữ liệu và xử lý bất kỳ tương tác nào thông qua các lệnh. Mỗi mô hình khung nhìn sẽ bị ràng buộc với khung nhìn của nó thông qua vùng chứa IOC, do đó làm cho việc thay đổi hành vi của giao diện người dùng trở nên dễ dàng hơn.

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