Tại sao tôi nên sử dụng mô hình MVC?

Dường như mọi người đang làm các ứng dụng web hiện nay đều muốn sử dụng MVC cho mọi thứ. Tuy nhiên, tôi thấy khó thuyết phục bản thân sử dụng mẫu này. Tôi hiểu ý tưởng chung là tách logic phụ trợ khỏi giao diện đại diện cho chương trình. Nói chung, có vẻ như các khung nhìn luôn phụ thuộc vào bộ điều khiển ở một mức độ nào đó, kết thúc tùy thuộc vào mô hình. Tôi không thấy những lợi thế khi thêm bộ điều khiển giúp tôi. Tôi đã đọc rất nhiều sự cường điệu về "đây là cách các ứng dụng nên được thiết kế", nhưng có lẽ tôi vẫn không hiểu những gì được cho là sẽ đi đâu. Bất cứ khi nào tôi nói chuyện với người khác về MVC, dường như mọi người đều có một ý tưởng khác nhau về những gì thuộc về thể loại nào.

Vậy, tại sao tôi nên sử dụng MVC? Tôi có được gì khi sử dụng MVC chỉ bằng cách tách frontend khỏi logic phụ trợ? (Hầu hết "lợi thế" mà tôi thấy về mẫu này có được chỉ bằng cách tách giao diện khỏi triển khai và không giải thích được mục đích của việc có một "bộ điều khiển" riêng)

Heh. Martin Fowler đồng ý với sự nhầm lẫn của bạn về MVC:

Tôi không thấy hữu ích khi nghĩ về MVC như một mô hình vì nó chứa khá nhiều ý tưởng khác nhau. Những người khác nhau đọc về MVC ở những nơi khác nhau sẽ lấy những ý tưởng khác nhau từ nó và mô tả những điều này là 'MVC'. Nếu điều này không đủ gây nhầm lẫn, thì bạn sẽ nhận được hiệu ứng hiểu lầm về MVC phát triển thông qua một hệ thống thì thầm của Trung Quốc.

Tuy nhiên, ông tiếp tục đưa ra một trong những giải thích sâu sắc hơn về những gì thúc đẩy MVC:

Tại trung tâm của MVC là những gì tôi gọi là Trình bày tách biệt. Ý tưởng đằng sau Bản trình bày tách biệt là phân chia rõ ràng giữa các đối tượng miền mô hình hóa nhận thức của chúng ta về thế giới thực và các đối tượng trình bày là các thành phần GUI mà chúng ta thấy trên màn hình. Các đối tượng miền phải hoàn toàn khép kín và hoạt động mà không cần tham khảo bài thuyết trình, chúng cũng có thể hỗ trợ nhiều bài thuyết trình, có thể đồng thời.

Bạn có thể đọc toàn bộ bài viết của Fowler tại đây .

Tôi cảm thấy điều này phụ thuộc nhiều vào vấn đề bạn đang giải quyết. Tôi thấy sự phân tách như sau:

Mô hình - làm thế nào để chúng tôi đại diện cho dữ liệu? Ví dụ: làm thế nào để tôi đi từ các đối tượng của mình đến một bộ lưu trữ liên tục như DB -> làm cách nào để lưu đối tượng 'Người dùng' của tôi vào cơ sở dữ liệu?

Người điều khiển - tôi đang làm gì? Đây là hành động đang diễn ra, và những gì, ở cấp độ khái niệm, cần phải được thực hiện. Ví dụ: tôi cần trải qua giai đoạn nào để lập hóa đơn cho Người dùng? NB điều này có thể ảnh hưởng đến bất kỳ số lượng đối tượng nào, nhưng không biết gì về cách chúng được duy trì đối với DB.

Xem - làm cách nào để hiển thị kết quả?

Vấn đề tôi cảm thấy bạn đang thấy là rất nhiều ứng dụng web là giao diện CRUD (Tạo-Lấy-Cập nhật-Xóa) được vinh danh cho DB. tức là bộ điều khiển được yêu cầu 'thêm người dùng', và sau đó nó chỉ đơn giản là nói với mô hình để 'thêm người dùng'. Không có gì đạt được.

Tuy nhiên, trong các dự án mà các hành động bạn thực hiện không áp dụng trực tiếp vào các thay đổi trong mô hình, bộ điều khiển làm cho cuộc sống dễ dàng hơn nhiều và hệ thống dễ bảo trì hơn.

Bạn không nên.

Hãy để tôi nói lại rằng. Bạn nên sử dụng một kiến ​​trúc tách biệt logic khỏi quan điểm của bạn. Nếu cần, bạn nên sử dụng một kiến ​​trúc sử dụng bộ điều khiển (chẳng hạn như MVC) nếu có logic cần thiết mà không nhất thiết phải phù hợp với một mô hình (chẳng hạn như một đoạn phân tích cú pháp phân tích cú pháp cây).

Đến từ CI và Yii, tôi nghĩ rằng có một bộ điều khiển chuyên dụng là một ý tưởng tuyệt vời. Tuy nhiên, khi phát triển các ứng dụng với giao diện RESTful thích hợp, thì nhu cầu về bộ điều khiển để xử lý logic phi mô hình cụ thể dường như giảm đi. Do đó, khi chuyển sang Django và sau đó là Kim tự tháp (cả hai đều không tuân theo kiến ​​trúc MVC hoàn toàn), tôi thấy rằng bộ điều khiển không thực sự là một thành phần bắt buộc cho các ứng dụng tôi đang xây dựng. Lưu ý rằng cả hai khung công tác đều có các tính năng "bộ điều khiển", chẳng hạn như Phân phối URL trong Kim tự tháp, nhưng đó là một điều cấu hình, không phải là điều thời gian chạy (chẳng hạn như CContoder trong Yii).

