Vấn đề với MVClà mọi người nghĩ rằng khung nhìn, bộ điều khiển và mô hình phải độc lập nhất có thể với nhau. Chúng không - một khung nhìn và bộ điều khiển thường đan xen - nghĩ về nó như M(VC).
Bộ điều khiển là cơ chế đầu vào của giao diện người dùng, thường bị rối trong chế độ xem, đặc biệt là với GUI. Tuy nhiên, xem là đầu ra và bộ điều khiển là đầu vào. Một khung nhìn thường có thể hoạt động mà không có bộ điều khiển tương ứng, nhưng bộ điều khiển thường ít hữu ích hơn nếu không có chế độ xem. Bộ điều khiển thân thiện với người dùng sử dụng chế độ xem để diễn giải đầu vào của người dùng theo cách trực quan, có ý nghĩa hơn. Đây là những gì nó làm cho nó khó tách khái niệm bộ điều khiển khỏi chế độ xem.
Hãy nghĩ về một robot điều khiển vô tuyến trên một trường phát hiện trong một hộp kín như mô hình.
Mô hình là tất cả về chuyển đổi trạng thái và trạng thái không có khái niệm đầu ra (hiển thị) hoặc những gì đang kích hoạt chuyển đổi trạng thái. Tôi có thể có được vị trí của robot trên sân và robot biết cách chuyển vị trí (tiến một bước tiến / lùi / trái / phải. Dễ dàng hình dung mà không cần xem hoặc điều khiển, nhưng không có gì hữu ích
Hãy nghĩ về một chế độ xem mà không có bộ điều khiển, ví dụ như ai đó trong một phòng khác trên mạng trong một phòng khác đang xem vị trí robot khi tọa độ (x, y) truyền xuống bảng điều khiển cuộn. Khung nhìn này chỉ hiển thị trạng thái của mô hình, nhưng anh chàng này không có bộ điều khiển. Một lần nữa, dễ dàng hình dung quan điểm này mà không cần bộ điều khiển.
Hãy nghĩ về một bộ điều khiển mà không có tầm nhìn, ví dụ như ai đó bị nhốt trong tủ quần áo với bộ điều khiển vô tuyến được điều chỉnh theo tần số của robot. Bộ điều khiển này đang gửi đầu vào và gây ra các chuyển đổi trạng thái mà không biết họ đang làm gì với mô hình (nếu có gì). Dễ hình dung, nhưng không thực sự hữu ích nếu không có một số phản hồi từ chế độ xem.
Hầu hết các giao diện người dùng thân thiện với người dùng phối hợp chế độ xem với bộ điều khiển để cung cấp giao diện người dùng trực quan hơn. Ví dụ: hãy tưởng tượng một chế độ xem / bộ điều khiển với màn hình cảm ứng hiển thị vị trí hiện tại của robot trong 2 chiều và cho phép người dùng chạm vào điểm trên màn hình xảy ra ở phía trước robot. Bộ điều khiển cần chi tiết về chế độ xem, ví dụ: vị trí và tỷ lệ của chế độ xem và vị trí pixel của điểm được chạm tương đối với vị trí pixel của robot trên màn hình) để diễn giải điều này một cách chính xác (không giống như anh chàng bị khóa trong tủ quần áo với bộ điều khiển vô tuyến).
Tôi đã trả lời câu hỏi của bạn chưa? :-)
Bộ điều khiển là bất cứ thứ gì lấy đầu vào từ người dùng được sử dụng để làm cho mô hình chuyển sang trạng thái chuyển tiếp. Cố gắng giữ chế độ xem và bộ điều khiển tách biệt, nhưng nhận ra chúng thường phụ thuộc lẫn nhau, vì vậy không có vấn đề gì nếu ranh giới giữa chúng mờ, tức là có chế độ xem và bộ điều khiển vì các gói riêng biệt có thể không tách biệt rõ ràng như bạn thích, nhưng không sao Bạn có thể phải chấp nhận bộ điều khiển sẽ không được tách biệt rõ ràng khỏi chế độ xem vì chế độ xem là từ mô hình.
... có nên thực hiện bất kỳ xác nhận nào trong Bộ điều khiển không? Nếu vậy, làm cách nào để tôi phản hồi các thông báo lỗi trở lại Chế độ xem - có nên chuyển qua Mô hình lại không, hay Bộ điều khiển chỉ nên gửi thẳng trở lại Chế độ xem?
Nếu xác thực được thực hiện trong Chế độ xem, tôi sẽ đặt gì vào Bộ điều khiển?
Tôi nói rằng một khung nhìn và bộ điều khiển được liên kết sẽ tương tác tự do mà không cần thông qua mô hình. Bộ điều khiển lấy đầu vào của người dùng và nên thực hiện xác nhận (có thể sử dụng thông tin từ mô hình và / hoặc chế độ xem), nhưng nếu xác thực không thành công, bộ điều khiển sẽ có thể cập nhật trực tiếp chế độ xem liên quan của nó (ví dụ: thông báo lỗi).
Thử nghiệm axit cho điều này là để tự hỏi liệu một quan điểm độc lập (tức là anh chàng ở phòng khác đang xem vị trí robot qua mạng) có nên xem bất cứ điều gì hay không do lỗi xác thực của người khác (ví dụ như anh chàng trong tủ quần áo đã cố gắng nói với robot bước ra khỏi sân). Nói chung, câu trả lời là không - lỗi xác nhận đã ngăn quá trình chuyển đổi trạng thái. Nếu không có trạng thái tĩnh lặng (robot không di chuyển), thì không cần phải nói các quan điểm khác. Anh chàng trong tủ chỉ không nhận được bất kỳ phản hồi nào rằng anh ta đã cố gắng gây ra sự chuyển đổi bất hợp pháp (không có chế độ xem - giao diện người dùng xấu) và không ai khác cần phải biết điều đó.
Nếu anh chàng với màn hình cảm ứng cố gắng đưa robot ra khỏi sân, anh ta nhận được một tin nhắn thân thiện với người dùng yêu cầu anh ta không giết robot bằng cách gửi nó ra khỏi trường phát hiện, nhưng một lần nữa, không ai cần biết điều này.
Nếu quan điểm khác làm cần biết về các lỗi này, sau đó bạn có hiệu quả nói rằng các đầu vào từ người sử dụng và bất kỳ sai sót kết quả là một phần của mô hình và toàn bộ điều là một chút phức tạp hơn ...