Vai trò EventBus trong GWT

Question

Tôi đã đọc về xử lý sự kiện thú vị này trong GWT bằng EventBus và cho đến nay tôi thực sự thích nó. Nhưng tôi không thực sự nắm bắt được khái niệm khi nào tôi nên sử dụng nó. Tất cả thời gian? Tôi có thể lạm dụng nó không? Tôi có nên sử dụng nó cho mọi thứ liên quan đến sự kiện không? (Giống như giao tiếp giữa chế độ xem và lớp trình bày trong MVP? Hoặc tôi có thể sử dụng nó với sự kiện onMouseMove? Làm thế nào nặng?)

Vì vậy, trong một câu hỏi: Vai trò chính xác của EventBus trong GWT là gì?

Answer 1

Tôi nghĩ sử dụng toàn cầu EventBus cho giao tiếp nội bộ giữa các phần MVP của một widget đơn lẻ có phần quá mức. Điều đó sẽ làm cho widget của bạn phụ thuộc vào eventbus. (Nếu eventbus không nằm trong GWT cốt lõi sẽ không được chấp nhận nhiều hơn.) Tôi xem eventbus là phương tiện truyền thông giữa các widget khác nhau của các phần khác nhau của ứng dụng.

Answer 2

Sẽ thật vô dụng khi sử dụng chế độ xem và trình bày, thay vì chỉ có người trình bày gọi trực tiếp phương thức xem.

Tôi tin EventBus là tốt khi các thành phần không tham chiếu lẫn nhau, ví dụ như trình bày của 2 màn hình khác nhau.

Answer 3

Bạn có thể đã xem bản trình bày Google I/O này: Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App.

Nó bao gồm các kỹ thuật gọn gàng để làm việc với một dự án GWT lớn dễ quản lý hơn, như sử dụng Mẫu lệnh cho các cuộc gọi RPC, mẫu MVP, Dependency Injection và các thành phần tách bằng mẫu EventBus. Bây giờ có một số khuôn khổ GWT mà thực hiện những mô hình, (gwt-văn cho mẫu Command, gwt-người dẫn chương trình và gwt-platform cho MVP, GIN & Guice cho DI) nhưng điều tôi thích về EventBus khái niệm là nó là một phần của khuôn khổ GWT cốt lõi (HandlerManager), vì vậy tôi không phải thêm phụ thuộc vào các dự án GWT nhỏ hơn.

Tôi nghĩ khái niệm EventBus có liên quan đến Quan sát mẫu thiết kế theo nghĩa là bạn đang tách các thành phần Xem chịu trách nhiệm cho việc nhập người dùng từ các thành phần Trình bày cần được thông báo về các hành động đó. Vấn đề là ListBox của bạn không cần phải biết về tất cả các thành phần quan tâm đến sự thay đổi trạng thái của nó, nó chỉ kích hoạt một sự kiện cho EventBus, và các thành phần quan tâm sẽ nhận được sự kiện đó và hành động theo ý muốn.

Tôi không nghĩ bạn luôn phải làm mọi thứ thông qua trường hợp HandlerManager. Giả sử bạn có một tiện ích con tùy chỉnh DateRangePicker, cho phép người dùng chọn phạm vi ngày tùy chỉnh. Bất cứ khi nào một phạm vi ngày được chọn, các widget có thể làm một cái gì đó như thế này trong phương pháp onSomethingChanged() của nó:

NativeEvent event = Document.get().createChangeEvent(); 
DomEvent.fireNativeEvent(event, this); 

Sau đó, các thành phần quan tâm đến sự thay đổi lựa chọn phạm vi ngày chỉ có thể đăng ký callbacks hander đến các trường hợp phụ tùng DateRangePicker.

dateRangePicker.addDomHandler(new ChangeHandler(){ 
    @Override 
    public void onChange(ChangeEvent event) { 
     refresh(); 
    } 
}, ChangeEvent.getType()); 

Tôi nghĩ đây là thiết kế được ghép nối lỏng lẻo và không sử dụng trường hợp HandlerManager.

Thiết kế tồi sẽ gọi tất cả các phương thức refresh() của thành phần quan tâm trong phương thức onSomethingChange() của DateRangePicker trên máy chủ thay vì kích hoạt sự kiện. (Hoặc thậm chí tệ hơn: gọi tất cả các phương thức refresh() - es trong, các phương thức onSomethingChange() của đối tượng DateRangePicker.)