Máy ảo JHipster vs DTO

Question

tôi muốn hiểu thêm một chút về quyết định tùy chọn tạo DTO của JHipster. Tôi có một số câu hỏi về nó.

1. Tại sao nó được gọi là DTO? Nó được mô tả trong release notes of JHipster 3.6.0, nó có thể được sử dụng để thực thi logic nghiệp vụ trên các đối tượng này. Nếu đây thực sự là ý định của nó, thì nó không chỉ là một DTO (Data Transfer Object). Nó là nhiều hơn, đó là trong ý kiến ​​của tôi một đối tượng tên miền. Ok, có lẽ đây cũng không phải là một thuật ngữ lý tưởng, vì Domain Object cũng được hiểu như là một thuật ngữ cha mẹ cho DTO, thực thể, vv Từ góc độ DDD, nó cũng có thể được gọi là Aggregate, vì nó kết hợp nhiều đối tượng Domain.

2. Dựa trên 1., tôi nghĩ rằng giàn giáo hiện tại của DTO không phù hợp với ý định của DTO kết hợp nhiều thực thể. Trong trường hợp đó, nó sẽ không liên quan đến một thực thể cụ thể và do đó không nên được tạo ra trong bối cảnh của thực thể đó.

3. Tôi nghĩ rằng giàn giáo hiện tại của DTO phù hợp hơn nhiều với định nghĩa của máy ảo của JHipster (Xem mô hình). Nếu bạn có một thực thể phức tạp với rất nhiều quan hệ và có lẽ cũng có một số dữ liệu blob hoặc clob, bạn không muốn gửi tất cả dữ liệu đó đến giao diện người dùng. Bạn cần một máy ảo để cắt bỏ các đối tượng phụ thuộc, không cần thiết bởi giao diện người dùng. Điều này phù hợp với giàn giáo DTO hiện tại, vì các mối quan hệ chỉ được đại diện bởi các ID. Đây cũng là những gì vẫn được mô tả trên trang web của JHipster cho DTOs. Tôi nghĩ rằng mô tả này không được chấp nhận và phù hợp với máy ảo, nhưng không phù hợp với DTO nữa. Dưới đây là trích dẫn từ website JHipster:

Những đối tượng thêm thêm một lớp trên đầu trang của các đối tượng miền, và được điều chỉnh đặc biệt cho lớp REST của

đã khái niệm về DTOs và máy ảo không được suy nghĩ hoàn toàn, hoặc tôi đang thiếu một số khía cạnh quan trọng?

Answer 1

Mặc dù tôi không thể nói tại sao quyết định được thực hiện bởi nhóm, tôi hoàn toàn đồng ý rằng khái niệm DTO/VM-không rõ ràng.

Tôi nghĩ, ý tưởng cơ bản là tương tự với mẫu MVP/MVC, nơi thường có một mô hình xem mới được giới thiệu để nhận mẫu MVVM. Vì vậy, các DTO không ảnh hưởng đến bất kỳ khung nhìn nào đã được "đẩy" vào lớp mô hình/bộ điều khiển thực tế. Đó là ok, nếu bạn nói rằng một DTO là một đối tượng chuyển giao giữa các dịch vụ.

Tuy nhiên, chúng tôi cũng gặp "sự cố" và rất nhiều cuộc thảo luận với các lớp và DTO, VM, v.v. trong ứng dụng jhipster cũ hơn của chúng tôi. Chúng tôi bắt đầu cùng lúc khi jhipster giới thiệu các công cụ DTO và Mapstruct. Trong các dự án mới, nơi chúng tôi sử dụng Jhipster, chúng tôi luôn xóa tất cả các DTO và VM. Trước hết: công cụ UserVM/DTO (Được quản lý), rất khó hiểu. Điều này có một số lý do:

