Mẫu lưu trữ so với thực thể quản lý DAO

Tôi chưa quen với các khái niệm như DAO, DAL và Domain Driven Design. Cuối cùng, tôi muốn tách lớp kiên trì (cơ sở dữ liệu mysql) khỏi các đối tượng kinh doanh và logic của tôi trong một ứng dụng web. Tôi thích khái niệm DAO nhưng tôi gặp khó khăn khi triển khai nó khi tôi muốn tạo Đối tượng kinh doanh từ cơ sở dữ liệu có các thực thể khác được liên kết với nó (được biểu thị bằng khóa ngoại trong bảng db).

1. Các tham chiếu (tập hợp) này được xử lý bằng mẫu DAO như thế nào? Mỗi ví dụ DAO trực tuyến đều đơn giản và chỉ hiển thị việc tạo các Đối tượng Kinh doanh giống như đối tượng giá trị (mà không tham chiếu các thực thể hoặc đối tượng giá trị khác). Được thực hiện bằng cách sử dụng Dependency Injection và nếu vậy, sự phụ thuộc được tạo ra ở đâu?
2. Bằng cách đọc thêm, tôi đoán rằng mẫu Kho lưu trữ từ DDD cho khả năng có thể sử dụng các DAO đằng sau hậu trường và xử lý các tập hợp đối tượng. Theo tôi hiểu, nó chỉ cung cấp cái gọi là root (Thực thể với tất cả các tham chiếu được tải hoặc lười tải) cho thế giới bên ngoài, điều có vẻ là một cách tiếp cận tốt với tôi. Kho lưu trữ có được đề xuất khi sử dụng DAO hay chính DAO có thể cung cấp chức năng này bằng cách duy trì sự thiếu hiểu biết liên tục cho các đối tượng kinh doanh.

Tôi không sử dụng công cụ ORM và không muốn trực tiếp khám phá các mẫu cơ bản này

Có hai mối quan tâm để giải quyết - đó là trực giao với nhau:

1) Sự kết thúc của sự kiên trì

Đây là nơi bạn phải đối phó với các kết nối , truy vấn , kết quả và tương tự. Thông thường, bạn sử dụng một hoặc một khung công tác khác cung cấp cho bạn một mô hình mặt tiền trong tay, nó trừu tượng hóa đi những thứ bẩn thỉu để bạn chỉ nói, những gì bạn muốn biết (resultset từ Truy vấn) và nơi khung có thể tìm thấy nó ( Truy vấn và kết nối). Những gì bạn làm với các kết quả là tùy thuộc vào bạn.

Khi mô hình của bạn là OOP, có một bước bổ sung liên quan: lắp ráp tập kết quả vào các đối tượng. Hoặc là bạn làm thủ công hoặc có một trình ánh xạ quan hệ đối tượng thực hiện công việc cho bạn.

2) Sự trừu tượng hóa trong ứng dụng của bạn Trên lớp cấp thấp này là sự trừu tượng hóa mà ứng dụng của bạn xử lý. Có là DataAccessObject (DAO) -Layer hoặc Repository -Layer. Cả hai đều tạo Đối tượng để Ứng dụng của bạn hoạt động.

Cái nào bạn đang sử dụng không có tác dụng đối với câu trả lời của câu hỏi của bạn.

Câu hỏi của bạn là một mặt về mô hình hóa ( »Cách xử lý mối quan hệ giữa các đối tượng« Trả lời: thông qua Thành phần / Tập hợp ) và về cách điền vào đối tượng (và các phụ thuộc của nó) với dữ liệu.

Được thực hiện bằng cách sử dụng Dependency Injection và nếu vậy, sự phụ thuộc được tạo ra ở đâu?

Đây là con đường để đi. Có hai cách:

1) Bạn làm cho DI rõ ràng và xác định một hàm tạo. Khi tạo Đối tượng, trước tiên bạn có thể tạo tất cả các phụ thuộc và tiêm chúng thông qua hàm tạo hoặc hàm setter

2) Bạn sử dụng một khung làm việc kỳ diệu cho bạn. Thông thường sự phản ánh có liên quan, tức là có một số khả năng trong một số ngôn ngữ để kiểm tra và thao tác với các đối tượng một cách nhanh chóng. Việc tiêm được thực hiện một cách minh bạch cho người dùng theo khung.

Điều này là độc lập với mẫu DAO / Kho lưu trữ.

Tôi không sử dụng công cụ ORM và không muốn trực tiếp khám phá các mẫu cơ bản này

Đó là một cách tiếp cận cao quý, nhưng không phải trong mọi trường hợp đều hiệu quả. Hầu hết thời gian, bạn muốn hoàn thành công việc. Đối với mục đích giáo dục, bạn có thể đi trên con đường đó. Nhưng tôi sẽ không đề nghị nó.

Hãy tìm kiếm một ORM-Framework linh hoạt, giúp bạn giúp đỡ khi cần mà không buộc bạn phải bằng cách này hay cách khác. Không phải trong mọi trường hợp là truy vấn tạo ootB có hiệu quả. Một khung công tác tốt cho phép bạn sử dụng SQL khi cần và chỉ quan tâm đến phần lắp ráp .

Đây là nơi ORM (ánh xạ quan hệ đối tượng) có ích. Có thư viện cho nhiều ngôn ngữ lập trình, cung cấp loại kỹ thuật lập trình này. Ví dụ, đối với Java có Hibernate . Hibernate hoạt động với các chú thích Java. Đây là một ví dụ đơn giản cho nhiều mối quan hệ từ một tài liệu chính thức :

@Entity
public class Flight implements Serializable {
    @ManyToOne(cascade={CascadeType.PERSIST, CascadeType.MERGE})
    @JoinColumn(name="COMP_ID")
    public Company getCompany() {
        return company;
    }
    ...
}