Kiến trúc phần mềm MVC: khi nào còn phù hợp

MVC chia một ứng dụng thành mô hình dữ liệu, giao diện hiển thị và phần điều khiển luồng. Nó vẫn phù hợp với ứng dụng web có nhiều màn hình đọc ghi dữ liệu, nhưng bắt đầu cản trở khi luồng nghiệp vụ trải nhiều bước và nhiều ngoại lệ.

Tóm tắt nhanh

• MVC tổ chức mã theo lớp kỹ thuật, không theo nghiệp vụ. Điều này tốt khi màn hình là đơn vị công việc chính, và xấu khi quy trình là đơn vị công việc chính.
• MVC còn phù hợp khi phần lớn thao tác là đọc và ghi dữ liệu theo một màn hình, nghiệp vụ ít bước, và đội còn nhỏ.
• Bốn dấu hiệu MVC đã cản trở: phần điều khiển phình to, mô hình chứa logic hiển thị, một quy trình trải nhiều màn hình, và khó viết kiểm thử cho một luồng.
• Cách xử lý rẻ nhất là thêm một lớp nghiệp vụ giữa điều khiển và mô hình, không phải đổi sang kiến trúc khác.

MVC gồm ba phần nào

Mô hình giữ dữ liệu và quy tắc liên quan tới dữ liệu: một đơn hàng gồm những trường nào, trạng thái nào được chuyển sang trạng thái nào, giá trị nào bắt buộc. Mô hình không biết gì về giao diện.

Giao diện hiển thị dữ liệu và nhận thao tác từ người dùng. Giao diện không tự quyết định dữ liệu thay đổi thế nào; nó chỉ hiển thị và chuyển thao tác đi tiếp.

Điều khiển nhận yêu cầu, gọi phần xử lý phù hợp, rồi chọn giao diện để hiển thị kết quả. Điều khiển là nơi luồng của một yêu cầu được nối lại.

Ba phần này độc lập ở mức lý thuyết. Trong thực tế, phần lớn vấn đề của MVC đến từ một chỗ: ranh giới giữa điều khiển và mô hình bị mờ dần, và logic nghiệp vụ chảy vào cả hai bên.

Khi nào MVC còn phù hợp

MVC còn là lựa chọn tốt trong bốn tình huống cụ thể.

Ứng dụng có nhiều màn hình đọc ghi dữ liệu. Hệ thống quản trị, danh mục sản phẩm, hồ sơ khách hàng, cấu hình. Ở đây mỗi màn hình là một đơn vị công việc trọn vẹn, và MVC ánh xạ gần như trực tiếp: một màn hình, một điều khiển, một mô hình.

Nghiệp vụ ít bước. Khi thêm một bản ghi là một hành động duy nhất, không có nhiều bước trung gian, không có phê duyệt nhiều cấp, thì một lớp điều khiển gọi mô hình là đủ. Thêm lớp nữa chỉ tăng số file phải sửa cho mỗi thay đổi.

Đội còn nhỏ và cần người mới vào nhanh. MVC là mô hình phổ biến nhất trong các framework web, nên người mới thường đã biết. Chi phí đào tạo thấp là một lợi ích thật, đặc biệt với đội dưới năm người.

Hệ thống cần bàn giao cho bên khác vận hành. Một cấu trúc quen thuộc giúp bên nhận đọc mã nhanh hơn. Đây là lý do nhiều dự án chọn MVC dù về lý thuyết có kiến trúc "đẹp" hơn.

Vị trí của MVC trong bức tranh chung được trình bày trong các kiến trúc phần mềm phổ biến, và lý do chọn kiến trúc là chọn chi phí được phân tích trong kiến trúc phần mềm là gì.

Khi nào MVC bắt đầu cản trở

Bốn dấu hiệu dưới đây xuất hiện theo thứ tự này. Dấu hiệu đầu tiên chưa cần đổi kiến trúc; dấu hiệu thứ tư thì đã cần.

Dấu hiệu thứ ba là dấu hiệu nghiêm trọng nhất. Khi một quy trình như duyệt đơn, xử lý khiếu nại hay tính lương trải qua nhiều màn hình, MVC không còn mô tả đúng công việc thật. Mỗi màn hình là một phần của quy trình, nhưng không nơi nào giữ được cái nhìn toàn bộ.

Cách xử lý trong phần lớn trường hợp không phải đổi sang kiến trúc khác. Chỉ cần thêm một lớp nghiệp vụ nằm giữa điều khiển và mô hình: điều khiển chỉ nhận yêu cầu và trả kết quả, lớp nghiệp vụ giữ toàn bộ luồng, mô hình giữ dữ liệu và quy tắc dữ liệu. Cấu trúc này vẫn là MVC ở tầng giao diện, nhưng nghiệp vụ đã có chỗ riêng.

Bốn biến thể của MVC

MVC có nhiều biến thể, và khác biệt giữa chúng chủ yếu là ai xử lý yêu cầu trước.

Biến thể thứ ba là lựa chọn nên dùng khi nghiệp vụ phức tạp. Nó giữ được lợi ích của MVC ở tầng giao diện và giải quyết được điểm yếu lớn nhất của MVC ở tầng nghiệp vụ.