Vào cuối ngày, điều thực sự quan trọng là sự tách biệt quan điểm khỏi logic. Điều này không chỉ làm sạch mọi thứ về mặt triển khai mà còn cho phép các kỹ sư FE / BE làm việc song song (khi làm việc trong môi trường nhóm).

(Lưu ý bên lề: Tôi không phát triển ứng dụng web một cách chuyên nghiệp, vì vậy có thể thiếu thứ gì đó)

Vâng, thuật ngữ về điều này là một mớ hỗn độn. Thật khó để nói về bởi vì bạn không bao giờ khá gì ai đó có nghĩa là bởi các điều khoản.

Theo như lý do tại sao một bộ điều khiển riêng biệt, lý do có thể phụ thuộc vào phiên bản của bộ điều khiển mà bạn đang nói đến.

Bạn có thể muốn có bộ điều khiển vì khi bạn chạy thử, chế độ xem có một loạt các tiện ích mà bạn không viết và có thể không muốn kiểm tra. Có, bạn đã tách việc thực hiện khỏi kế thừa, do đó bạn có thể sử dụng sơ khai hoặc giả để kiểm tra các nội dung khác, nhưng khi bạn kiểm tra quan điểm cụ thể của mình thì khó hơn. Nếu bạn có bộ điều khiển không có bất kỳ widget nào chạy cùng mã đó thì bạn có thể kiểm tra trực tiếp và có thể không cần kiểm tra các widget thông qua tập lệnh.

Các phiên bản khác là IMHO khó hơn để hiển thị một lợi ích cụ thể cho. Tôi nghĩ rằng vấn đề chủ yếu là tách biệt mối quan tâm - tách biệt mối quan tâm GUI trực quan khỏi logic áp dụng cho GUI nhưng không phải là một phần của mô hình kinh doanh (những thứ như, dịch các bản cập nhật từ mô hình sang các widget sẽ hiển thị). Nhưng trong thực tế, hai lớp có khả năng được liên kết chặt chẽ với nhau (ngay cả khi chúng giao tiếp qua các giao diện) đến nỗi khó có thể quá khó chịu khi hợp nhất chúng thành một khung nhìn và chỉ để ý các cách chức năng có thể tái sử dụng nhiều hơn nếu chúng bị chia tách

Nói một cách đơn giản: tách mối quan tâm. Ngoài tất cả các cuộc nói chuyện về cách làm việc "chính xác", có mã sạch hơn, v.v. bạn có thể nói rằng MVC cho phép bạn dễ dàng sử dụng lại mã của mình hơn. Về cơ bản, bạn lập trình các mô hình và bộ điều khiển của mình và bạn có thể sử dụng chúng một cách không rõ ràng trong một ứng dụng web, ứng dụng bàn, dịch vụ, bất cứ nơi nào mà không cần nỗ lực nhiều.

Vâng, lý do cơ bản để sử dụng cấu trúc MVC xuất hiện trong một thiết lập công nghiệp, trong đó một quy trình làm việc duy nhất, một mô hình duy nhất được theo dõi để phát triển bất kỳ ứng dụng nào. Vì vậy, trong trường hợp, nếu dự án chuyển từ một mô-đun của một tổ chức sang một tổ chức khác, việc cung cấp một sự hiểu biết tốt hơn về kịch bản công việc sẽ dễ dàng hơn nhiều. Nó kết hợp sự rõ ràng của công việc.
Trong khi bạn, với tư cách là một cá nhân sẽ có một cách tiếp cận khác cho ứng dụng của bạn, thì khi bạn làm việc theo kiểu kết hợp với một cộng sự, trước tiên sẽ thảo luận và tìm đến một mô hình thường được hai người đồng ý (bạn và cộng sự của bạn). Và trong trường hợp như vậy, nó phân tách các trách nhiệm được giao cho bạn và cộng sự của bạn tương ứng với một lề đặc biệt.

Tôi nghĩ rằng MVC được sử dụng chỉ là một từ thông dụng bởi các nhà lý thuyết là các nhà quản lý. Tuy nhiên, đã nói rằng, việc lặp lại hiện tại của web với thiết kế đáp ứng, phổ biến HTML5 và cố gắng tạo một dòng lập trình cơ sở dữ liệu duy nhất sẽ hoạt động trên web và trên iPhone dựa trên các ý tưởng chung về MVC. Công nghệ mặt trước web thực sự đang di chuyển với tốc độ ánh sáng ngay bây giờ với Jquery, các bước lặp mới của điều khiển CSS, trong khi phía máy chủ của mọi thứ đang di chuyển với tốc độ của một con ốc sên.

Cuối cùng, mọi thứ trên máy chủ sẽ thực sự chỉ là các dịch vụ hoặc "applet" bơm dữ liệu lên giao diện người dùng và tùy thuộc vào loại máy khách nào bạn có, dữ liệu đó sẽ được tiêu thụ và hiển thị khác nhau. Theo nghĩa đó, MVC có ý nghĩa.

Về vấn đề này, tôi tin vào thế giới thực hiện tại, MVVM thực sự là một "mẫu" tốt hơn hoặc bất cứ điều gì bạn muốn gọi nó hơn là bộ điều khiển vì bộ điều khiển luôn phải quay lại mô hình để thay đổi chế độ xem và điều này chậm . Trong mẫu MVVM, ViewModel có thể cung cấp các cập nhật ngay lập tức cho chế độ xem. Ngoài ra, mô hình MVVM thúc đẩy hiệu trưởng thiết kế RESTful IMHO.