Tôi đã làm nghề tự do trong một thời gian dài và gần 90% dự án là về Java Swing (ứng dụng dành cho máy tính để bàn). Ngoài ra rất nhiều dự án liên quan đến việc di chuyển từ các ngôn ngữ như Visual Fox Pro sang Java, nó là một nỗi đau, bởi vì phần cứng không nghĩ đến logic đã được thực hiện, phần khó là lấy mã đó là một mớ hỗn độn và biến nó thành thành một mã đẹp mắt theo các thực hành tốt và sử dụng các mẫu thiết kế, đó là lý do tại sao bạn nên tạo một lược đồ hoặc bản đồ trong tâm trí của mình cách bạn có thể tách mã của mình theo các khái niệm về Mô hình, Chế độ xem, Bộ điều khiển.
MVC như đã đề cập sẽ giúp bạn có mã đẹp, dễ bảo trì và dễ đọc, cũng như bạn tuân theo các mô hình lập trình và thực hành tốt.
Xem: Rõ ràng, phần tương tác với người dùng (giao diện người dùng), trong trường hợp Swing, cửa sổ, khung, bảng và tất cả mã liên quan đến các thành phần đồ họa bạn cần cho ứng dụng của mình.
Bộ điều khiển: Khẳng định cốt lõi hoặc logic nghiệp vụ bạn đã thiết lập cho ứng dụng của mình, trong "lớp" này, bạn nên bao gồm chức năng và "cách ứng dụng của tôi sẽ đạt được mục tiêu?".
Mô hình: Liên quan đến dữ liệu bạn quản lý, ví dụ: các thực thể và lớp học đại diện cho dữ liệu bạn muốn quản lý hoặc bảo trì.
Áp dụng MVC không quá khó, nhưng như tôi đã đề cập, đôi khi bạn phải di chuyển mã của bạn từ cấu trúc MVC không áp dụng sang ứng dụng có cấu trúc MVC. Nó dễ dàng hơn để bắt đầu mã hóa bằng cách sử dụng MVC.
Cách tôi quen với việc này là sử dụng maven và tách ứng dụng của tôi thành "mô-đun" nhỏ, tất nhiên, bạn không cần maven, tôi thấy nó hữu ích trong thời điểm đó, nhưng trong mọi trường hợp bạn có thể cố gắng thực hành hoặc làm quen với MVC bằng cách tách ứng dụng của bạn thành các dự án nhỏ, ví dụ:
Java Project 1: application-data-model (chứa tất cả mã liên quan đến quản lý dữ liệu: thực thể, dtos, bean, daos)
Java Project 2: ứng dụng lõi điều khiển (chứa tất cả logic nghiệp vụ và chức năng, bạn có thể sử dụng mẫu mặt tiền ở đây nếu bạn muốn làm cho mã của mình "minh bạch" hơn khi bạn liên quan với chế độ xem của mình)
Java Dự án 3: Ứng dụng-view-ui (chứa tất cả các tấm, khung và các thành phần đồ họa)
Làm việc theo cách này đã giúp tôi (và buộc tôi) để có được sử dụng để tách mã của tôi và giữ một mắt trên những gì thực sự quan trọng đối với dự án tôi đang làm việc. Ví dụ, nếu tôi đang sử dụng mô hình dữ liệu ứng dụng, tôi tập trung vào mô hình dữ liệu, tôi không suy nghĩ về logic nghiệp vụ cũng như giao diện đồ họa.
Giải thích dài, có thể ai đó có thể làm tốt hơn, nhưng hy vọng tôi có thể giúp bạn hoặc ít nhất đã trao cho bạn một bàn tay với điều này.
Trân trọng.
Chào mừng bạn đến với tổ ong. Swing không kết hợp mô hình MVC cho phép "VC" được ảo hóa thành một thành phần duy nhất. Tốt hay xấu là không liên quan, đó chỉ là nó như thế nào. Những gì nó làm là thử và tách dữ liệu khỏi khung nhìn. Có một số trường nghĩ rằng nhà nước bạn nên loại bỏ các yếu tố "kiểm soát" ra khỏi tầm nhìn vào lớp riêng của nó, cá nhân tôi nghĩ rằng điều này chỉ làm tăng sự phức tạp và mời thêm nhiều vấn đề sau đó nó có giá trị - IMHO. Nói chung, chế độ xem/bộ điều khiển của bạn sẽ không bao giờ có thể trực tiếp thay đổi dữ liệu, đó là trách nhiệm của mô hình - IMHO – MadProgrammer
Ah, cảm ơn bạn. Điều này làm cho mọi thứ rõ ràng hơn một chút. Tuy nhiên, bạn sẽ đồng ý rằng nó có ý nghĩa để giới thiệu một bộ điều khiển riêng biệt nếu việc thực hiện GUI có khả năng thay đổi (ví dụ SWT)? Quá tệ Tôi không thể nâng cao nhận xét của bạn - chưa có danh tiếng :) –
Bộ điều khiển riêng sẽ chỉ có ý nghĩa nếu API/khung làm việc theo kiểu tương tự, có một số loại giao diện. Điều đó nói rằng, nếu bạn viết bộ điều khiển của bạn bằng cách sử dụng cùng một mô hình như các mô hình đã được viết (tức là bắt đầu với một giao diện, chuyển sang triển khai trừu tượng và sau đó cho phép triển khai nhiều bê tông), nó sẽ khả thi. Nó sẽ cần phải là một hành động cân bằng được cân nhắc, nhưng thấy như tôi muốn trừu tượng mọi thứ để việc thực hiện không biết với những người sử dụng nó, vâng, tôi sẽ coi đó là một ý tưởng hợp lý – MadProgrammer