Trên MVC, một số khung nhìn có thể có cùng một bộ điều khiển hoặc một khung nhìn phải có một bộ điều khiển duy nhất?

Tôi có một số câu hỏi trong khi thiết kế kiến ​​trúc cho một dự án xung quanh MVC. (Đó là một dự án SDK C ++ / Marmalade, tôi không sử dụng bất kỳ khung MVC cụ thể nào, tôi đang tạo một.)

Trên một số bài viết (như trên bài viết gốc của Steve Burbek ) Tôi tiếp tục đọc khái niệm "bộ ba MVC" khiến tôi sa lầy kể từ khi tôi lấy khái niệm này theo nghĩa đen. Khi tôi đọc nó lần đầu tiên trông giống như một ứng dụng được xây dựng xung quanh các đơn vị "bộ ba MVC" - một cho mỗi phần UI tôi nghĩ - nhưng tôi thấy điều này khá không linh hoạt và tôi nghĩ đó không phải là cách sử dụng MVC. Sau đó, nghiên cứu sâu hơn về vấn đề này, tôi đã tìm thấy một số ví dụ về sự kết hợp chặt chẽ của bộ điều khiển và khung nhìn, cụ thể là, mối quan hệ 1-1 - TextEditView có TextEditControll.

Nhưng khi tôi quay lại dự án của mình, tôi thấy rằng có thể hữu ích khi có một bộ điều khiển (theo 'đơn vị logic', như AddEuityContoder) và một số khung nhìn cho bộ điều khiển cụ thể đó.

Tôi rõ ràng đang suy nghĩ về một cái gì đó giống như AddEuityControll cần có một số loại UI tab. Tôi có nên có một AddEuityContoder có AddEuityTabView và một vài AddImageView, AddSoundView, v.v. cho các tab không? Hoặc tôi nên có một 'bộ điều khiển phụ' khác nhau cho mỗi chế độ xem tab?

Tóm lại, và liên quan đến mẫu MVC (không phải là sự hiểu biết / triển khai cụ thể của khung X), liệu có chính xác để có một vài khung nhìn cho một bộ điều khiển hay mỗi khung nhìn có bộ điều khiển cụ thể không?

Ngoài ra, có đúng không khi giữ một số thông tin trạng thái trên bộ điều khiển hoặc nên không trạng thái (nghĩa là trạng thái nên được đặt trên một số mô hình trạng thái không thuộc miền)?

Cảm ơn tất cả trước.

Vấn đề là mẫu MVC được thiết kế trong một hệ thống không thực sự tồn tại nữa. Nó được phát minh trong Smalltalk tại thời điểm thư viện UI không tồn tại. Để tạo một hộp thoại cửa sổ, bạn đã vẽ tất cả các ô, tô sáng các ô vuông thích hợp, đảm bảo rằng văn bản bạn đang vẽ kết thúc ở đúng vị trí ... vv ...

Hãy tưởng tượng nó sẽ như thế nào khi viết một ứng dụng hộp thoại mà không sử dụng gì ngoài một khung vẽ lớn. Đó là thế giới mà MVC đến từ.

Một "khung nhìn" trong hệ thống này là một hộp văn bản và đó là một lớp chịu trách nhiệm vẽ hộp, văn bản, vẽ các khu vực được chọn, đáp ứng các thay đổi trong văn bản, v.v ...

"Trình điều khiển" là một lớp khác lấy các sự kiện chuột xảy ra trong hộp này như di chuyển chuột, phím xuống, phím lên, nhấp chuột, v.v ... và nó sẽ quyết định điều gì đã xảy ra. Chúng ta có nên thay đổi văn bản? Có nên thay đổi lựa chọn? Những thứ như thế.

Một "mô hình" là một lớp khác đại diện cho dữ liệu và trạng thái cơ bản của thành phần. Một mô hình hộp văn bản sẽ có văn bản tất nhiên, phông chữ, lựa chọn, v.v ...

Như bạn có thể thấy, trong một tình huống như thế này, ba thành phần rất vướng mắc trong việc thể hiện một ý tưởng duy nhất. Nó có ý nghĩa trong bối cảnh này để nói về một "bộ ba".

Ngày nay, nếu bạn đang làm việc để tạo một thư viện UI và sử dụng các lệnh vẽ thô, bạn có thể làm điều gì đó tương tự. Nhưng ứng dụng của mẫu "MVC" đã lan rộng ra ngoài mục đích ban đầu của nó. Ngày nay, bạn có một "chế độ xem" thực sự có thể là một hộp thoại hoàn chỉnh và bộ điều khiển phản ứng với các sự kiện như "textChanged" hoặc "buttonClicky". Mô hình trong MVC ngày nay thường là một cái gì đó khá ngắt kết nối với hệ thống (nhưng thường được liên kết với khung nhìn bằng cách cung cấp một giao diện quan sát nào đó) và có thể có nhiều khung nhìn liên quan đến một mô hình.

