Sử dụng các đối tượng truyền dữ liệu trong ejb3 được coi là thực hành tốt nhất

Question

Mặc dù rõ ràng không phải tất cả các kịch bản đều có thể được bao phủ bởi một thiết kế duy nhất, hiện tại chúng ta cảm thấy rằng các lớp ORM phải được chuyển đến và giữa lớp trình bày và lớp nghiệp vụ (địa phương hoặc từ xa), thay thế nhu cầu cho các đối tượng chuyển dữ liệu? Theo như tôi có thể thấy, sử dụng các lớp ORM trình bày các vấn đề tải không mong muốn, các vấn đề quản lý ngữ cảnh và ghép nối chặt chẽ, nhưng cũng tiết kiệm rất nhiều thời gian và giữ mọi thứ đơn giản. Có phải bây giờ là một cách tiếp cận tiêu chuẩn mà thường ủng hộ một trong những khác (đối với phần lớn các tình huống)?

Answer 1

Đây là câu hỏi rất thú vị và tôi đã điều tra và thử nghiệm với hơn hai năm qua.

Tôi nghĩ thực sự không có câu trả lời đúng hay sai ở đây. Tôi không nghĩ rằng bạn có thể chỉ đơn giản nói rằng tôi muốn một trong những khác vì thông thường bạn có thể muốn một lai tùy thuộc vào những gì khách hàng của bạn (trang web, ws, máy và/hoặc địa phương, từ xa).

Điều quan trọng cần nhớ ở đây là những ưu điểm và nhược điểm của mỗi đề xuất và áp dụng điều này dựa trên yêu cầu của bạn.

Ví dụ:

• Nếu bạn đang sử dụng Seam, sau đó bạn sẽ muốn tránh một kiến ​​trúc nặng nề lớp bởi vì bạn có quyền truy cập vào một bối cảnh kiên trì mở rộng. Các công nghệ web khác không có hỗ trợ này có xu hướng hoạt động tốt hơn với DTO đã chuẩn bị trước trạng thái.
• Nếu bạn đang gửi một tin nhắn từ xa điều nhập khẩu để giữ cho nó mỏng và nhẹ, DTO thường hoạt động tốt hơn ở đây so với đối tượng miền phong phú. Ở đây bạn có thể ngăn chặn rõ ràng bất kỳ vấn đề/hành vi ORM nào.
• Mẫu DTO có lợi ích trong việc bảo vệ khách hàng của bạn khỏi các thay đổi tên miền. Điều này đặc biệt quan trọng nếu ứng dụng của bạn là một dịch vụ web, có đối tượng miền (đối tượng) xác định hợp đồng của bạn có thể khiến bạn không bị bỏ lỡ tại một số thời điểm.

Bằng cách gói hệ thống của bạn theo lớp và cẩn thận phơi bày và bảo mật chúng, bạn có thể tạo nhiều API khác nhau cho nhiều khách hàng thuộc nhiều loại khác nhau.

Answer 2

Tôi nghĩ rằng sự tồn tại của DTO có liên quan đến lỗ hổng JPA/Hibernate . Nếu bạn luôn có thể làm khởi tạo lười biếng trong suốt, bạn sẽ không bao giờ sử dụng chúng. Vì vậy, việc sử dụng DTO là một hợp đồng trong đó miền/không gian làm việc của tôi luôn bị mất (trùng lặp ở mọi nơi). Tổng hợp, bạn có thể sử dụng chúng nhưng bạn phải ghét chúng :)

Answer 3

Khớp nối chặt? Vui lòng giải thích.

Đối với tôi, DTO là một mẫu chống. EJB3 cho phép chúng tôi bỏ qua việc sử dụng chúng. Bạn có thể chỉ cần khởi tạo lười biếng của bạn trước khi gửi Entity cho khách hàng.

Tất nhiên nếu bạn chỉ cần hai trong số 30 trường để gửi cho ứng dụng khách, bạn chỉ cần gửi cho họ. Nhưng nếu là toàn bộ bản sao tất cả các thời gian như trong dự án hiện tại của tôi - cố gắng để thoát khỏi DTO đó. Tôi không thấy lý do gì để sử dụng chúng. Bạn gửi một đối tượng nghiệp vụ cho khách hàng như một khách hàng được hỏi. Tại sao sử dụng trình bao bọc?

Answer 4

Tôi đồng ý với "loa" cuối cùng tại sao sử dụng trình bao bọc khi ở trong ejb3 ?? Chúng tôi xây dựng một hệ thống khá phức tạp mà không có DTO nhưng sử dụng các thực thể (JPA) mà nó hoạt động. Rõ ràng ...

Answer 5

chỉ làm việc với các thực thể sẽ ổn nếu bộ điều khiển GUI gửi đối tượng thích hợp với các biểu mẫu chứ không phải đối tượng thực thể.Mặt khác, nếu các thực thể được sử dụng và các thực thể này có mối quan hệ nhiều-một, thì người ta sẽ thấy một số ngoại lệ khó chịu, nếu các thực thể không được trình quản lý thực thể háo hức tìm nạp.

Các tình huống như vậy có thể được quan sát thấy khi cố gắng điền các thẻ của Spring MVC chẳng hạn, hoặc các cấu trúc tương tự của các thành phần GUI khác.

Hơn nữa, DTOs là một nơi rất tốt để đặt chú thích bổ sung như chú thích xác nhận hoặc JAXB, vv

Answer 6

Tôi có một số vấn đề đối với sử dụng thực thể ở lớp trình bày:

• Khóa-in: Điều này cuối cùng tạo ra khóa chặt chẽ giữa bản trình bày và mô hình của bạn. Nó trở nên đắt tiền để thay đổi, hoặc trong các dự án lớn, thậm chí không thể. Các công cụ hiện đại chưa hoàn toàn có.

• Bảo mật: Với đối tượng mô hình, bạn dễ dàng chuyển thông tin id cơ sở dữ liệu khác nhau đến trang web của mình. Đây là vấn đề bảo mật rõ ràng. Sử dụng dto:s bạn có thể ẩn những thứ này tại máy chủ với các bản đồ phiên rất đơn giản.

• Sự khác biệt về nhu cầu: Giao diện GUI hiếm khi liệt kê trực tiếp các đối tượng mô hình. Thông thường, chúng là thứ gì đó nhiều hơn, kết hợp các con thú, guish. Nhu cầu của GUI có xu hướng leo vào mô hình của bạn che khuất nó.

• Tốc độ: Với thực thể, mọi trường được xử lý mỗi khi bạn đọc/ghi chúng. Vì bạn đang chuyển chúng trực tiếp đến lớp trình bày, bạn có một thời gian khó cố gắng tối ưu hóa các truy vấn JPA của bạn - hầu như không thể. Tôi chắc chắn sẽ quay lại trực tiếp JDBC -truy cập - như myBatis trong các dự án trong tương lai. Do đó loại bỏ ORM.

Tôi có một vấn đề đối với DTO:s quá:

• tắm DAO mã.

Những điều được xem xét, tôi sẽ bỏ phiếu cho việc sử dụng dto:s cho tất cả các dự án, cũng loại bỏ JPA. Vì vậy, chồng tôi trở thành một cái gì đó như:

• myBatis để truy cập cơ sở dữ liệu
• POJO như DTO: s
• Stateless EJB cho các dịch vụ DAO tôi.
• StatefulEJB cho chương trình phụ trợ GUI.
• JSF để trình bày.