Giới thiệu Model View Presenter trong Android

Khi chúng ta đang phát triển một ứng dụng phức tạp, chúng ta thường bắt gặp những thách thức mà có lẽ đã được giải quyết trước đó và đã có một số giải pháp khá tuyệt vời.

Các giải pháp như vậy thường được gọi là patterns. Chúng ta thường nói về design patterns và architectural patterns. Chúng đơn giản hóa phát triển và nên sử dụng chúng bất cứ khi nào thích hợp.

Hướng dẫn này sẽ giúp bạn hiểu được tầm quan trọng của một dự án được thiết kế tốt và tại sao kiến trúc tiêu chuẩn của Android không phải là luôn luôn đủ.

Chúng ta sẽ thảo luận về một số vấn đề tiềm năng mà bạn có thể gặp phải khi phát triển các ứng dụng Android và mình sẽ chỉ cho các bạn làm thế nào để giải quyết các vấn đề bằng cách cải thiện khả năng kiểm thử và độ tin cậy của ứng dụng thông qua mô hình Model View Presenter (MVP).

1.Kiến trúc Android

Các thiết kế của một dự án là mối quan tâm ngay từ đầu. Một trong những điều đầu tiên chúng ta nên xem xét là kiến trúc mà chúng ta dự định áp dụng vì nó sẽ xác định cách các yếu tố khác nhau của ứng dụng liên quan đến nhau như thế nào. Nó cũng sẽ thiết lập một số nguyên tắc cơ bản để hướng dẫn chúng ta trong phát triển.

Nói chung, một framework hay SDK hy vọng mọi việc được thực hiện một cách nhất định, nhưng điều đó không phải luôn luôn là một trong những quyền cho một dự án. Đôi khi, không có cách nào xác định trước hoặc đúng làm việc, để lại các quyết định thiết kế lên đến các nhà phát triển. Android SDK hy vọng mọi việc được thực hiện một cách nhất định, nhưng đó không phải là luôn luôn đủ hoặc sự lựa chọn tốt nhất.

Mặc dù Android cung cấp một SDK xuất sắc, mô hình kiến trúc của nó là khá bất thường và có thể dễ dàng có được theo cách của bạn trong thời gian phát triển, đặc biệt là khi xây dựng các ứng dụng phức tạp cần phải được kiểm tra và duy trì trong một thời gian dài. May mắn thay, chúng ta có thể chọn từ nhiều giải pháp kiến trúc để giải quyết vấn đề này.

Vấn đề là gì ?

Đây là một câu hỏi khó. Một số có thể nói rằng không có bất kỳ vấn đề với các kiến trúc được cung cấp bởi Android. Chắc chắn, nó được công việc làm. Nhưng chúng ta có thể làm tốt hơn? Tôi mạnh mẽ tin rằng chúng ta có thể.

Các công cụ được cung cấp bởi Android, với cách bài trí, hoạt động, và các cấu trúc dữ liệu, dường như hướng chúng ta theo hướng mô hình Model View Controller (MVC). MVC là một mô hình rắn thành lập nhằm mục đích cô lập các vai trò khác nhau của ứng dụng. Điều này được gọi là tách quan tâm.

Kiến trúc này tạo ra ba lớp:

Model
View
Controller

Mỗi layer có trách nhiệm một khía cạnh của ứng dụng. Model phản ứng với logic kinh doanh, View là giao diện người dùng, và Controller trung gian Xem tiếp cận với Model.

Nhưng nếu chúng ta phân tích chặt chẽ kiến trúc Android, đặc biệt là mối quan hệ giữa View (Activities, Fragments, vv) và Model (cấu trúc dữ liệu), chúng ta có thể kết luận rằng nó không thể được coi là MVC. Nó hoàn toàn khác với MVC và theo những luật riêng của nó. Nó chắc chắn có thể nhận được theo cách của bạn khi mục tiêu của bạn là để tạo ra các ứng dụng tốt nhất có thể.

Cụ thể hơn, nếu chúng ta nghĩ về sự kết nối cộng sinh giữa Loaders và Activities hoặc Fragments, bạn có thể hiểu lý do tại sao chúng ta nên chú ý tới kiến trúc của Android. Một Activity hoặc Fragment có trách nhiệm gọi Loader, thứ mà sẽ lấy dữ liệu và gửi trả lại cho cha mẹ của nó. Sự tồn tại của nó là hoàn toàn gắn liền với mẹ của nó và không có sự tách biệt giữa vai trò View (Activity/Fragment) và business logic được thực hiện bởi các Loader.

Chúng ta sử dụng unit test như thế nào, trong một ứng dụng, trong đó dữ liệu (Loader) được kết hợp rất chặt chẽ với các View (Hoạt động hoặc Fragment) nếu bản chất của đơn vị kiểm tra là kiểm tra các mảnh nhỏ nhất có thể của mã? Nếu bạn đang làm việc trong một đội và bạn cần phải thay đổi điều gì đó trong mã của người khác, làm thế nào bạn có thể tìm ra vấn đề nếu dự án không dính vào một mô hình kiến trúc nổi tiếng và bất cứ điều gì có thể là nghĩa đen bất cứ nơi nào?

