Thực tiễn không tốt là sử dụng các đối tượng thực thể trên tất cả các lớp của ứng dụng web?

Question

Tôi đang phát triển một ứng dụng web bằng cách sử dụng kiến ​​trúc phân lớp. Tôi có:

1. Application Layer (Controller)
2. Service Layer (Dịch vụ)
3. Data Access Layer (DAO)

này kết nối với một cơ sở dữ liệu backend Oracle.

Tôi đang sử dụng JPA với Hibernate làm việc triển khai. Do đó, tôi tạo các thực thể để mô hình hóa khung nhìn đối tượng của các bảng cơ sở dữ liệu quan hệ của tôi.

Câu hỏi của tôi là ... Có được coi là thực hành không tốt để sử dụng các đối tượng thực thể này trên tất cả 3 lớp của tôi không?

Tôi biết nó cần phải được sử dụng bởi lớp Truy cập dữ liệu ít nhất nhưng còn hơn thế nữa về lớp Ứng dụng & Ứng dụng?

Tôi đã thấy một số người sử dụng DTO trong dịch vụ & lớp ứng dụng thay vào đó và họ thực hiện chuyển đổi giữa các DTO và thực thể giữa các lớp Dịch vụ & Truy cập dữ liệu.

Chỉ cần tự hỏi thực hành tốt nhất cho điều này là gì và cách tiếp cận tốt nhất là gì?

Answer 1

Bạn không bao giờ nên sử dụng đối tượng thực thể của mình trong tất cả các lớp. Bằng cách sử dụng cùng một đối tượng trong tất cả các lớp, bạn thực hiện khớp nối chặt chẽ giữa dữ liệu biểu mẫu giao diện người dùng và bảng cơ sở dữ liệu.

Nếu bạn muốn thay đổi tên trường trên giao diện người dùng, thì bạn cần sửa đổi cột tương ứng trong bảng của mình. Do đó nó được khuyên DTOs, VOs để thực hiện các dữ liệu từ DAO để kết thúc trước của bạn. Sử dụng các loại bản đồ khác nhau có sẵn trên thị trường. Một trong những ví dụ là orika mapper.

Answer 2

Có trường hợp khi đối tượng dữ liệu khớp chính xác với đối tượng mà người dùng thao tác trên màn hình. Mặt khác, có những trường hợp khi người dùng làm việc trên các đối tượng có nguồn gốc và/hoặc ảnh hưởng đến nhiều đối tượng theo logic nghiệp vụ. Nhiều ứng dụng báo cáo là các ví dụ về ứng dụng sau.

Tùy thuộc vào tên miền và hồ sơ người dùng của bạn tần suất dữ liệu khớp/trường hợp đối tượng giao diện người dùng cao hoặc thấp. Bạn nên xác định các mô hình riêng biệt khi cần và có chi phí duy trì chúng thông qua các thay đổi trong dự án của bạn. Do đó, các mô hình tách biệt quá mức là thực hành không tốt. Mặt khác, nếu bạn nhấn mạnh vào việc truyền các mô hình dữ liệu ở khắp mọi nơi, logic nghiệp vụ hoặc mã giao diện người dùng của bạn có thể không rất sạch sẽ.

Quyết định tách riêng các đối tượng lớp truy cập dữ liệu và các đối tượng được chuyển đến giao diện người dùng cũng tùy thuộc vào công cụ đang sử dụng. Ví dụ, trong trường hợp bộ điều khiển nối tiếp thành JSON theo một cách tĩnh (*), người ta có thể chọn định nghĩa các lớp cho mỗi lần duyệt cây khác nhau (được sử dụng) của biểu đồ đối tượng. Mặt khác, các đối tượng tương tự có thể sử dụng được với giao diện người dùng dựa trên JSP.

(*) Ví dụ là jackson, sử dụng chú thích sửa cách cách đối tượng (đồ thị) được tuần tự hóa thành cây. Có tồn tại có nghĩa là để hạn chế cây -useful để ngăn ngừa rò rỉ dữ liệu không mong muốn-tuy nhiên thực tế của họ và bảo trì được giới hạn, trong trường hợp tôi gặp phải.