MVC hay MVP hay MVVM hay không có gì?

Khi bắt đầu hiện thực một dự án Android, việc đầu tiên chúng ta cần làm là tìm một pattern tốt để xây dựng cấu trúc cho cả project. Dùng MVC hay MVP hay MVVM hay không sài gì hết (^^)? Mỗi pattern đều có những ưu nhược điểm khác nhau và thông qua bài viết này mình hy vọng các bạn sẽ có thêm những cơ sở để lựa chọn cho dự án một pattern phù hợp.

1. Không sử dụng pattern

Nếu chúng ta có một màn hình chỉ hiển thị đôi ba dòng ký tự từ String resource và thêm một button để đi đến màn hình khác hoặc mở link liên kết ra ngoài app thì việc đưa pattern vào liệu có cần thiết?

Việc sử dụng pattern sẽ trở nên không cần thiết khi chúng ta có những ứng dụng chứa các màn hình không yêu cầu lưu lại các trạng thái, không liên kết với Model Layer (gọi API, truy xuất thông tin từ DB hoặc SharedPreferences).

2. MVC - Model View Controller

Vấn đề lớn nhất của MVC là testing. Với MVC thì thật sự là rất khó để có thể test các action của user diễn ra trên UI khi nó đã kết thúc. Chúng ta cần phải giả lập nhiều Android component để có thể test các Activity/Fragment.

Chúng ta sử dụng MVC khi các màn hình có các action dạng One-Direction-Flow (tương tác một chiều). Mọi thao tác của user tác đồng trực tiếp tới Model nhưng kết quả không ảnh hưởng tới UI.

3. MVP - Model View Presenter

Khi chúng ta có màn hình liên kết với Model layer và đợi kết quả trả về để cập nhật UI thì chúng ta cần phải nghĩ đến khả năng testing của pattern. Khi màn hình của chúng ta đơn giản theo dạng Bi-Directional-Flow (tương tác hai chiều) giữa UI và Model, nhưng chỉ cập nhật UI có giới hạn khi có kết quả trả về thì MVP là một lựa chọn không tồi.

Ví dụ khi người dùng thao tác với button, Presenter xử lý sự kiện click bằng cách liên lạc với Model để yêu cầu một message, và nó chờ kết quả trả về, khi nhận nhận được kết quả trả về, Presenter sẽ cập nhật UI. Nếu chúng ta muốn test ngữ cảnh này trong Unit Tests, chúng ta có thể dễ dàng hiện thực bằng cách giả lập Mock-View và Mock-Repository.

Khi UI được tự cập nhật mà không cần các thao tác từ người dùng (ví dụ cập nhật UI khi có sự kiện từ Model Layer) thì MVP không phải là một sự lựa chọn tốt.

4. MVVM - Model View View-Model

Chúng ta có thể dùng MVVP khi màn hình giữ nhiều view và tại một thời điểm cần xử lý nhiều subscribe tương ứng với data-source trong View-Model (data-source có thể là Live-Data, RxJava2 Observable hoặc bất kỳ framework nào).

Một trong những hạn chế của MVVM là sự phức tạp khi sử dụng chung nhiều framework như Rx-Java2, Live-Data, Android-Binding hay Rx-Binding.

Hy vọng với bài viết này, các bạn sẽ thêm những cơ sở để lựa chọn cho mình một pattern phù hợp khi bắt đầu dự án. Hẹn gặp lại các bạn trong bài viết sau!