Trong một hệ thống gần đây tôi đã kiến ​​trúc, ví dụ, chúng tôi có khoảng hơn 10 lượt xem tất cả quan sát một "người giữ" tài liệu duy nhất và tài liệu đang hoạt động của nó. Giao diện bản vẽ chính tương tác với bố cục của tài liệu, các chế độ xem thuộc tính khác nhau quan sát mục đã chọn và cung cấp giao diện bản ghi và biểu thị tỷ lệ nhỏ hơn của chế độ xem chính hiển thị toàn bộ tài liệu thay vì chỉ cửa sổ hiển thị. Một số trong các khung nhìn này có các bộ điều khiển có độ phức tạp khác nhau đã biến các sự kiện GUI thành các thay đổi đối với tài liệu, từ đó sẽ thông báo cho các khung nhìn khác nhau của nó.

Bạn vẫn có thể gọi một mối quan hệ như vậy là "bộ ba"? Có lẽ, nhưng tôi nghĩ nó ngụ ý quá nhiều về ứng dụng MVC cũ hơn.

Bạn có thể chia sẻ bộ điều khiển với các quan điểm khác nhau? Phụ thuộc vào cách nhìn tương tự. Tôi đã phát hiện ra rằng nói chung loại đối tượng này có hành vi cụ thể đối với chế độ xem nó đang kiểm soát VÀ mô hình mà nó đang thao túng để có thể tái sử dụng ... nhưng luôn có ngoại lệ.

Nó phụ thuộc. Có một số biến thể của MVC, một số trong đó chỉ có mối quan hệ 1: 1 có ý nghĩa (như "hộp thoại khiêm tốn"), những biến thể khác không phải là trường hợp. Tôi khuyên bạn nên đọc loạt bài viết " Xây dựng CAB của riêng bạn ", giải thích các biến thể MVC quan trọng nhất.

Lượt xem không có Bộ điều khiển trong MVC. Bộ điều khiển là ông chủ, do đó, Bộ điều khiển quyết định Chế độ xem nào được hiển thị và Chế độ xem không / không quan tâm Bộ điều khiển nào yêu cầu Chế độ xem.

Bạn hoàn toàn có thể / sẽ có nhiều Lượt xem từ Bộ điều khiển. Chỉ cần nghĩ về việc tạo một mô hình cho mỗi chế độ xem nếu bạn muốn gắn bó với mô hình MVC.

Quan điểm của bộ điều khiển là kiểm soát các tương tác của người dùng với mô hình miền của bạn - nghĩa là, đó là một mức độ không xác định giữa những gì người dùng nhìn thấy (chế độ xem) và trạng thái của các ứng dụng của bạn (mô hình).

Khi người dùng đưa ra yêu cầu, nó sẽ được chuyển đến bộ điều khiển. Bộ điều khiển quyết định cách chuyển tiếp yêu cầu đó đến ứng dụng, thường thông qua một số loại dịch vụ. Sau đó, nó diễn giải phản hồi từ lớp dịch vụ đó và quyết định xem sẽ gửi lại cho người dùng.

Bộ điều khiển có thể luôn trả về cùng một chế độ xem (1: 1) nếu chỉ có một loại yêu cầu mà người dùng có thể thực hiện đối với bộ điều khiển và nó luôn yêu cầu cùng một loại phản hồi. Ví dụ: HelloWorldControllersẽ luôn trả về HelloWorldViewhiển thị "Xin chào, Thế giới!"

Mặt khác, một bộ điều khiển thường phải quyết định các quan điểm khác nhau, tùy thuộc vào những gì mô hình nói với nó. Có TeamRosterControllerthể trả về a RugbyTeamRosterViewhoặc a FootbalTeamRosterView, tùy thuộc vào loại đội được yêu cầu.

Nói chung, tốt hơn là các bộ điều khiển không trạng thái, mặc dù một số quyền truy cập vào trạng thái của phiên người dùng có thể là cần thiết hoặc mong muốn. Bạn nên quản lý quyền truy cập vào trạng thái đó một cách riêng biệt nếu có thể.

Tôi thực sự khuyên bạn nên nhìn vào một khung MVC thực tế để xem nó làm gì và hoạt động như thế nào. Bạn không cần phải sử dụng nó, nhưng bạn chắc chắn sẽ hiểu rõ hơn trước khi tự xây dựng.