Kiến trúc MVC - Tôi cần bao nhiêu Bộ điều khiển?

Tôi đã mã hóa được một thời gian, nhưng chủ yếu là các tập lệnh và các ứng dụng đơn giản. Tôi đã chuyển sang một vai trò mới, đó là tất cả về phát triển Ứng dụng web và sử dụng kiến ​​trúc MVC phù hợp, vì vậy tôi rất cố gắng tìm hiểu về tất cả những điều đó rất nhanh.

Tôi hy vọng câu hỏi này không quá giống với " Thực tiễn tốt nhất cho kiến ​​trúc MVC " nhưng khi tôi trải qua một vài hướng dẫn khác nhau, tôi nhận thấy rằng một số có nhiều bộ điều khiển cho những thứ khác nhau.

Một ứng dụng web cần bao nhiêu bộ điều khiển?

Tôi nhận ra điều này sẽ khó trả lời nếu không có ví dụ nên tôi sẽ cung cấp một:

Ứng dụng:

1. Người dùng đăng nhập.
2. Người dùng có thể thực hiện một trong ba điều sau:
   a) Tải lên tệp (được lưu trữ trong cơ sở dữ liệu mongodb với dữ liệu meta).
   b) Tìm kiếm một tập tin.
   c) Đăng xuất.

Câu hỏi của tôi là một câu hỏi chung, nhưng tôi đã đưa ra ví dụ để giúp đỡ bất cứ ai cố gắng trả lời.

Ví dụ của bạn, tôi sẽ tạo hai bộ điều khiển:

• Phiên điều khiển đăng nhập và đăng xuất (tạo và hủy phiên cho bố cục giống như REST)
• Trình điều khiển tệp cho mọi thứ trên tệp (index = search và created = upload)

Nói chung, cách tiếp cận RESTful nơi bạn nghĩ về mọi thứ như một tài nguyên có thể được hiển thị, tạo, chỉnh sửa và phá hủy cho bạn ý tưởng hay về cách cấu trúc mọi thứ. Như bạn có thể thấy trong các ví dụ của mình, tôi không quá gần với mọi động từ trong REST.

Bạn rất có thể sẽ cần nhiều bộ điều khiển hơn cho chức năng hơn nữa. Ví dụ: Trình điều khiển người dùng nơi người dùng có thể tạo tài khoản mới. Và ngoài ra, bạn sẽ cần một giao diện quản trị nơi bạn có thể chỉnh sửa các tài nguyên với các đặc quyền cao hơn. Trong trường hợp như vậy, khá phổ biến khi có gần như mọi bộ điều khiển trùng lặp.

Một ước tính rất sơ bộ để có được ý tưởng ban đầu có thể là một bộ điều khiển cho mọi bảng trong cơ sở dữ liệu của bạn mà người dùng có thể truy cập. Nhưng đây thực sự chỉ là một phép đo rất thô thiển.

Nó thực sự phụ thuộc vào ứng dụng web. Trong ví dụ của bạn, một cái có lẽ là đủ. Nếu bạn đã triển khai một ứng dụng thương mại điện tử đầy đủ với vận chuyển, thuế, quản lý hàng tồn kho, định giá theo cấp bậc, v.v., thì bạn có thể muốn có thêm một vài thứ nữa.

Nếu bộ điều khiển của bạn bị một hoặc nhiều mã có mùi (đặc biệt là Lớp lớn hoặc Đối tượng Thần ) thì bạn có thể biết rằng bạn có thể đã vượt qua điểm mà chỉ một người sẽ làm.

Nó thực sự phụ thuộc vào nhu cầu ứng dụng và kiến ​​trúc của các mô-đun kinh doanh.

Một nguyên tắc chung , số lượng bộ điều khiển cần thiết phụ thuộc vào một số mô-đun và mô-đun phụ trong ứng dụng Web.

Là một bổ sung, sẽ rất hữu ích khi tổ chức các bộ điều khiển vào Khu vực . Khái niệm về các khu vực được xây dựng trong khung ASP.NET MVC và nó đơn giản hóa việc tổ chức các bộ điều khiển phục vụ một mô-đun.

Có một số cuộc thảo luận liên quan:

• Kiến trúc MVC
• Thiết kế hành động điều khiển ASP.NET MVC
• Bộ điều khiển mvc và xem thư mục tổ chức
• Tổ chức lớp MVC trông như thế nào đối với nhiều khung nhìn và bộ điều khiển?

Tôi thích cách làm của Apple.

Mỗi chế độ xem chỉ được điều khiển bởi một bộ điều khiển xem. ~ Xem Hướng dẫn lập trình điều khiển cho iOS

Ý tưởng là bạn sẽ có thể dễ dàng trao đổi Lượt xem. IMO, chỉ bằng 1 Controllermỗi Viewcái, nó sẽ giúp thực hiện việc này dễ dàng hơn. Nhưng tôi chắc chắn rằng bạn có thể có Bộ điều khiển với nhiều Chế độ xem và vẫn thiết kế nó để bạn có thể chuyển Chế độ xem mà không thay đổi logic chương trình.

Một ví dụ mà tôi thích là nghĩ về máy điều nhiệt. Một bộ điều chỉnh nhiệt là một hình ảnh tuyệt vời để xem mô hình MVC.

Trên một bộ điều nhiệt tương tự cũ hơn, bạn có thể hình dung những thứ như thế này:

Xem - Đầu đọc nhiệt độ, hiển thị nhiệt độ hiện tại.

Bộ điều khiển - Mặt số, nơi bạn thay đổi nhiệt độ

