Dựa theo một video của google: GoogleWebToolkitBestPractices trong hội nghị Google I/O đã được trình bày với một tuyên bố hoàn toàn bất ngờ: đó là, rằng việc áp dụng mô hình MVC - Là sẽ giúp bạn có gặp rắc rối với một ứng dụng GWT lớn.
Thay vì MVC, các Google Adwords mới UI (IIRC) đội đã sử dụng một mô hình MVP (Model-View-Presenter) mà có nhiều lợi thế hơn MVC: bằng cách xây dựng một ứng dụng bằng cách sử dụng một xe buýt sự kiện vào kênh và xử lý tất cả các sự kiện mà bạn giảm bớt phụ thuộc giữa các mô hình và quan điểm (PropertyChangeListeners nhiều, vv), làm cho code đơn giản, nó cũng làm cho nó dễ dàng hơn nhiều để decouple các lớp và giới thiệu thử nghiệm các đối tượng để
kiểm tra dễ dàng hơn của các mã.
Hình 36 - So sánh MVC và MVP
Trong lập trình web việc tách code xử lí khỏi hệ thống giao diện là rất cần thiết, tạo ra khả năng xử lí độc lập cho giao diện.
Việc tách rời dữ liệu khỏi giao diện cũng sẻ tạo ra được nhiều giao diện khác nhau cho các cách thể hiện khác nhau.
Code xử lý đặt trong UI gây khó khăn cho việc kiểm tra và gây phức tạp và trùng lập code. Việc kiểm tra các UI thường hoặc phải chạy ứng dụng thủ công hoặc sử dụng kịch bản (script) để thực hiện việc tương tác tự động lên các UI, do đó sẽ tốn nhiều chi phí và thời gian hơn để kiểm tra các xử lý bên trong thành phần này. Việc tách các xử lý này ra ngoài ra còn tăng tính tái sử dụng code và dễ bảo trì hơn.
Phương pháp để giải quyết là mô hình MVC (Model-View-Controller) và một mẫu kiến trúc thừa kế là MVP.
(output) và dữ liệu nhập từ người dùng (input) thành những thành phần riêng biệt.
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic).
View là thành phần đảm nhận việc thể hiện những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form... Trên cùng một Model, có thể có nhiều View.
Controller là thành phần đảm nhận việc xử lý đáp trả lại các dữ liệu được đưa vào từ người dùng như các sự kiện chuột, bàn phím, các tương tác lên các control... Controller là cầu nối giữa người dùng và ứng dụng.
Sự phụ thuộc của Model vào các thành phần khác và tại một thời điểm khó xác định điều gì sẽ xảy ra khi đọc code và việc kiểm tra cũng khó khăn hơn.
Kiến trúc MVP dựa trên tư tưởng cơ bản của MVC nhưng với cách tiếp cận khác nhằm khắc phục các hạn chế của MVC cổ điển.
Các thành phần của MVP
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới.
View là thành phần đảm nhận việc thể hiện những dữ liệu của Model và là tổng hợp của các form, control được sử dụng.
Presenter là thành phần đảm nhận các xử lý thể hiện cũng như tương tác đến dữ liệu bên dưới và có thể tương tác để thay đổi View trong quá trình xử lý.
Phối hợp các thành phần
Mẫu kiến trúc MVP tương tự như Passive View nhưng có bổ sung ràng buộc là Presenter chỉ có thể truy cập đến View thông qua interface IView. Điều này giúp Presenter không phụ thuộc đến cài đặt cụ thể của View và có thể dễ dàng kiểm tra Presenter một cách độc lập.
gián tiếp). Hệ quả là chúng ta có một mô hình đa lớp như cấu trúc ở trên theo ý nghĩa các thành phần ở một lớp chỉ phụ thuộc và sử dụng các thành phần ở lớp ngay bên dưới nó.
Với MVP, một View gắn liền với một interface IView. Khi View được tạo ra, nó tạo ra một đối tượng private Presenter và gắn nó vào đối tượng này thông qua IView. Khi một sự kiện xảy ra, View bắt lấy và sau đó kích hoạt một phương thức của Presenter mà sau đó có thể tương tác với Model. Một số sự kiện như bắt đầu hiển thị và đóng của View cũng được gửi tới để Presenter kích hoạt một số phương thức tương ứng, điều này giúp cho một số công việc như khởi tạo và giải phóng dữ liệu cho View được dễ dàng hơn. Model được tổ chức bổ sung một lớp Service nằm bên server để tương tác với Presenter.