Đối tượng mô hình miền có đang chuyển giữa các lớp trên không?

Question

Tôi đang làm việc trên một dự án sử dụng ngủ đông và mùa xuân. Hibernate được đóng gói trong một lớp DAO và lớp DAO có lớp dịch vụ tương ứng là tốt, cũng có các bộ điều khiển được ánh xạ cho các yêu cầu và các trang JSP. Tôi đã nói không vượt qua các đối tượng giữa các lớp này (Bộ điều khiển < -> Dịch vụ < -> DAO) vì nó là chi phí hoạt động. Một ví dụ cụ thể là khi tôi cần cập nhật một giá trị boolean trong một đối tượng miền (lớp ORM), tôi đã viết một phương thức truyền đối tượng miền giữa lớp Service và lớp DAO, và tôi được yêu cầu chuyển ID đối tượng và boolean cụ thể chỉ có giá trị và để viết các phương thức riêng biệt trong các lớp cho điều đó. Thê nay đung không? Tôi cảm thấy làm như vậy sẽ vô hiệu hóa nhiều lợi thế của việc sử dụng một công cụ ORM (Hibernate). Tôi có sai khi nghĩ về điều này không? Mọi lời khuyên và thông tin chi tiết sẽ hữu ích ....

Answer 1

Bạn đang 100% bên phải. Đó là lời khuyên khủng khiếp. Vượt qua các đối tượng xung quanh. Đó là chính xác những gì Hibernate được thiết kế cho, và "hiệu suất trên không" cho đi qua bình thường của các đối tượng chỉ là điên. Trừ khi có điều gì đó về ứng dụng mà bạn không biết, hãy cảnh giác với lời khuyên của người đã nói với bạn điều đó.

Answer 2

Như với hầu hết các vấn đề kiến ​​trúc, có một sự cân bằng được thực hiện ở đây.

Đối với các ứng dụng không mong muốn sử dụng kiến ​​trúc hướng dịch vụ (ví dụ: trang web độc lập có cơ sở dữ liệu sao lưu, một ứng dụng doanh nghiệp nội bộ), tốt hơn hết là phải tiếp xúc với mô hình miền của bạn ở tất cả các lớp của ứng dụng. Điều này đảm bảo rằng bạn không vi phạm nguyên tắc DRY (Don't Repeat Yourself) và bạn không phải thực hiện nhiều lần tái cấu trúc mỗi lần bạn thêm thuộc tính mới vào mô hình miền của mình. Bạn cũng có thể sử dụng một khuôn khổ như NHibernate Validator để xác định tất cả các xác nhận của bạn một lần, và sử dụng xác nhận đó cho cả lớp dữ liệu và lớp web.

Đối với các ứng dụng lớn hơn chứa nhiều dịch vụ riêng biệt (ví dụ: các bộ ứng dụng doanh nghiệp nội bộ lớn), bạn nên tách ORM khỏi giao diện của dịch vụ. Điều này sẽ cho phép bạn thay đổi các mô hình truy cập dữ liệu mà không thay đổi giao diện của dịch vụ (và ngược lại), điều này cực kỳ có giá trị khi nhiều dịch vụ khác phụ thuộc vào giao diện của bạn ổn định. Tuy nhiên, tình huống bạn mô tả (sử dụng các phương pháp để thay đổi các thuộc tính cụ thể) dường như không khớp với một trong hai trường hợp này: thường là một ý tưởng tồi để theo dõi mô hình bạn đã mô tả khi nó theo dõi đường dẫn thực hiện và tái cấu trúc rất khó (và có thể dẫn đến mã spaghetti). Chỉ có thể sử dụng số dặm mà tôi có thể nghĩ là nếu các mô hình dữ liệu của bạn rất lớn (các đốm màu XML 5k, vv) và gửi chúng qua lớp dịch vụ sẽ tạo ra một lượng lớn lưu lượng truy cập. (NB: Các đối tượng C# nhỏ hơn 5k khi được sắp xếp chính xác!)

Tôi khuyên bạn nên chuyển toàn bộ mô hình truy cập dữ liệu lên lớp web.

Answer 3

sớm tối ưu hóa là gốc rễ của mọi tội lỗi

Ngay cả trong High Frequency Thương mại, nơi 50 nano giây vấn đề, bạn làm gì là quyền đầu tiên, và sau đó bạn tối ưu hóa nếu cần thiết. Bạn sẽ ngạc nhiên về những gì trình biên dịch hiện đại/băng thông mạng có thể thực hiện.

Để trả lời câu hỏi của bạn trực tiếp hơn => chuyển các Đối tượng đó xung quanh và không nghĩ về hiệu suất. Bạn sẽ, nếu bạn cần phải sau này, nhưng nó là cao không có khả năng nó sẽ gây ra bởi việc truyền các Vật thể xung quanh.