Bài viết được dịch từ: medium.freecodecamp.com
Ngày càng có nhiều các lập trình viên front-end áp dụng các kiến trúc một chiều (unidirectional architectures). Vậy đâu là tương lai cho hướng tiếp cận Model-View-Controller (MVC) cổ điển?
Đầu tiên hãy xem lại sự phát triển của kiến trúc front-end.
Hơn 4 năm trước, tôi đã làm việc với nhiều dự án web và dành thời gian để kiến trúc front end và tích hợp framework vào chúng.
Trước năm 2010, JavaScript - ngôn ngữ lập trình để viết jQuery - được sử dụng phổ biến để thêm, chỉnh sửa DOM cho các website truyền thống. Các lập trình viên không cần quan tâm tới kiến trúc của chúng. Những thứ như revealing module pattern là đủ tốt cho cấu trúc code của chúng ta.
Chỉ sau năm 2010 chúng ta mới bắt đầu thảo luận về kiến trúc front-end so với back-end. Đây là lúc các lập trình viên bắt đầu nói về các khái niệm như single page application một cách nghiêm túc. Đây cũng là thời điểm các framework như Backbone và Knockout bắt đầu trở nên phổ biến.
Nhiều nguyên tắc được xây dựng xung quanh các framework này vẫn còn khá mới mẻ tại thời điểm đó, các nhà thiết kế của họ đã tìm kiếm nguồn cảm hứng ở nơi khác. Họ đã chán các practice có sẵn được tạo ra cho kiến trúc ở phía server. Và tại thời điểm đó, tất cả các framework phía server đều liên quan tới một phiên bản của mô hình MVC cổ điển (cũng được biết đến như là MV* vì nó có nhiều biến thể).
Khi React.js lần đầu được giới thiệu như một thư viện render, nhiều lập trình viên chế giễu nó bởi vì họ cảm nhận cách nó xử lý với HTML trong JavaScript không giống với cái họ đã quen thuộc. Nhưng họ đã bỏ qua đóng góp quan trọng nhất của React - Kiến trúc dựa trên Component (Component Based Achitecture).
React không phát minh ra component, nhưng nó đã đưa ý tưởng này tiến một bước xa.
Bước đột phá lớn trong kiến trúc đã bị bỏ qua thậm chí cả với Facebook, khi họ quảng cáo React như là "V trong MVC".
Năm 2015 mang đến cho chúng ta một sự thay đổi lớn trong tư duy - từ pattern MVC quen thuộc tới các kiến trúc một chiều (Unidirectional Architectures) và các luồng dữ liệu (Data Flows) có nguồn gốc từ Flux và Functional Reactive Programming, được hỗ trợ bởi các công cụ như Redux hoặc RxJS.
Vậy đâu là lý do làm cho MVC không còn phù hợp?
MVC vẫn là cách tốt nhất trên phía server. Các framework như Rails và Django là ví dụ.
Các vấn đề phát sinh từ thực tế là các nguyên tắc và cách phân chia mà MVC đã giới thiệu trên server không giống như trên client.
Controller-View Coupling
Bên dưới là hình minh họa cách View và Controller tương tác trên server. Chỉ có duy nhất 2 điểm tiếp xúc giữa chúng, cả hai vượt qua ranh giới giữa client và server.
Khi chuyển MVC tới client, đây là một vấn đề. Các controller giống với cái chúng ta gọi là "code-behind". Controller phụ thuộc nhiều và View. Trong hầu hết các framework đã được triển khai, nó thậm chí được tạo bởi View (Ví dụ ng-controller trong Angular).
Ngoài ra, khi bạn nghĩ về Single Responsibility Principle, điều này rõ ràng đã vi phạm các nguyên tắc. Controller ở client phải bao gồm cả even handing và business logic, ở một mức độ nhất định.
Fat Models
Hãy xem xét một chút về loại dữ liệu bạn lưu trữ trong một Model ở phía client.
Một mặt, bạn có dữ liệu như users và products, cái biểu diễn trạng thái ứng dụng (Application State). Mặt khác, bạn cần lưu trữ trạng thái giao diện người dùng (UI State) - những thứ giống như showTab hoặc selectedValue.
Tương tự Controller, Model đã vi phạm Single Responsibility Principle, bởi vì bạn không tách việc quản lý UI State và Application State.
Vậy đâu là lý do các component phù hợp với mô hình này?
Các component là: Views + Event Handling + UI State.
Hình bên dưới cho bạn thấy cách chia mô hình MVC gốc để có các component. Cái ở phía trên đường kẻ chính xác là cái Flux đang cố để giải quyết: quản lý Application State và Business Logic.
Với sự phổ biến của React và kiến trúc dựa trên component (component-based architecture), chúng ta thấy sự nổi lên của các kiến trúc một chiều (unidirectional architectures) để quản lý trạng thái của ứng dụng.
Một trong những lý do 2 kiến trúc này làm việc tốt với nhau là chúng đề cập tới toàn bộ hướng tiếp cận MVC cổ điển. Chúng cũng cung cấp một cách phân chia tốt hơn các thành phần khi xây dựng các kiến trúc font-end.
Nhưng đây không còn là câu chuyện của riêng React. Nếu bạn xem Angular 2, bạn sẽ thấy chính xác pattern tương tự được áp dụng, mặc dù bạn có vài tùy chọn để quản lý trạng thái của ứng dụng giống như ngrx/store.
Thực tế là không phải tất cả mọi thứ MVC có thể làm tốt hơn trên phía client. Nó đã thất bại ngay từ khi bắt đầu. Chúng ta chỉ cần chờ để thấy điều này, mặc dù quá trình này đã diễn ra 5 năm, kiến trúc front-end đã phát triển thành như hiện tại. Tuy nhiên, 5 năm không phải là thời gian dài để có các best practice.
MVC cần thiết khi bắt đầu bởi vì các ứng dụng front end trở lên lớn hơn và phức tạp hơn, và chúng ta không biết cách cấu trúc chúng. Tôi nghĩ nó đã làm tốt nhiệm vụ này, và nó cũng cung cấp một bài học hay về cách lấy một practice tốt từ một bối cảnh (server) và áp dụng tới một bối cảnh khác (client).
Vậy cái gì sẽ nắm giữ tương lai?
Tôi không nghĩ rằng chúng ta sẽ trở lại với kiến trúc MVC cổ điển trong các ứng dụng front end của mình.
Ngày càng có nhiều lập trình viên nhận thấy lợi thế của các kiến trúc một chiều (unidirectional) và component, việc này sẽ tạo ra các thư viện và các công cụ tốt hơn.
Vậy loại kiến trúc này sẽ là giải pháp tốt nhất cho 5 năm tới? Rất có thể, nhưng một lần nữa, không có gì là chắc chắn cả.
5 năm trước, không ai có thể dự đoán cách chúng ta sẽ viết ứng dụng như hiện tại. Vì thế tôi không nghĩ nó là an toàn để đặt cược tương lai ngay lúc này.
Bình luận