Biến thể thứ tư xuất hiện khi giao diện được tách thành ứng dụng riêng. Lúc đó phần điều khiển thường thu lại thành một tập điểm cuối dữ liệu, và MVC chỉ còn ở phía máy chủ dưới dạng cấu trúc mô-đun. Đây là lúc nên xem lại ranh giới nghiệp vụ thay vì cố giữ MVC ở cả hai phía.

Một ví dụ: màn hình duyệt đơn hàng

Xét một thao tác tưởng như đơn giản: nhân viên bấm duyệt một đơn hàng.

Trong MVC thuần tuý, điều khiển nhận yêu cầu, kiểm tra trạng thái đơn, cập nhật trạng thái, trừ tồn kho, ghi log, rồi trả về giao diện. Năm bước nằm trong một hàm. Khi nghiệp vụ thêm một bước — ví dụ chỉ duyệt được khi đã xác nhận thanh toán — hàm đó lại dài thêm.

Với một lớp nghiệp vụ, điều khiển chỉ gọi một hàm duy nhất. Hàm đó kiểm tra điều kiện, cập nhật trạng thái, trừ tồn kho, ghi log, và trả về kết quả có ý nghĩa. Điều khiển không biết gì về các bước bên trong.

Lợi ích không nằm ở số dòng mã. Lợi ích nằm ở chỗ có thể viết kiểm thử cho hàm duyệt đơn mà không cần dựng yêu cầu HTTP, và có thể tái sử dụng hàm đó khi đơn được duyệt tự động theo lịch thay vì do người bấm.

Đây cũng là lý do các công cụ AI viết mã thường làm sai cấu trúc này nếu không được hướng dẫn: chúng sẽ thêm bước mới vào đúng chỗ mã hiện có, tức là vào điều khiển, và làm phần đã phình càng phình thêm. Xem thêm AI coding là gì.

Khi nào nên bỏ MVC

Có hai tình huống nên xem lại MVC thay vì mở rộng nó.

Tình huống thứ nhất: nghiệp vụ trở thành phần thay đổi chính, còn giao diện gần như đứng yên. Lúc đó việc tổ chức mã theo màn hình khiến mỗi thay đổi nghiệp vụ phải sửa nhiều nơi. Nên tổ chức lại theo mô-đun nghiệp vụ, mỗi mô-đun có mô hình, luồng xử lý và điểm cuối riêng.

Tình huống thứ hai: nhiều đội cùng làm và cần phát hành độc lập. MVC không giải quyết bài toán ranh giới giữa các đội. Khi đó câu hỏi không còn là MVC hay không, mà là ranh giới mô-đun nằm ở đâu và ai sở hữu dữ liệu nào. Một monolith mô-đun hoá vẫn thường rẻ hơn nhiều dịch vụ ở giai đoạn này — xem kiến trúc phần mềm monolithic.

Câu hỏi thường gặp

MVC có phải là kiến trúc phần mềm không?

Có, nhưng ở phạm vi hẹp. MVC là kiến trúc bên trong một ứng dụng, tổ chức mã theo ba loại trách nhiệm. Nó không nói gì về cách chia hệ thống thành nhiều đơn vị triển khai, về quyền sở hữu dữ liệu giữa các hệ thống, hay về cách các hệ thống tích hợp. Vì vậy MVC thường là một phần của bức tranh lớn hơn, không phải toàn bộ.

MVC có lỗi thời không?

Không. MVC vẫn là mô hình mặc định trong phần lớn framework web, và vẫn phù hợp với ứng dụng nhiều màn hình đọc ghi dữ liệu. Điều đã thay đổi là nhận thức: MVC không đủ cho nghiệp vụ nhiều bước, nên cần thêm lớp nghiệp vụ. Vấn đề không phải MVC lỗi thời mà là dùng MVC cho bài toán nó không được thiết kế để giải.

Có nên dùng MVC cho dự án mới không?

Có, nếu phần lớn công việc của hệ thống là quản lý dữ liệu theo màn hình và nghiệp vụ ít bước. Nên chốt ngay từ đầu một quy tắc: điều khiển không chứa logic nghiệp vụ, mọi luồng đi qua lớp nghiệp vụ. Quy tắc này giữ được lợi ích của MVC mà không phải đổi kiến trúc khi nghiệp vụ phức tạp lên.

Dấu hiệu rõ nhất để biết cần đổi cấu trúc là gì?

Là không viết được kiểm thử cho một luồng nghiệp vụ mà không dựng cả yêu cầu HTTP. Khi đó logic đang nằm ở nơi khó kiểm chứng, và mọi thay đổi đều phải kiểm tra thủ công. Đây là dấu hiệu đáng tin hơn số dòng mã trong tệp điều khiển, vì nó đo đúng thứ quyết định chi phí thay đổi về sau.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung phản ánh quy trình bốn chặng WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — và được rà soát theo thông lệ thiết kế hệ thống đang áp dụng. Bài viết không mô tả hạ tầng nội bộ của WinSell, không nêu giá dịch vụ và không sử dụng số liệu khách hàng của bất kỳ bên nào.

Nếu bạn cần rà lại cấu trúc mã hiện tại trước khi mở rộng, xem dịch vụ xây dựng phần mềm theo yêu cầu của WinSell. Báo giá sau khi chốt phạm vi.