Chúng tôi chưa bao giờ có máy ảo ở phía máy chủ của các ứng dụng của chúng tôi. Trong một ứng dụng jhipster, nơi khung nhìn hoàn toàn dựa trên javascript/góc cạnh, thì mô hình khung nhìn phải ở đó. Chúng ta thường có các ứng dụng khác sử dụng REST-API và các ứng dụng này không phải là các khung nhìn. Vì vậy, đặc biệt là trong một kiến ​​trúc microservice, tôi sẽ không bao giờ gọi một cái gì đó trong một khung nhìn REST-API hoặc thậm chí là "view-model". Vì vậy, trong các ứng dụng như vậy mà không có khung nhìn nào được viết bằng Java (với JSP hoặc như vậy), bạn sẽ không bao giờ tìm thấy thuật ngữ "VM" trong mã Java của chúng ta. Hơn nữa, có thể có các loại chế độ xem khác nhau (ví dụ: ứng dụng web góc, ứng dụng iOS, máy tính để bàn hoặc các thứ khác) và mỗi chế độ xem khác, xem các bộ phận, tiện ích và do đó cần các kiểu xem khác. Cuối cùng, có một số người nói rằng REST-API có thể không cung cấp bất kỳ nội dung nào không phải là tài nguyên/thực thể thực sự ...

Vì vậy, bạn hoàn toàn đúng là các máy ảo trong jhipster thực ra là DTO. Nhưng, như bạn cũng nói, có một vấn đề với "DTO", bởi vì thông thường DTO chỉ là một đối tượng chuyển giao không trạng thái để đóng gói các giá trị chung giữa hai hoặc nhiều dịch vụ (hoặc hệ thống) mà không có bất kỳ logic nào. Chúng tôi nghĩ rằng đây cũng là một vấn đề kiến ​​trúc giữa thiết kế điều khiển miền từ trên xuống dưới (REST) ​​API và hướng xuống dưới, bằng cách nào đó được trộn lẫn trong các ứng dụng JHipster. Tương tự như ý kiến ​​của bạn, tôi nghĩ rằng JHipster sử dụng DTO nơi nó phải là một đối tượng miền (hoặc một thực thể). Ví dụ. người dùng được quản lý không phải là máy ảo hoặc DTO, nó là một thực thể. Tôi nghĩ, vấn đề ở đây là một số người nghĩ rằng chỉ có các thực thể dựa trên JPA là các đối tượng miền và có thể không có các đối tượng miền khác (các thực thể).

Cuối cùng, chúng tôi quyết định giới thiệu một loại mới được gọi là ADO (Đối tượng dữ liệu API hoặc Đối tượng dữ liệu truy cập), vì chúng tôi không tìm thấy thuật ngữ nào phù hợp. Một ADO được so sánh với jhipster một máy ảo, một DTO hoặc thậm chí một thực thể không có bất kỳ logic nào. "Lớp API" chung chỉ đọc và viết ADO. Lớp này được sử dụng cho các bộ điều khiển REST API cũng như cho một API Java có thể được sử dụng bởi các plugin. Điều này cho chúng ta khả năng gửi tất cả các ADO với client-API-jar mà không cần thêm bất kỳ thực thể nội bộ hoặc đối tượng miền cụ thể nào. Vì REST-API và mỗi plugin sử dụng cùng một ADO (và do đó cùng mô tả và cấu trúc), các nhà phát triển không bị nhầm lẫn và các lớp định hướng tài nguyên bên ngoài được tách biệt hoàn toàn với các lớp bên trong sử dụng một logic nghiệp vụ khác dựa trên.

Mọi thứ khác là một phần của lớp bên trong như thực thể, thực thể được thừa kế, tập hợp con hoặc bộ siêu của thực thể chủ yếu là các đối tượng miền. Vì vậy, chúng tôi đã loại bỏ tất cả các VM và DTO khỏi lớp nội bộ này, logic nghiệp vụ, v.v.

Tổng hợp: Để đóng gói các thực thể nội bộ (JPA) từ truy cập bên ngoài, chúng tôi sử dụng ADO, vì có thể có các đối tượng khác không chỉ là chế độ xem. Những ADO này là về máy ảo jhipster cũng như DTO. Nhưng nội bộ đằng sau lớp API chung, chúng tôi không bao giờ sử dụng bất kỳ DTO hoặc VM hoặc thậm chí một ADO, bởi vì các thực thể đó chủ yếu là các đối tượng miền.