Những nhược điểm của MVC là gì? [đóng cửa]

Tôi đã sử dụng MVC / MV * kể từ khi tôi thực sự tổ chức mã của mình cách đây nhiều năm. Tôi đã sử dụng nó quá lâu đến nỗi tôi thậm chí không thể nghĩ ra bất kỳ cách nào khác để cấu trúc mã của mình và mọi công việc tôi đã có sau khi thực tập đều dựa trên MVC.

Câu hỏi của tôi là, những nhược điểm của MVC là gì? Trong trường hợp nào MVC sẽ là một lựa chọn tồi cho một dự án và đâu là sự lựa chọn đúng (hơn)? Khi tôi tìm kiếm các lựa chọn thay thế MVC, gần như mọi kết quả chỉ là các loại MVC khác nhau.

Để thu hẹp phạm vi để điều này không bị đóng, giả sử ứng dụng web. Tôi làm việc trên phần phụ trợ và phần đầu cho các dự án khác nhau, vì vậy tôi không thể nói chỉ là phần đầu hoặc phần cuối.

Bạn nên luôn nhớ - MVC là một mẫu liên quan đến giao diện người dùng. Nếu bạn đang xây dựng một ứng dụng phức tạp, bạn nên lấy tất cả mọi thứ, không liên quan đến UI, ngoài bộ ba MVC đến bất kỳ lớp, hệ thống con hoặc lớp nào khác.

Đó là sai lầm lớn nhất của tôi. Tôi đã dành một thời gian dài để hiểu quy tắc đơn giản đó:

• Không trải một mô hình MVC trong toàn bộ ứng dụng,
• Giới hạn nó chỉ những thứ liên quan đến UI.

Luôn kiểm tra xem mã bạn viết có đúng ở vị trí chính xác hay không, nghĩa là nó phù hợp một cách hợp lý với trách nhiệm của lớp bạn đặt nó. Nếu không - hãy chuyển mã đi ngay khi bạn hiểu.

Tất cả các mẫu mà bạn gọi là các lựa chọn thay thế MVC (ví dụ Model-View-Presenter, Model-View-ViewModel) chỉ là một cách để thực hiện khái niệm MVC chung.

Theo tôi có hai loại MVC - thuần túy và không trong sạch (vì thiếu một từ tốt hơn :)

MVC thuần túy là những gì đã được giới thiệu vào cuộc nói chuyện nhỏ:

Điều này được dành cho các ứng dụng máy tính cá nhân / máy tính để bàn. Như bạn có thể thấy, mô hình thông báo quan điểm của bất kỳ cập nhật / thay đổi nào được thực hiện cho nó. Không như vậy với (không trong sạch) MVC.

MVC khác (không tinh khiết) được quảng cáo cho các ứng dụng web là mô hình PAC ( Trình bày-trừu tượng-kiểm soát ) thay vì mô hình MVC cổ điển ở trên. Đó là nhiều hơn về tổ chức mã và tách các mối quan tâm:

• Model : Trừu tượng cho dữ liệu được lưu trữ
• Điều khiển : Thông thường lớp được gọi là lớp logic nghiệp vụ cũng như một phần của ứng dụng chịu trách nhiệm định tuyến các yêu cầu HTTP đến logic nghiệp vụ tương ứng (còn gọi là bộ điều khiển)
• Xem : Chủ yếu là xem các mẫu định dạng dữ liệu từ mô hình và trả lại cho khách hàng. Mô hình KHÔNG BAO GIỜ gửi các bản cập nhật cho chế độ xem cũng không xem 'đăng ký' cho các cập nhật từ một mô hình. Đó là cơn ác mộng ghép nối. Do đó, nó giống PAC hơn là MVC thực sự.

Bây giờ, đây là cách một ứng dụng web thường được cấu trúc:

1. Front-end : MVC trên máy khách sử dụng các khung làm Backbone.js, v.v., về bản chất đây là dạng MVC 'đúng'.
2. Back-end : Một lần nữa, bạn có (không tinh khiết) MVC / PAC để tổ chức mã và tách các mối quan tâm
3. Ứng dụng web toàn cầu (cho toàn bộ ứng dụng web): Nếu bạn có phần phụ trợ RESTful chỉ trả về dữ liệu JSON, thì toàn bộ phần phụ trợ của bạn có thể được coi là một mô hình cho ứng dụng khách phía trước, nơi thực chất là View và Trình điều khiển.

Vậy một số nhược điểm của MVC là gì? Chà, mô hình đã đứng trước thử thách của thời gian nên không có nhiều vấn đề khác ngoài việc nó hơi "phức tạp". Bạn thấy đấy, MVC là một mẫu tổng hợp - thực hiện mô hình chiến lược / quan sát viên và tất cả đều được sắp xếp hợp lý để tạo thành một mẫu mức cao.

