Đó là một câu hỏi lớn. Tôi sẽ chia sẻ một số suy nghĩ với bạn Tôi có về chủ đề này và xem những gì đi ra khỏi nó.
Swing có nhiều Model-> View so với Model-> View-> Controller. Vấn đề với Model-> View là các ứng dụng Swing thường phân lớp một đối tượng View, và các đối tượng đó trở thành cả View và Controller cho view đó được tạo thành một. Làm thêm giờ trong các ứng dụng lớn, điều này dẫn đến rất nhiều vấn đề và mã spaghetti.
Điều tôi đã làm bây giờ trong nhiều năm là tạo một đối tượng riêng được gọi là Bộ điều khiển không mở rộng bất kỳ lớp UI nào. Đó là một vật thể đơn giản trong khía cạnh này. Bộ điều khiển này sẽ phụ trách việc khởi tạo các thành phần cấp cao nhất cho Chế độ xem, kết nối người nghe với chế độ xem để phản hồi người dùng và quay lại và thực hiện cuộc gọi vào mô hình để hoàn thành công việc.
Chế độ xem sẽ phân lớp Swing. Chế độ xem có trách nhiệm trả lời các sự kiện chuột, sự kiện bàn phím, v.v. Bất kỳ loại sự kiện Swing cụ thể nào được xử lý trong Chế độ xem. Nó cũng sẽ cung cấp các phương thức mức cao để cập nhật khung nhìn mà bộ điều khiển sẽ sử dụng để gọi lại để cập nhật giao diện người dùng. Các mô hình xoay cổ điển cũng nằm ngoài Chế độ xem vì lựa chọn các thành phần của bạn rất gắn liền với các mô hình bạn sẽ sử dụng. View cũng chịu trách nhiệm gửi các sự kiện mức cao đến Controller, và Controller chịu trách nhiệm trả lời các sự kiện cấp cao đó. Các sự kiện này có thể là UserEvent.ADD, UserEvent.EDIT, AuthenticationEvent.LOG_IN, AuthenticationEvent.LOG_OUT, vv Các sự kiện này là các sự kiện ứng dụng và đọc nhiều hơn như những gì người quản lý sản phẩm có thể nhận ra. Bộ điều khiển không đáp ứng với Mouse, ChangListener, vv Tôi đã thực sự xây dựng EventDispatch và Event framework của riêng tôi vì chúng rất khó mở rộng và sử dụng hiệu quả. Chế độ xem hoạt động như sau:
public void mouseClicked(MouseEvent evt) {
User u = getUserAt(evt.getPoint());
dispatch(new UserEvent(UserEvent.EDIT, u));
}
Trong bộ điều khiển của tôi, tôi có các phương pháp đơn giản được kết nối với các sự kiện đó. Đây có thể là ví dụ về một:
@EventCallback(command = "exit")
public void exit(AppEvent evt) {
onExit();
}
@EventCallback(command = "help.about")
public void showAbout(AppEvent evt) {
audioFinderFrame.showAboutDialog(engine.getLicenseInfo());
}
@EventCallback(command = MediaSourceEvent.START_REFRESH)
public void refreshStarted(final MediaSourceEvent event) {
if(frame != null) frame.refreshMediaSource(event.getSource(), true);
}
Chú thích là tiện ích mở rộng tôi phải thêm phương thức nghe sự kiện nhanh chóng vào nguồn EventDisptach. Nhưng, vấn đề là mỗi phương thức trên bộ điều khiển được gọi từ khung nhìn sử dụng các sự kiện mức cao. Điều này cho phép Bộ điều khiển được phân tách một phần từ cách hiển thị khung nhìn. Phương thức đăng nhập của Controller không phải lo lắng thành phần nào tạo nên khung nhìn. Anh ta chỉ nhận được một sự kiện và thực hiện công việc. Bộ điều khiển chịu trách nhiệm về dòng chảy của ứng dụng.
Kể từ khi hệ thống sự kiện được ly dị từ Swing tôi tái sử dụng nó trong các lớp mô hình để mô hình có thể gửi các sự kiện trở lại Controller, và Controller có thể chuyển tiếp những thay đổi đó đến giao diện người dùng.
Mô hình và Bộ điều khiển là POJO. Họ hiểu sự kiện, nhưng đó là nó. Mô hình là logic của ứng dụng bao gồm một mức DAO, các dịch vụ có thể thực hiện các công việc nền, bất kỳ lớp dịch vụ nào nói chuyện với máy chủ và các đối tượng mà hầu hết mọi người có thể nói là DTO.Tôi không quy định khái niệm rằng DTO chỉ nên là các cấu trúc getter/setter đơn giản. Tôi cho phép một số logic trong đó bởi vì chúng là một thứ nổi giữa tất cả các lớp. Bởi vì mỗi lớp đều có quyền truy cập vào chúng, chúng cung cấp một vị trí tốt để tập trung logic mà mỗi lớp có thể tái sử dụng. View, Controller và Model có thể truy cập các phương thức này, vậy tại sao không đặt chúng vào đối tượng di chuyển giữa chúng.
Thông thường logic này gần với logic nghiệp vụ hoặc logic bảo trì mô hình. Tôi cẩn thận về việc ghép các hệ thống kiến trúc lớn hơn với các phương thức này. Các phương thức này sẽ không nói chuyện với cơ sở dữ liệu, hoặc gọi các phương thức phía máy chủ để chúng không mang các tham chiếu trở lại các phần kiến trúc lớn hơn. Họ có tất cả những ưu điểm của DTO: ánh sáng, dễ dàng xây dựng, phụ thuộc thấp, nhưng vẫn duy trì các nguyên tắc của Thiết kế hướng đối tượng: đóng gói, tái sử dụng và ẩn thông tin.
Tôi cũng đã bắt đầu sử dụng Spring để nối các phần của mô hình với các phụ thuộc và phụ thuộc của bộ điều khiển trên mô hình. Tôi đã tìm thấy mô hình này hoạt động rất tốt và nó dễ chịu hơn nhiều so với việc không sử dụng nó. Thật tuyệt khi có quyền truy cập vào các công nghệ như các mẫu Spring JDBC và các mẫu JMS nếu tôi đang sử dụng các công nghệ đó. Nhưng, đó là tùy chọn.
Tôi không bao giờ sử dụng lại Bộ điều khiển. Bộ điều khiển là điều cụ thể nhất trong hệ thống của bạn và các tính năng chung chỉ khiến chúng khó duy trì hơn. Các tổng quan thuộc về Chế độ xem và Mô hình vì nó giúp việc phát triển dễ dàng hơn. Vì vậy, các mẫu thiết kế có xu hướng tìm thấy chính mình trên các mặt đó, nhưng hiếm khi trong Bộ điều khiển. Bộ điều khiển là các cuộc gọi phương thức đơn giản qua lại.
Tôi nhận thấy rằng thực hiện điều này đã làm cho việc xây dựng giao diện người dùng Swing dễ dàng hơn nhiều và nhanh chóng hơn. Tôi ít có khả năng tham gia vào các vòng lặp vô hạn từ việc nghe và thao tác hai điều khiển cùng một lúc. Tôi cũng tìm thấy nó dễ dàng hơn để kiểm tra và phá vỡ hệ thống ngoài vì nhiều logic của tôi tồn tại bên ngoài nắm bắt của Swing. Điều đó làm cho việc kiểm tra chức năng có thể không có bộ công cụ khổng lồ cố gắng mô phỏng nhấp chuột, v.v.
Không có nhiều mã ở đây để minh họa cho sự tiếc, nhưng hy vọng điều này sẽ hữu ích.