Model - Các bộ phận bên trong được gọi bởi bộ điều khiển khiến nhiệt độ thay đổi.

Bạn phải luôn tuân theo các thiết kế cho phép các mô hình khớp nối và giới hạn lỏng lẻo và các bộ điều khiển liên quan của chúng vào một tác vụ duy nhất và bạn nên sử dụng bao nhiêu mô-đun / bộ điều khiển mà bạn cần . Tùy thuộc vào kích thước ứng dụng của bạn, bạn có thể có ít lượt xem hơn so với mô hình và bộ điều khiển. Điều này được mong đợi với bất kỳ ứng dụng kích thước lớn. Lập trình hướng đối tượng tốt được đặc trưng bởi khớp nối lỏng lẻo, đóng gói, kế thừa và đa hình. Không phải tất cả các ngôn ngữ đều hỗ trợ đa hình ở cùng một mức độ (chức năng, phương thức, quá tải / ghi đè toán tử).

Nếu bạn muốn hiểu rõ hơn về việc sử dụng đúng kiến ​​trúc MVC, hãy tham khảo "Các mẫu thiết kế: Các yếu tố của phần mềm tái sử dụng" của GoF, sử dụng mã C ++ và SmallTalk chẳng hạn. Cuốn sách này không phải là alpha và omega, nhưng nó chắc chắn là một sự khởi đầu!

Chúc may mắn!

Tôi giả định rằng ví dụ của bạn sẽ phát triển thành một hệ thống phức tạp.

Ứng dụng:

Người dùng đăng nhập:

• LoginController

Trách nhiệm duy nhất của nó là xử lý đăng nhập, chỉ đạo lại hoặc thông báo cho người dùng về kết quả.

Tải lên một tài liệu

• UploadController

Tôi giả sử ở đây rằng bạn muốn tải lên bất kỳ loại tập tin. Nếu vào ngày sau đó, bạn quyết định tải lên MP3 và PDF, thì tôi sẽ có một UploadContoder cơ bản, MP3UploadContoder và PDFUploadContoder.

Tìm kiếm một tập tin.

• SearchFileController

Điều này sẽ đủ cho một yêu cầu cơ bản. Bạn có thể có nhiều bộ điều khiển tìm kiếm vào một ngày sau đó tùy thuộc vào mức độ phức tạp của logic tìm kiếm. Điều cuối cùng bạn muốn có là một SearchContoder duy nhất với 20 phương thức hành động thực hiện các tìm kiếm khác nhau.

Đăng xuất.

- LogoutController .

Người ta có thể coi đây là một việc làm quá mức, nhưng tôi không nghĩ là vậy. Tôi nghĩ rằng nó sạch sẽ và độc đáo tách biệt.

Nếu tôi nhìn vào cấu trúc dự án này, tôi sẽ biết ngay nó làm gì và cấu trúc của nó như thế nào. Để tiến thêm một bước, tôi sẽ đặt LoginControllervà LogoutControllervào khu vực riêng.

Tôi đã phát triển một cái gì đó như thế này trước đây và nó hoạt động rất tốt.

Hầu hết các mã của bạn sẽ xảy ra trong một lớp kinh doanh phải không? Nếu đó là trường hợp thì tất cả những gì bạn thực sự làm trong bộ điều khiển của bạn là trả lại dữ liệu cho chế độ xem.

Không thực sự chắc chắn nếu tôi là một fan hâm mộ của việc tách các bộ điều khiển thành các kiểu con. Trong khi bạn nên duy trì sự tách biệt các mối quan tâm, tôi nghĩ rằng các kiểu con sẽ đi quá xa. Ngoài ra, bạn cần cẩn thận trong trường hợp các đối tượng nặng được khởi tạo trong hàm tạo hoặc bộ điều khiển. Ví dụ: trong ví dụ của bạn, bạn sẽ muốn một đối tượng nặng, chỉ được sử dụng cho tệp tìm kiếm / tải lên được phát hành khi người dùng ở trên trang đăng nhập.

Tốt hơn là nên có bộ điều khiển trên mỗi đơn vị logic, ví dụ AccountContoder (đăng nhập, đăng ký, đăng xuất), FileContoder (tìm kiếm, tải lên), v.v.

Nói chung, bạn có thể nói rằng mỗi MÔ HÌNH đều có ĐIỀU KHIỂN và XEM riêng. Nói chung tôi có nghĩa là đây là cách thực hành tốt nhất.

Các khía cạnh ứng dụng (như quản lý người dùng) nên được dịch sang dịch vụ ứng dụng và cần được gọi bởi bộ điều khiển tự nó hoặc để bọc bộ điều khiển của bạn (ví dụ sử dụng các thuộc tính làm cho chức năng của bộ điều khiển "hiển thị" theo vai trò người dùng yêu cầu).

Hãy nhớ rằng tất cả các bộ điều khiển về cơ bản nên xử lý các hoạt động CRUD qua mô hình và sử dụng các chế độ xem khác nhau cho các bộ lọc khác nhau.

Theo tôi, một trong những lợi thế chính của mô hình MVC là nó cung cấp cách tốt nhất để gắn kết các mô hình và khung nhìn.

Về ví dụ bạn đã thêm: Tôi sẽ tạo 2 bộ điều khiển: một cho tất cả thao tác đăng nhập của người dùng (đăng ký, đăng nhập, đăng xuất, v.v.) và thứ hai cho các thao tác tệp (Tải lên và tìm kiếm). lưu ý rằng cái đầu tiên cũng cần được sao lưu với một số khía cạnh liên quan đến chức năng Đăng nhập và cái thứ hai là bộ điều khiển thông thường