Kiến trúc sạch: Mô hình View là gì?

Trong cuốn sách 'Kiến trúc sạch', chú Bob nói rằng Người thuyết trình nên đưa dữ liệu mà nó nhận được vào thứ mà ông gọi là 'Mô hình xem'.

Đây có phải là điều tương tự như 'ViewModel' từ mẫu thiết kế Model-View-ViewModel (MVVM) hay nó là một Đối tượng truyền dữ liệu đơn giản (DTO)?

Nếu nó không phải là một DTO đơn giản, thì nó liên quan đến View như thế nào? Chế độ xem có nhận được cập nhật từ nó thông qua mối quan hệ Observer không?

Tôi đoán là nó giống với ViewModel từ MVVM hơn, bởi vì trong Chương 23 của cuốn sách, Robert Martin nói:

Công việc của [Người thuyết trình] là chấp nhận dữ liệu từ ứng dụng và định dạng nó để trình bày để Chế độ xem có thể chỉ cần di chuyển nó đến màn hình. Ví dụ: nếu ứng dụng muốn một ngày được hiển thị trong một trường, nó sẽ trao cho Người trình bày một đối tượng Ngày. Sau đó, Người trình bày sẽ định dạng dữ liệu đó thành một chuỗi thích hợp và đặt nó vào một cấu trúc dữ liệu đơn giản được gọi là mô hình Chế độ xem, nơi Chế độ xem có thể tìm thấy dữ liệu đó.

Điều này ngụ ý rằng Chế độ xem được kết nối bằng cách nào đó với ViewModel, trái ngược với việc chỉ đơn giản nhận nó làm đối số chức năng (ví dụ như trường hợp với DTO).

Một lý do khác khiến tôi nghĩ điều này là bởi vì nếu bạn nhìn vào hình ảnh, Người thuyết trình sử dụng Mô hình Chế độ xem chứ không phải Chế độ xem. Trong khi đó, Người trình bày sử dụng cả Ranh giới đầu ra và Dữ liệu đầu ra DTO.

Nếu nó không phải là DTO hay ViewModel từ MVVM, vui lòng giải thích chi tiết về nó.

Đây có phải là điều tương tự như 'ViewModel' từ mẫu thiết kế Model-View-ViewModel (MVVM)

Không.

Đó sẽ là thế này :

Điều đó có chu kỳ. Chú Bob đã cẩn thận tránh chu kỳ .

Thay vào đó bạn có điều này:

Mà chắc chắn không có chu kỳ. Nhưng nó khiến bạn tự hỏi làm thế nào quan điểm biết về một bản cập nhật. Chúng ta sẽ đến đó trong giây lát.

hoặc nó là một đối tượng truyền dữ liệu đơn giản (DTO)?

Để trích dẫn Bob từ trang trước:

Bạn có thể sử dụng các cấu trúc cơ bản hoặc các đối tượng truyền dữ liệu đơn giản nếu bạn muốn. Hoặc bạn có thể đóng gói nó thành một hashmap hoặc xây dựng nó thành một đối tượng.

Kiến trúc sạch p207

Vì vậy, chắc chắn, nếu bạn thích.

Nhưng tôi cực kỳ nghi ngờ những gì thực sự làm phiền bạn là đây :

Việc lạm dụng UML nhỏ dễ thương này tương phản hướng phụ thuộc mã nguồn với hướng điều khiển. Đây là nơi câu trả lời cho câu hỏi của bạn có thể được tìm thấy.

Trong mối quan hệ sử dụng:

luồng điều khiển đi theo cùng hướng mà phụ thuộc mã nguồn thực hiện.

Trong một mối quan hệ thực hiện:

luồng điều khiển thường đi theo hướng ngược lại, sự phụ thuộc mã nguồn thực hiện.

Điều đó có nghĩa là bạn đang thực sự nhìn vào điều này:

Bạn sẽ có thể thấy rằng luồng điều khiển sẽ không bao giờ có được từ Người thuyết trình đến Chế độ xem.

Làm thế nào mà có thể được? Nó có nghĩa là gì?

Điều đó có nghĩa là chế độ xem có luồng riêng của nó (không phải là bất thường) hoặc (như @Euphoric chỉ ra) luồng kiểm soát đang đi vào chế độ xem từ một thứ khác không được mô tả ở đây.

Nếu đó là cùng một chủ đề thì Chế độ xem sẽ biết khi nào Mô hình xem sẵn sàng để đọc. Nhưng nếu đó là trường hợp và khung nhìn là GUI thì sẽ khó có thể sơn lại màn hình khi người dùng di chuyển xung quanh trong khi họ chờ DB.

Nếu khung nhìn có luồng riêng thì nó có luồng điều khiển riêng. Điều đó có nghĩa là để thực hiện điều này, Chế độ xem sẽ phải thăm dò Mô hình Chế độ để nhận thấy các thay đổi.

Vì Người thuyết trình không biết Chế độ xem tồn tại và Chế độ xem không biết Người thuyết trình tồn tại nên họ không thể gọi nhau. Họ không thể ném các sự kiện vào nhau. Tất cả những gì có thể xảy ra là Người thuyết trình sẽ ghi vào Mô hình xem và Chế độ xem sẽ đọc Mô hình xem. Bất cứ khi nào nó cảm thấy thích nó.

