Thực tiễn tốt nhất: Các mẫu lập trình ứng dụng cơ sở dữ liệu

Tôi đã viết nhiều ứng dụng web cơ sở dữ liệu (MySQL) cho đến nay nhưng tôi luôn nghĩ rằng cấu trúc của tôi hơi vụng về. Tôi muốn cải thiện mẫu lập trình / thiết kế mà tôi sử dụng, hy vọng một số lời khuyên ở đây. Đặc biệt, tôi không thể tìm thấy một cấu trúc bổ sung cho cách tiếp cận OOP đóng gói việc thực hiện cơ sở dữ liệu (lược đồ). Tôi

Hãy nghĩ rằng câu hỏi của tôi có thể được giải thích tốt nhất bằng ví dụ. Có 2 cách tiếp cận tôi sử dụng bây giờ nói rằng tôi có một đối tượng / lớp Hóa đơn:

đầu tiên là sử dụng các hàm thành viên tĩnh

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

Cách tiếp cận thứ hai là đặt mọi thứ trong một đối tượng cơ sở dữ liệu:

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

Tôi thấy rằng cả hai cách các hàm thành viên (SQL) đều không thể tách rời khỏi "khung nhìn", trong đó "khung nhìn" xác định những gì các lớp cần phải có và do đó dường như phá vỡ kiến ​​trúc tài liệu / khung nhìn.

Ngoài ra, có vẻ như không hiệu quả, ví dụ, một câu lệnh CHỌN chỉ nên chọn những gì cần thiết, nhưng sự hiện diện của các biến thành viên trong Hóa đơn dường như ngụ ý "dữ liệu được bảo đảm".

Không biết nếu tôi giải thích rõ ràng câu hỏi, một số cách tiếp cận tốt nhất khác đối với kiến ​​trúc / mẫu thiết kế này / cái gì được biết đến như là gì?

Cảm ơn lời khuyên

Vâng, tôi cho rằng bạn có thể sử dụng ORM.

Nhưng thực sự, thiết kế cơ sở dữ liệu KHÔNG nên theo dự đoán OOP, nó nên tuân theo các dự đoán thiết kế cơ sở dữ liệu như chuẩn hóa. Và nó nên được thiết kế tại cơ sở dữ liệu không có trong ứng dụng. Và các quy tắc toàn vẹn dữ liệu nên được thi hành ở cấp cơ sở dữ liệu chứ không phải bởi ứng dụng.

Tôi sẽ đề nghị bạn đọc một số sách thiết kế cơ sở dữ liệu và sau đó, đọc về hiệu suất điều chỉnh cơ sở dữ liệu bạn chọn.

Tôi không thể tìm thấy cấu trúc bổ sung cho cách tiếp cận OOP đóng gói việc triển khai cơ sở dữ liệu

Có vẻ như bạn đang mô tả sự không phù hợp trở kháng quan hệ đối tượng .

Có một số điều được cho là để giải quyết công cụ ORB, công cụ ORM này, một loạt các công cụ truy cập dữ liệu.

Tôi nghĩ rằng thực tế là có rất nhiều giải pháp khiến tôi tin rằng One True Solution ™ không tồn tại.

Vì vậy, bạn có thể chọn bất kỳ hướng nào bạn thích an toàn trong kiến ​​thức mà một số người sẽ ghét nó và một số sẽ yêu thích nó.

Nếu bạn không muốn sử dụng trình bao bọc ORM, hãy sử dụng cơ sở dữ liệu hỗ trợ lưu trữ kiểu OOP như MongoDB .

MongoDB (từ "hu Mongo chúng ta") là một nền tảng tài liệu theo định hướng cơ sở dữ liệu hệ thống. Được phân loại là cơ sở dữ liệu " NoQuery ", MongoDB tránh cấu trúc cơ sở dữ liệu quan hệ dựa trên bảng truyền thống để ủng hộ các tài liệu giống như JSON với các lược đồ động (MongoDB gọi định dạng BSON ), giúp việc tích hợp dữ liệu trong một số loại ứng dụng dễ dàng và nhanh hơn. ..