2012-07-04 35 views
8

Chúng tôi có một ứng dụng java n-tier điển hình và tôi nhận thấy rằng các lớp truy cập dữ liệu của chúng tôi có DAO là loại FooDAO và FooDAOImpl. Tôi đang tìm cách biện minh cho nhu cầu của cả hai và đây là phân tích của tôi.Cần có giao diện riêng và impl cho DAO

  1. Nếu bạn có nhiều triển khai cho cùng một giao diện, việc trừu tượng sẽ hữu ích. Nhưng cho rằng chúng tôi đã thực hiện sự lựa chọn của khuôn khổ được sử dụng cho DAOImpl (nói iBATIS), là nó thực sự cần thiết?
  2. Trợ giúp ủy quyền qua Spring. Từ những gì tôi thu thập, các lớp có giao diện có thể được ủy nhiệm một cách dễ dàng (đi theo tuyến đường JdkProxy) thay vì các lớp không có giao diện (nơi tuyến đường cglib được chọn) và một lớp có lớp con được ủy nhiệm. Phân lớp có các vấn đề của nó khi lớp được ủy quyền là cuối cùng hoặc không có các hàm tạo mặc định - cả hai đều khó xảy ra ở lớp truy cập dữ liệu. Hiệu suất được sử dụng để là một yếu tố, nhưng từ những gì tôi nghe, nó không còn là một nguyên nhân của mối quan tâm.
  3. Trợ giúp chế nhạo. Các lớp có giao diện phù hợp hơn với các khung mocking. Tôi chỉ nghe thấy điều này, nhưng không nhìn thấy nó trong thực tế - vì vậy không thể thực sự dựa vào nó, nhưng có lẽ vì các yếu tố tương tự như đã đề cập trong # 2 ở trên.

Với những điểm này, tôi không cảm thấy nhu cầu thực sự về FooDAO và FooDAOImpl riêng biệt khi FooDAO đơn giản đủ. Vui lòng sửa bất kỳ điểm nào mà tôi đã đề cập.

Cảm ơn trước!

+1

Trừ khi tôi nhầm, bạn không thực sự đặt câu hỏi tại đây? Lợi ích của việc sử dụng giao diện với tiêm đã được nêu trong 'câu hỏi' của bạn ... – steelshark

+0

Vâng, bạn đã nói ba lý do chính đáng để sử dụng giao diện và thực hiện DAO của bạn. Tôi đã rút ra kết luận ngược lại với bạn, cụ thể là cần phải có một giao diện! –

+0

@ user935439 Câu hỏi đặt ra ở mỗi điểm bullet. Mặc dù chúng tôi đồng ý về lợi ích của giao diện về nguyên tắc, tôi muốn thu thập ý kiến ​​về sự thèm ăn của việc giảm các tệp lớp mà tôi phải viết và duy trì khi lợi ích của giao diện trong trường hợp sử dụng đó không hoàn toàn rõ ràng. Bạn có biết với các ví dụ nếu mocking dễ dàng hơn khi bạn có giao diện không? Cảm ơn! – Kilokahn

Trả lời

2

Tôi đã thử # 3 với Mockito và nó có thể giả lập POJO mà không cần giao diện tốt. Với các đối số đề cập đến # 1 và # 2, tôi nghiêng không đi với DAO và DAOImpl riêng biệt cho bây giờ. Vui lòng thêm các điểm so sánh khác.

1

tôi thấy một lý do thứ tư:

  • chi tiết Ẩn thực hiện

Tùy ví dụ trong nhóm, tuổi thọ dự kiến ​​của phần mềm hoặc số lượng thay đổi dự đoán trong tương lai, nó trả tiền để ẩn càng nhiều càng tốt ngay cả khi chỉ có một triển khai.

0

Tôi có thể nói rằng có giao diện FooDAO với một triển khai đơn lẻ FooDAOImpl nói chung là chống mẫu. Các giải pháp đơn giản (không có giao diện riêng biệt cho DAO) là thích hợp hơn nhiều, trừ khi bạn có một lý do vững chắc nếu không - mà dường như không phải là trường hợp ở đây.

Cá nhân, tôi sẽ tiến xa hơn và nói rằng có DAO ở tất cả không phải là lựa chọn tốt nhất. Tôi thích có một lớp mặt tiền kiên trì duy nhất được triển khai trên đầu trang của một API ORM như Hibernate hoặc JPA. Có lẽ iBATIS là quá thấp cấp cho điều đó, mặc dù.

Các vấn đề liên quan