Theo sơ đồ này, điều duy nhất mà Chế độ xem và Người trình bày chia sẻ là kiến ​​thức về Mô hình Chế độ xem. Và nó chỉ là một cấu trúc dữ liệu. Vì vậy, đừng hy vọng nó có bất kỳ hành vi nào.

Điều đó có vẻ không thể nhưng nó có thể được thực hiện để hoạt động ngay cả khi Mô hình xem phức tạp. Một trường cập nhật nhỏ là tất cả các chế độ xem sẽ phải thăm dò để phát hiện thay đổi.

Bây giờ tất nhiên bạn có thể khăng khăng sử dụng mẫu người quan sát hoặc có một số điều cơ bản che giấu vấn đề này với bạn nhưng xin vui lòng hiểu rằng bạn không phải làm vậy.

Đây là một chút thú vị tôi đã minh họa dòng kiểm soát:

Lưu ý rằng bất cứ khi nào bạn thấy luồng đi ngược lại các hướng tôi đã xác định trước đó, điều bạn đang thấy là một cuộc gọi trở lại. Thủ thuật đó sẽ không giúp chúng ta đến được View. Chà, trừ khi trước tiên chúng ta trở lại bất cứ thứ gì gọi là Bộ điều khiển. Hoặc bạn chỉ có thể thay đổi thiết kế để bạn có thể xem. Điều đó cũng khắc phục sự cố giống như bắt đầu của sự cố yo-yo với Truy cập dữ liệu và Giao diện.

Điều duy nhất khác để tìm hiểu ở đây ngoài đó là Bộ xử lý trường hợp sử dụng có thể gọi khá nhiều thứ theo bất kỳ thứ tự nào nó muốn miễn là nó gọi cho người trình bày trước.

Tôi thấy vấn đề này quá khó hiểu và sẽ mất rất nhiều văn bản và thời gian để giải thích chính xác vấn đề vì tôi tin rằng bạn hiểu nhầm cả Kiến trúc sạch và MVVM của Martin.

Điều đầu tiên cần lưu ý là sơ đồ bạn đã đăng không đầy đủ. Nó chỉ hiển thị "logic kinh doanh", nhưng thiếu một số loại "dàn nhạc" thực sự làm cho các bộ phận di chuyển theo đúng thứ tự.

Mã của dàn nhạc sẽ đơn giản như

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

Tôi tin rằng tôi đã nghe Martin nói về điều này trong một trong những cuộc nói chuyện của anh ấy về Kiến trúc sạch.

Một điều khác cần chỉ ra là nhận xét của candied_orange về việc thiếu chu kỳ là sai. Có, chu kỳ không tồn tại (và không nên) trong kiến ​​trúc của mã. Nhưng chu kỳ giữa các trường hợp thời gian chạy là phổ biến và thường dẫn đến thiết kế đơn giản hơn.

Đó là trường hợp trong MVVM. Trong Chế độ xem MVVM phụ thuộc vào ViewModel và ViewModel sử dụng các sự kiện để thông báo cho View về những thay đổi của nó. Điều này có nghĩa là trong thiết kế của các lớp, chỉ có sự phụ thuộc từ các lớp View đến Model, nhưng trong thời gian chạy, có sự phụ thuộc theo chu kỳ giữa các phiên bản View và ViewModel. Do đó, không cần người điều phối, vì ViewModel sẽ cung cấp cách Xem để tìm ra khi nào nên tự cập nhật. Đây là lý do tại sao "thông báo" trong sơ đồ này sử dụng dòng "squigly" chứ không phải dòng trực tiếp. Điều đó có nghĩa là View quan sát các thay đổi trong ViewModel, không phải ViewModel phụ thuộc vào View.

Điều quan trọng nhất bạn nên lấy từ Kiến trúc sạch của Martin không phải là bản thân thiết kế, mà là cách bạn xử lý các phụ thuộc. Một trong những điểm quan trọng mà anh ấy đưa ra trong các cuộc nói chuyện của mình là khi có một ranh giới, thì tất cả các phụ thuộc mã sẽ vượt qua ranh giới đó theo một hướng. Trong sơ đồ, ranh giới này được thể hiện bằng đường đôi. Và có rất nhiều phụ thuộc đảo thông qua giao diện ( InputBoundary, OutputBoundaryvàDataAccessInterface ) mà sửa theo hướng đang phụ thuộc.

Ngược lại, ViewModeltrong Kiến trúc sạch chỉ là DTO đơn giản không có logic. Điều này được thực hiện rõ ràng bằng <DS>thẻ. Và đây là lý do tại sao orchestratorcần thiết, nhưView sẽ không biết khi nào nên chạy logic.

Nếu tôi "làm phẳng" sơ đồ thành giao diện trong thời gian chạy, nó sẽ trông như thế này:

Vì vậy, trong thời gian chạy, các phụ thuộc theo hướng "sai", nhưng điều đó là tốt.

Tôi khuyên bạn nên xem bài nói chuyện của anh ấy về Kiến trúc sạch để hiểu rõ hơn lý lẽ của anh ấy.