DTO = ViewModel?

Tôi đang sử dụng NHibernate để duy trì các đối tượng miền của mình. Để đơn giản hóa mọi thứ, tôi đang sử dụng một dự án ASP.NET MVC làm cả lớp trình bày và lớp dịch vụ của tôi.

Tôi muốn trả lại các đối tượng miền của mình trong XML từ các lớp bộ điều khiển của tôi. Sau khi đọc một số bài đăng ở đây trên Stack Overflow, tôi thu thập DTO là cách để thực hiện. Tuy nhiên, tôi cũng đã xem qua các bài đăng nói về ViewModel.

Câu hỏi của tôi: Đối tượng truyền dữ liệu và ViewModels có giống nhau không? Hay ViewModel là một loại mẫu phụ của DTO?

Định nghĩa chính tắc của DTO là hình dạng dữ liệu của một đối tượng không có bất kỳ hành vi nào.

ViewModels là mô hình của khung nhìn. ViewModels thường là dữ liệu đầy đủ hoặc một phần từ một hoặc nhiều đối tượng (hoặc DTO) cộng với bất kỳ thành viên bổ sung nào cụ thể cho hành vi của chế độ xem (các phương thức có thể được chế độ xem thực thi, các thuộc tính để chỉ ra cách chuyển đổi các phần tử chế độ xem, v.v.). Bạn có thể xem mô hình xem dưới dạng tất cả dữ liệu cho một chế độ xem cộng với các hành vi. ViewModels có thể hoặc không thể ánh xạ từng cái một tới các đối tượng kinh doanh hoặc DTO.

Nhân tiện, các phép chiếu NHibernate rất hữu ích nếu một mô hình xem nhất định cần một tập hợp con dữ liệu từ một đối tượng cố định.

ViewModel trong ASP.NET MVC thực hành giống với DTO, tuy nhiên ViewModel trong MVVM pattern khác với DTO vì ViewModel trong MVVM có các hành vi nhưng DTO thì không.

DTO! = ViewModel

Trong mẫu MVVM , ViewModel được sử dụng để tách Model khỏi Chế độ xem. Để biểu diễn Mô hình, bạn có thể sử dụng các lớp DTO đơn giản , lớp này lại được ánh xạ tới cơ sở dữ liệu thông qua ví dụ: NHibernate. Nhưng tôi chưa bao giờ thấy một lớp ViewModel được mô hình hóa như một DTO .. ​​Các lớp ViewModel chủ yếu có hành vi, mà các DTO không có.

DTO - Đối tượng truyền dữ liệu chính xác như nó nói, các thùng chứa để truyền dữ liệu. Chúng không có hành vi mà chỉ đơn thuần là một đám người định cư và lập công. Một số người biến chúng thành bất biến và chỉ tạo những cái mới khi cần thay vì cập nhật những cái hiện có. Chúng phải có thể nối tiếp hóa để cho phép truyền qua dây.

Nói chung DTO được sử dụng để chuyển dữ liệu từ lớp này sang lớp khác qua các giới hạn quy trình vì các lệnh gọi đến một dịch vụ từ xa có thể tốn kém vì vậy tất cả dữ liệu được yêu cầu được đẩy vào một DTO và được chuyển đến máy khách trong một đoạn (hạt thô).

Tuy nhiên, một số người sử dụng khái niệm DTO liên kết màn hình (không liên quan gì đến việc vượt qua các giới hạn quy trình). Một lần nữa, những dữ liệu này được điền với dữ liệu bắt buộc (nói chung là dữ liệu cần thiết cho một màn hình cụ thể và có thể là tập hợp dữ liệu từ nhiều nguồn khác nhau) và được gửi đến máy khách.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

Trong các trường hợp đơn giản như đã nêu, DTO này có thể được sử dụng để liên kết với chế độ xem nhưng trong các trường hợp phức tạp hơn, nó sẽ yêu cầu tạo ViewModel và tải dữ liệu từ DTO sang ViewModel, điều này rõ ràng là nhiều công việc hơn (khi áp dụng mẫu MVVM) .

Vì vậy, một lần nữa như đã nêu DTO! = ViewModel

và

DTO và ViewModel có những mục đích khác nhau trong cuộc sống