Giải pháp là gì ?

Chúng tôi có thể giải quyết điều này bằng cách thực hiện một mô hình kiến trúc khác nhau, và may mắn thay, Android SDK cho phép chúng ta lựa chọn giữa nhiều giải pháp. Chúng tôi có thể thu hẹp lựa chọn của chúng tôi đến các giải pháp phù hợp nhất cho Android. Các mô hình Model View Controller (MVC) là một lựa chọn tốt, nhưng một một thậm chí tốt hơn là Model View Presenter (MVP) mô hình liên quan chặt chẽ. MVP đã được phát triển bằng cách sử dụng cơ sở giống như MVC, nhưng với một mô hình hiện đại hơn mà tạo ra một tách thậm chí tốt hơn các mối quan tâm và tối đa hóa khả năng kiểm thử của ứng dụng.

Với kiến trúc Android trong tâm trí (hoặc thiếu một), chúng ta có thể kết luận rằng:

 Android không lo lắng quá nhiều về một tách quan tâm
 nó là tốt nhất để lại kiến trúc của Android cho nó là gì vì nó là có thể dẫn đến các vấn đề trong tương lai
 thiếu một mô hình kiến trúc thích hợp có thể làm cho đơn vị thử nghiệm một nỗi đau thực
 Android cho phép chúng ta lựa chọn giữa một số mô hình kiến trúc thay thế
 Model View Presenter (MVP) là một trong những giải pháp tốt nhất có sẵn cho Android

2.Model View Presenter

Như tôi đã đề cập trước đó, tách mối quan tâm không phải là điểm mạnh của Android. May mắn thay, các mô hình Model View Presenter cải thiện này đáng kể. MVP tách ứng dụng thành ba lớp:

Model
View
Presenter

Mỗi một người có trách nhiệm của mình và thông tin liên lạc giữa các lớp được quản lý bởi các Presenter. Các thuyết trình hoạt động như một trung gian hòa giải giữa các bộ phận khác nhau.

• Model tổ chức business logic của ứng dụng. Nó kiểm soát như thế nào dữ liệu có thể được tạo ra, lưu trữ, và sửa đổi.

• View là một giao diện thụ động hiển thị dữ liệu và các tuyến đường hành động dùng cho Presenter.

• Presenter đóng vai trò như người đàn ông trung niên. Nó lấy dữ liệu từ Model và cho thấy nó trong các View. Nó cũng xử lý hành động người dùng mong muốn được nó bằng các View.

Khác nhau giua MVC và MVP

Các mô hình Model View Presenter được dựa trên mô hình Model View Controller. Kể từ khi họ chia sẻ một số khái niệm, nó có thể được khó khăn để phân biệt chúng. Các Presenter và Controller có vai trò tương tự. Chúng có trách nhiệm giao tiếp giữa Model và View. Điều đó nói rằng, Controller không quản lý Model và View như đúng như trình bày không.

Trong mô hình MVC, View lớp có phần thông minh và có thể lấy dữ liệu trực tiếp từ Model. Trong các mô hình MVP, View là hoàn toàn thụ động và dữ liệu luôn được phân phối đến các Xem theo Presenter. Bộ điều khiển trong MVC cũng có thể được chia sẻ giữa nhiều lượt xem. Trong MVP, View và trình bày có một mối quan hệ một-một, do đó, các Presenter được gắn với một View.

 Trong MVP, View không thể truy cập các Model.
 Các thuyết trình được gắn với một Xem đơn.
 Xem là hoàn toàn thụ động trong các mô hình MVP.

Những khác biệt về khái niệm làm cho rằng các mô hình MVP đảm bảo một tách tốt hơn các mối quan tâm và nó cũng làm tăng đáng kể khả năng kiểm thử của ứng dụng bằng cách thúc đẩy một tách lớn hơn trong ba lớp lõi.

Activity, Fragment, and View Objects

Có rất nhiều cách hiểu về cách MVP có thể được thực hiện trên Android. Nhìn chung, mặc dù, hoạt động và các mảnh vỡ được giao vai trò của Xem và chịu trách nhiệm cho việc tạo ra các Presenter và Model. The View cũng là trách nhiệm duy trì mô hình và thuyết trình giữa những thay đổi cấu hình, thông báo cho họ về sự phá hủy cuối cùng của View.

Xem các đối tượng khác, chẳng hạn như RecyclerView, cũng có thể được coi là một phần của lớp View trong MVP. Có một mối quan hệ một-một giữa View và các thuyết trình và các tình huống phức tạp đôi khi có thể yêu cầu nhiều diễn giả.

Tham khảo http://code.tutsplus.com/tutorials/an-introduction-to-model-view-presenter-on-android--cms-26162