Bạn có nên sử dụng nó ở mọi nơi? Có thể không. Các ứng dụng web cực kỳ phức tạp có thể chia thành nhiều lớp! Bạn có thể không thoát ra được chỉ với các lớp View / Business Logic / Data. Khung / tổ chức bao trùm vẫn có thể là MVC-ish, nhưng chỉ ở cấp độ vĩ mô.

Đây là một ví dụ trong đó chỉ riêng MVC có thể là một lựa chọn tồi : Hãy thử thiết kế hệ thống kiểm soát không lưu hoặc ứng dụng xử lý khoản vay / thế chấp cho một ngân hàng lớn - chỉ riêng MVC sẽ là một lựa chọn tồi. Bạn chắc chắn sẽ có các hàng đợi xe buýt / tin nhắn cùng với kiến ​​trúc nhiều lớp với MVC trong các lớp riêng lẻ và có thể là một thiết kế MVC / PAC bao quát để giữ cho cơ sở mã được tổ chức tốt hơn.

Sai lầm rất nhiều người mắc phải với các mẫu thiết kế là thấy nó hoạt động rất đẹp ở một nơi và sau đó cố gắng áp dụng nó ở mọi nơi.

Nếu bạn đã làm việc ở một nơi trong một thời gian, bạn gần như có thể hẹn hò với một đoạn mã bằng cách xem những gì công nghệ / mẫu thiết kế / thực hành đang thịnh hành tại thời điểm đó, ví dụ như singletons / tiêm phụ thuộc / TDD, v.v.

Đối với nơi không sử dụng nó. Chà, bất cứ nơi nào một yếu tố của bộ ba MVC không áp dụng. Các ứng dụng Console có thể không thực hiện giao diện nào cả. Các chương trình tiện ích có thể không có mô hình. Và có thể nói, nếu bạn không có mô hình cũng như chế độ xem, bạn không yêu cầu bộ điều khiển.

Vấn đề hiếm khi xảy ra với khái niệm - nhiều hơn với việc thực hiện. Cho dù mô hình tốt như thế nào, hãy dành thời gian để xem nó có phù hợp với vấn đề trong tay không.

MVC, giống như bất kỳ mô hình nào không thể tách rời với nền tảng phát triển của bạn, được tăng độ phức tạp. Hạn chế của nó là bạn có thể kết thúc các lớp tách biệt không nên tách rời và làm giảm sự rõ ràng về mức độ ràng buộc chặt chẽ của chúng. (Hoặc, đối với các dự án tầm thường, thậm chí làm xáo trộn mã của bạn.)

Giải pháp thay thế cho vấn đề đầu tiên là tách mã đó thành các tiểu dự án độc lập; thay thế cho thứ hai là mã không tách rời, tại lớp hoặc mô hình tệp.

Sự hiểu biết của tôi về việc áp dụng MVC / MV * tuân theo nguyên tắc Tách mối quan tâm (SoC) - tách chương trình / mã thành các phần / phần riêng biệt để mỗi phần có thể giải quyết một mối quan tâm riêng (Tham khảo: http://en.wikipedia.org / wiki / Tách_of_concerns )

Có rất nhiều lợi ích khi phân tách mối quan tâm: người ta sẽ không ảnh hưởng đến người khác và nhà phát triển có thể làm việc trên một đơn vị mà không ảnh hưởng đến phần còn lại, v.v ... v.v ... MVC không phải là mô hình duy nhất theo SoC, về cơ bản, chính OOP là một khái niệm tuyệt vời để phá vỡ mọi thứ thành các đơn vị.

MVC / MV * rất hữu ích khi bạn xử lý sự phát triển liên quan đến UI, trong khi bên dưới có thể có nhiều mẫu hơn - nhà máy, singleton, mặt tiền, v.v ... Phần lớn các dự án lớn bao gồm nhiều lớp xử lý các khía cạnh khác nhau, nhưng UI có thể không phải một số trường hợp Bạn có thể thấy MVC rất nhiều - đó là vì rất nhiều dự án có các thành phần UI.

do đó, trong khi nói về những nhược điểm của MVC, nó thực sự phụ thuộc vào các dự án bạn đang thực hiện - nó có UI không? nó đòi hỏi khả năng mở rộng / mở rộng lớn? nó có nhiều tương tác giữa UI và hệ thống phía sau không? ví dụ, một trang web thông tin đơn giản hoàn toàn không yêu cầu MVC, trừ khi bạn có kế hoạch mở rộng nó thành một trang tương tác tuyệt vời trong tương lai.

vì vậy để đánh giá MVC (hoặc tổng quát hơn - một mẫu thiết kế), hãy đặt cho nó một bối cảnh và suy nghĩ về độ phức tạp, khả năng mở rộng, khả năng kiểm tra, bảo trì, hạn chế thời gian, v.v.