Đầu tiên, sự khác biệt chính là ViewModel có thể có hành vi hoặc phương thức mà DTO Không được !!!

Thứ hai, việc sử dụng DTO làm ViewModel trong ASP.NET MVC làm cho ứng dụng của bạn được kết hợp chặt chẽ với DTO và đó chính xác là mục đích ngược lại của việc sử dụng DTO. Nếu bạn làm như vậy, sự khác biệt khi sử dụng Model miền hoặc DTO của bạn, phức tạp hơn để có được một anti-pattern?

Ngoài ra ViewModel trong ASP.NET có thể sử dụng DataAnnotations để xác thực.

Cùng một DTO có thể có các Ánh xạ ViewModels khác nhau và Một ViewModel có thể được tạo từ các DTO khác nhau (luôn luôn có ánh xạ đối tượng không phải là thành phần). bởi vì tôi nghĩ thậm chí còn tệ hơn nếu bạn có ViewModel chứa DTO, chúng ta sẽ gặp vấn đề tương tự.

Từ lớp bản trình bày của bạn, hãy nghĩ về DTO như một hợp đồng, bạn sẽ nhận được một đối tượng mà bạn phải coi là xa lạ với ứng dụng của mình và không có bất kỳ quyền kiểm soát nào đối với nó (ngay cả khi bạn có dịch vụ cũ, lớp dto và lớp trình bày là của bạn à).

Cuối cùng, nếu bạn thực hiện tách biệt rõ ràng này, các nhà phát triển có thể làm việc cùng nhau một cách dễ dàng. Người thiết kế ViewModels, Views và Controllers không phải lo lắng về lớp dịch vụ hoặc việc triển khai DTO bởi vì anh ta sẽ lập bản đồ khi những người phát triển khác hoàn thành việc triển khai của họ ... Anh ta thậm chí có thể sử dụng công cụ Mocking hoặc mô phỏng thủ công để lấp đầy lớp trình bày với dữ liệu để kiểm tra.

Đối với một số chế độ xem đơn giản, tôi sẽ sử dụng DTO làm mô hình của mình, nhưng khi Chế độ xem trở nên phức tạp hơn, tôi sẽ tạo ViewModels.

Đối với tôi, đó là sự cân bằng giữa tính nhanh chóng (sử dụng DTO, vì tôi đã có chúng) và tính linh hoạt (tạo ViewModels có nghĩa là tách biệt nhiều mối quan tâm hơn).

Nếu bạn sử dụng DTO làm ViewModel, điều đó có nghĩa là bạn đang phụ thuộc nhiều vào DTO vì lý do nào đó bạn đang thay đổi DTO thì điều đó có thể ảnh hưởng đến ViewModel.

Sử dụng tốt hơn DTO & chuyển đổi thành mô hình xem.

Chúng ta có thể sử dụng DTOgiống như lớp Model và chúng ta có thể sử dụng viewmodel khi cần hiển thị / sử dụng dữ liệu / thuộc tính nhiều mô hình trong một chế độ xem duy nhất. Ví dụ: Tôi tạo một số mô hình bằng cách sử dụng cơ sở dữ liệu khung thực thể trước. Vì vậy, bây giờ tất cả các mô hình tạo ra dựa trên cơ sở dữ liệu. và bây giờ chúng ta cần chú thích dữ liệu, đối với những chú thích dữ liệu đó, chúng ta có thể tạo tên thư mục DTO, Trong thư mục DTO này, chúng ta có thể giữ chính xác tất cả các mô hình đã tạo và thêm chú thích dữ liệu phía trên thuộc tính. Sau đó, chúng ta có thể sử dụng bất kỳ thao tác nào (sử dụng bộ điều khiển, các khung nhìn) bằng cách sử dụng các lớp DTO này. Và khi chúng ta cần chế độ xem phức tạp, ý tôi là khi chúng ta cần nhiều dữ liệu lớp trong một chế độ xem ở đó chúng ta có thể sử dụng mô hình xem. Đối với viewmodel, chúng ta có thể tạo một viewmodel tên thư mục, sau đó tạo một lớp tùy chỉnh và giữ lại thuộc tính mà chúng ta cần. Tôi đã cố gắng thanh minh. Bất kỳ đề nghị đánh giá cao.