Như tiêu đề, bài viết lần này sẽ hướng đến là việc tìm hiểu về mô hình MVP. Nếu là dân lập trình thì MVC, MVP, MVVM… là những cái tên sẽ được nghe ở rất nhiều, và có thể đã từng làm việc dựa trên những kiến trúc này. Tất nhiên, làm việc được với nó không đồng nghĩa với việc hiểu hết tất cả về nó, và mình đã dành 1 thời gian để tìm hiểu thêm về lý thuyết của MVP nên hôm nay trời trong xanh nước trong veo, trong bài viết này, mình sẽ trình bày lại về MVP(tất nhiên là cấu trúc theo project Android) theo những gì còn sót lại sau quá trình tìm hiểu của mình. Hi vọng sẽ truyền đạt lại được cái gì đó có ích cũng như cũng cố lại kiến thức cá nhân :>.
Phần bài viết này sẽ đi qua 2 phần:
I. Giới thiệu mô hình MVP
II. Xây dựng mô hình MVP
Let’s start
I. Giới thiệu về MVP
MVP(Models-View-Presenter) không phải là một kiến trúc mới, và Google cũng khuyến khích sử dụng kiến trúc MVVM chứ ko phải MVP, tuy nhiên MVP vẫn luôn là một lựa chọn tốt của nhiều cá nhân, và riêng mình thấy khi sử dụng Livedata trong MVP thì nó hoàn toàn có thể thay thế MVVM , tổ chức khi bắt tay vào phát triển 1 sản phẩm mang tính lâu dài.
Đi qua các thành phần chính của cấu trúc.
Model
Tầng model là tầng chưa các Entities, hay chứa các đối tượng sử dụng. tầng này sẽ được Presenter sử dụng để mapping data. Tất nhiên nó bao gồm cả việc get data từ service(mình thường gọi là tầng Repository).
View
View là tầng giao diện người dùng(UI), tầng này sẽ bao gồm Fragment, Activity,… dữ liệu sử dụng ở tầng này được lấy từ data và xử lý bởi Presenter, và tất giao tiếp với Presenter sẽ thông qua Interface.
Presenter
Presenter, đây là tâng trung gian giao tiếp Model và View, Có thể ví dụ nó như cục Singum dính đôi giày mình với cái mặt đường( Sáng mới dẫm :’< ), tầng này sẽ có nhiệm vụ xử lý data tầng model và đưa output cho View.
Presenter sẽ thiết kế gồm 1 interface và 1 Implementation ví dụ đơn giản như sau
Ok, 1 presenter cho trang login đơn giản sẽ như vậy, các file này trích từ project mình up ở trên, nên có thể tải về để xem hén.
Chọn MVP ta được gì
Khi chọn một kiến trúc nào đó để xây xựng dự án nó đều có ưu điểm và nhược điểm riêng, ở đây mình sẽ điểm qua những ưu điểm mà tìm hiểu được trên lý thuyết, vì trên thực tế, trãi nghiệm cá nhân về mô hình MVP mình chưa đủ nhiều để tự đút kết được ưu điểm, nhược điểm theo quan điểm cá nhân.
Nhưng mà những cái đọc được nghe có vẻ cũng có lý, nên sẽ được tóm lại như sau:
Ưu điểm
- Việc chia project theo kiến trúc này, các tầng như Presenter và View sẽ được tách nhau ra đảm nhiệm UI và Business Logic, nên việc Unit Test sẽ dễ dàng hơn một phần.
- Presenter sẽ giao tiếp thông qua interface và định nghĩa ở file Implementation, nên việc tái sử dụng code sẽ rất tiện.
- Kiến trúc đơn giản, dễ hiểu và dễ xây dựng.
II. Xây dựng MVP đơn giản
Đọc tới khúc này mà vẫn chưa biết những đoạn code trên trích từ đâu thì nó ở ĐÂY nha :D
Xây dựng project mình sẽ xây dựng như sau.
Tất nhiên là không có một quy định bắt buộc phải đặt tên như thế nào, package phải tên gì tên gì, nhưng để dễ hơn trong quá trình phát triển thì nên đặt tên dễ hiểu, có nghĩa, và mô tả đúng mục đích.
MainActivity sẽ bao gồm 1 danh sách hình ảnh, việc tổ chức code trong các file sẽ như sau
Model
Ở đây mình tạo 1 interface cung cấp data là PhotoRepository
Ở lớp PhotoRepositoryImpl sẽ implement interface này, việc lấy data sẽ có thể xử lý kiểu gì cũng được, có thể là call Api, hay tự tạo một list,…. miễn output cuối cùng trả về 1 List<PhotoModel>
View & Presenter
View ở đây của mình sẽ là MainActivity, đi kèm với nó là một MainActivityPresenter,MainActivityPresenterImpl
Ở MainActivity sẽ implement MainActivityPreenter.View và sử dụng các hàm đã được cung cấp bởi Interface.
Ok, giải thích hơi rườm rà, nhưng cứ men theo project sẽ thông thôi hehe.
Tổng kết
Ok, không có gì để nói nhiều về kiến trúc này, bài viết dựa theo kiến thức và tìm hiểu cá nhân, nếu có sai sót mong được nhận phản hồi để bài viết được phát triển thêm hihi.
Link project: tải tại ĐÂY
Tham khảo:
Nhiều nguồn document trên google
