Tại sao chúng ta cần một bean để bean mapper như dozer trong một ứng dụng web

Question

Trong thuật ngữ đơn giản, tại sao chúng ta cần 'bean để bean mapping service' (như Dozer) trong một ứng dụng web.

Giả sử tôi đang làm việc trên dịch vụ web.

1. Tôi nhận được XML theo yêu cầu.
2. Tôi tìm nạp các giá trị từ các phần tử XML.
3. Thực hiện thao tác bắt buộc trên các giá trị được tìm nạp.
4. Chuẩn bị XML phản hồi.
5. Gửi XML phản ứng như phản ứng

Tại sao tôi nên thêm một bước của phần tử XML mapping để sở hữu các yếu tố tùy chỉnh.

Tôi không thể thuyết phục bản thân, có lẽ vì tôi không thể nghĩ ra một tình huống/lý do tốt hơn.

Vui lòng đề xuất, ví dụ: nếu có thể.

Answer 1

Giúp giảm khớp nối giữa bản trình bày (ví dụ: lược đồ XML) và logic nghiệp vụ. Ví dụ trong trường hợp thay đổi lược đồ bạn không phải chạm vào logic nghiệp vụ, chỉ cần ánh xạ giữa các đối tượng.

Trong những trường hợp đơn giản, điều đó có thể không đáng để làm phức tạp thêm. Nhưng nếu các đối tượng được sử dụng rộng rãi trong thành phần logic nghiệp vụ, bạn nên xem xét nó.

Answer 2

Giống như câu trả lời nhanh, trường hợp bạn mô tả không phải là câu trả lời duy nhất :).

Giả sử bạn đang làm việc với thư viện nội bộ cung cấp một số POJO/entity/bean khác. Bạn muốn trừu tượng hóa từ biểu diễn bên trong (vì lý do hoặc anohter), sau đó bạn muốn ánh xạ những bean đó cho bạn. Nó hoạt động:

• cho ejb client, hoặc somehting như thế,
• khi bạn không muốn để lộ nội tổ chức (Business Object vs đối tượng Presentation) (xem @ trả lời của Henry)
• bạn có đậu mà không kế thừa so với cùng mẹ (và có thể không cho bất kỳ lý do nào, thậm chí leacy) và bạn muốn tarnsfert giá trị từ trên khác

Có rất nhiều (khác) lý do :)

Như một lời khuyên xem thêm orika và bài đăng này: any tool for java object to object mapping?

Answer 3

Câu trả lời ngắn đối với tôi như henry nói nó giúp giảm khớp nối giữa những gì bạn vạch trần hoặc tiêu thụ và mô hình dữ liệu cốt lõi của bạn.

Đó là một cách xây dựng Hexagonal Architecture. Bạn có thể tự do sửa đổi mô hình cốt lõi của mình mà không ảnh hưởng đến mô hình tiếp xúc. Trong kiến ​​trúc lục giác, nó được sử dụng để chỉ trưng ra một phần nhỏ có liên quan của mô hình cốt lõi.

Nó cũng là một cách rất goog để xử lý dịch vụ và phiên bản mô hình vì nhiều phiên bản có thể được ánh xạ tới mô hình cốt lõi.

Khi làm việc với dịch vụ XML, tôi có xu hướng xây dựng ứng dụng đầu tiên theo hợp đồng, trước tiên tôi viết XMLSchema rồi tạo Jaxbeans và tôi thực sự không muốn mã kinh doanh của mình bị ô nhiễm bởi chú thích JAxb.

Nếu bạn biết rằng mô hình tiếp xúc của bạn sẽ luôn giống nhau và ứng dụng của bạn không nằm trong các trường hợp được đề cập trước đây, vì vậy bạn thực sự không cần sử dụng DTO. Cuối cùng, tôi khuyên bạn nên sử dụng một khung với thời gian biên dịch mạnh mẽ như Selma thay vì Dozer hoặc Orika bởi vì chúng chỉ đánh giá bản đồ khi thời gian chạy bị đánh máy yếu và hợp lý để tái cấu trúc.