Loạt bài này sẽ nói về MVC design pattern, cách chúng ta thiết kế các thành phần để hỗ trợ MVC trong Mini-Web-Server.
Mô hình MVC, lưu ý hướng các mũi tên, các bạn có thể sẽ nhìn thấy nhiều hình minh họa khác với số lượng/hướng mũi tên khác nhau. Tôi sẽ giải thích kỹ hơn về điều này khi chúng ta đi vào chi tiết.
Nếu theo dõi blog này và trang Facebook Nam.NET chắc mọi người không lạ gì project Mini-Web-Server (trang github), một web server đơn giản để thông qua đó giới thiệu về những công nghệ, mẫu thiết kế, kiến trúc phổ biến, giúp các bạn hiểu sâu hơn về những gì các bạn đang sử dụng hàng ngày. Hiện tại chúng ta đã có một mini server gọn nhẹ, chạy nhanh và hỗ trợ đầy đủ các method, hỗ trợ HTTPS, các nội dung tĩnh, cho phép viết các hàm phục vụ người dùng giúp phát triển các API, cung cấp đầy đủ session, authentication/authorization thông qua JWT và cookie…
Nhưng điều quan trọng nhất mà chúng ta đạt được (cũng như tôi muốn nhấn mạnh) khi viết Mini-Web-Server không phải là nó đã hỗ trợ những gì, mà lại là việc thêm vào những tính năng mới dễ dàng như thế nào. Thông qua một kiến trúc rõ ràng và nhiều design pattern, chúng ta có một ứng dụng với các module độc lập với nhau, gắn kết với nhau thông qua các policy. Khi thay thế module phân tích các request từ sử dụng Regular Expression sang việc phân tích trực tiếp mảng byte, chuyển từ mô hình sync sang async…, chúng ta hầu như không phải làm gì khác ngoài viết module mới và thay thế với module cũ, tất cả các phần khác đều giữ nguyên. Thông qua một loạt các cơ chế dựa trên “Dependency Inversion” như Callable, Callable filters, middleware… ta có thể mở rộng ra tới chừng nào ta muốn. Và đó là thứ quan trọng nhất mà tôi muốn mang đến cho các bạn thông qua project này.
Tất cả các ứng dụng trong thực tế đều sẽ thay đổi theo thời gian, lớn hơn, nhiều yêu cầu mới phát sinh, mô hình triển khai thay đổi và thậm chí các chức năng cũng thay đổi, do vậy việc quan trọng nhất đối với một người thiết kế đó là làm ra một ứng dụng có thể dễ dàng chỉnh sửa và bảo trì, hơn là làm cho nó chạy đúng. Điều này nghe có vẻ buồn cười nhưng thử nghĩ xem, nếu chỉ để một chương trình chạy đúng (vào một thời điểm cụ thể) thì bạn đâu cần phải thiết kế? Bạn không cần các interface, không cần đa hình, khi thêm một chức năng mới, bạn chỉ việc copy từ một chức năng tương tự đã có và sửa lại một chút… Bạn sẽ có những file mã nguồn, những function hàng ngàn dòng mà đến người viết còn không hiểu nó chạy thế nào, và khi có một yêu cầu mới, bạn chỉ mong ước có thể đập ra làm lại từ đầu. Một chương trình dễ bảo trì sẽ dễ dàng được làm cho chạy đúng, nhưng một chương trình chạy đúng với một thiết kế tồi lại không chắc sẽ chạy đúng mãi (sau khi thêm các chức năng mới hoặc thay đổi trong tương lai).
Quay lại với Mini-Web-Server, chúng ta đã hỗ trợ nhiều tính năng (như quảng cáo :D), nhưng những gì các bạn nhìn thấy chỉ là một trang web đơn giản, với vài tính năng demo. Thực sự mà nói, chừng đó cũng đã đủ để bạn viết một ứng dụng web, với nội dung tĩnh trong các trang HTML, và dữ liệu động được cung cấp bởi các API. Các tính năng cơ bản này cho phép bạn viết các ứng dụng SPA (single page app) dễ dàng, hoặc cung cấp backend API cho một mobile app. Nhưng nếu muốn viết một web app bình thường với nhiều trang thì sao? Có lẽ chúng ta cần thêm một cơ chế khác nữa.
Một lựa chọn phổ biến với người viết web .NET là ASP.NET MVC, một framework cực kỳ mạnh mẽ, hỗ trợ nhiều tính năng và cực kỳ mềm dẻo (flexible), cho phép chúng ta phát triển các ứng dụng với code .NET, render nội dung với Razor, các tham số được tiền xử lý và gửi đến các action, người lập trình hầu như chỉ cần tập trung vào việc viết code xử lý, các request/response sẽ được xử lý tự động thông qua các policy được ASP.NET hỗ trợ… Vì vậy nếu Mini-Web-Server cũng hỗ trợ một mô hình như vậy thì các nhà phát triển sẽ dễ dàng xây dựng các ứng dụng dựa trên “Mini MVC” thay vì ASP.NET MVC :D. Và có lẽ đây sẽ là tính năng lớn nhất mà Mini cung cấp, là một hành trình mất nhiều tháng để hoàn thành, và tôi muốn chia sẻ cùng các bạn hành trình này, từ các bước chúng ta thiết kế, cho đến việc implement, và thậm chí những sai sót khi thiết kế đã dẫn đến những vấn đề gì. A ha! Bạn nghĩ đúng rồi đó! Tôi vẫn thường xuyên sai sót khi thiết kế và cả khi code nữa!
Nhưng trước tiên chúng ta phải hiểu một cách chính xác MVC là gì và nó hoạt động như thế nào.
(hết phần 1)
Đào Hải Nam 