MVC, MVP, MVVM đâu là Design pattern tốt nhất?

Như tiêu đề hôm nay chúng ta sẽ cùng nhau so sánh thử xem giữa MVC, MVP, MVVM đâu là design pattern tốt nhất, đâu là lựa chọn phù hợp để ta có thể bắt tay vào bắt đầu phát triển dự án. MVC, MVP, MVVM đâu là design pattern phù hợp với dự án lớn. MVC, MVP, MVVM đâu là design pattern phù hợp với dự án nhỏ.

Chúng ta sẽ cùng nhau so sánh chúng dựa trên các tiêu chí sau:

– Dễ dàng mở rộng: ta có thể thêm các tính năng mới một cách nhanh chóng.

– Có thể bảo trì một cách dễ dàng: không có nhiều code rác lẫn lộn, không phá vỡ luồng xử lý.

– Dễ dàng kiểm thử.

1. Trường hợp không sử dụng design pattern

Ta sẽ thường chia ra các component chính như sau: Network, View Controller, và View.

Network: thường ta sẽ chứa các API các class kết nối tới API web services.

View Controller: thông thường sẽ chứa các controller cho view như gọi model, xử lý data logic…

View: View sẽ chứa mapping view, event, xử lý data logic…

– Nhược điểm:

Các Activity, fragment sẽ nhanh chóng bị phìng to ra.

Rất khó khăn khi ta phải thêm các tính năng mới, hoặc muốn cập nhật lại 1 tính năng nào đó.

Tất cả xử lý logic để hết trong Activity, rất khó để ta có thể testing.

Xem thêm:

Application và Activity trong Android

Fragment trong lập trình Android

2. MVC- Model View Controller.

Với MVC với 3 component chính là Model, View và Controller:

Trong MVC View có quan hệ mật thiết với controller, bất cứ hành vi nào của người dùng như nhấn button thì view sẽ gọi đến Controller. Controller xử lý tất cả các logic về event view và model là nhân vật luôn đứng sau view. Model sẽ xử lý các nghiệp vụ logic và ném cho View dữ liệu để show lên cho người dùng.

– Ưu điểm :

Không có xử lý logic business trên UI.

– Nhược điểm :

Không thể mở rộng, nó tách rời UI nhưng Model thì không. Controller cũng bị gắn liền với View.

Controller sẽ ngày càng trở lên phức tạp khi View có nhiều tính năng.

3. MVP design pattern.

Với MVP mỗi View ta sẽ có 1 Presenter.

– View: View sẽ làm nhiệm vụ hiển thị, xử lý các action và notify user event qua presenter. Trong Android View thường sẽ được tổ chức với 1 interface View và các Activity hoặc Fragment sẽ implement view.

– Presenter: Presenter sẽ control view hiển thị những gì. Nói cách khác thì Prester sẽ là cầu nối giữa View và Model. Trong MVP View sẽ không còn làm việc trực tiếp với Model giống như MVC.

– Model: Model sẽ phụ trách xử lý data logic và truy cập dữ liệu. Data ở đây có thể là remote đến API services, SQLite, SharedPreferences.

– Ưu điểm: Các nhiệm vụ của từng layer giờ đã được chia ra và rõ ràng hơn. Ta dễ dàng debug cũng như sử dụng unit test. Các Class trên từng layer giờ đã ngắn gọn hơn, ít bug hơn, dễ dàng review code.

– Nhược điểm: Nó sẽ trở lên rườm rà khi ta xây dựng với các ứng dụng nhỏ, hoặc với các Activity đơn giản. Khó sử dụng lại logic code trong Presenter cho các View khác.

4. MVVP MODEL VIEW VIEW-MODEL: 

Trong MVVP sẽ có sự ràng buộc data 2 chiều giữa View và View-Model. Nó cho phép tự động cập nhật data từ View-Model qua View. Thông thường View-Model sử dụng mô hình Observer để thực hiện cập nhật data từ View-Model qua View và ngược lại.

– Thay thế Presenter trong MVP bằng View-Model nhưng không chỉ đơn thuần là vậy.

– Xóa bỏ UI code trong Activity, Fragment.

– View không biết đến Model.

– Data binding sẽ bind View-Model qua Layout.

– View-Model: sẽ đảm nhận công việc đồng bộ dữ liệu từ model lên View. Mối quan hệ giữa View và View-Model là View sẽ được ánh xạ tới View-Model nhưng View-Model lại không biết thông tin gì về View. Nó được ẩn dấu qua cách sử dụng Data-binding và cơ chế của mô hình Observer. Một View-Model có thể được ánh xạ từ nhiều View.

– View: Trong mô hình Observer thì View sẽ là thành phần lắng nghe và emit các event từ người dùng và từ life cycle của View qua View-Model.

Kết Luận:

Mỗi Architechture đều có những điểm mạnh và điểm yếu riêng. Nếu dự án nhỏ ta có thể không cần sử dụng đến bất kỳ Design Pattern nào chỉ cần tổ chức code clear và code helper dễ sử dụng là sẵn sàng chiến các project nhỏ. Nhưng đối với cá dự án lớn team nhiều người thì ta bắt buộc phải lựa chọn một Design Pattern phù hợp.

(Tác giả: Ninh Luyen)

Bình luận

Loading...