Câu trả lời dài và muộn của tôi, thậm chí không đầy đủ, nhưng là một lời giải thích tốt TẠI SAO tôi ghét khuôn mẫu này, ý kiến và thậm chí một số cảm xúc:
1) phiên bản ngắn: Active Record tạo ra một " lớp mỏng " " ràng buộc chặt chẽ " giữa cơ sở dữ liệu và mã ứng dụng. Giải quyết không logic, không có vấn đề gì, không có vấn đề gì cả. IMHO nó không cung cấp BẤT KỲ GIÁ TRỊ NÀO, ngoại trừ một số đường cú pháp cho lập trình viên (sau đó có thể sử dụng "cú pháp đối tượng" để truy cập một số dữ liệu tồn tại trong cơ sở dữ liệu quan hệ). Nỗ lực tạo sự thoải mái cho các lập trình viên nên (IMHO ...) tốt hơn nên được đầu tư vào các công cụ truy cập cơ sở dữ liệu cấp thấp, ví dụ như một số biến thể của hash_map get_record( string id_value, string table_name, string id_column_name="id" )các phương pháp đơn giản, dễ dàng, đơn giản và tương tự (tất nhiên, các khái niệm và sự sang trọng khác nhau rất nhiều với ngôn ngữ sử dụng).
2) phiên bản dài: Trong bất kỳ dự án nào dựa trên cơ sở dữ liệu mà tôi có quyền "kiểm soát khái niệm" của mọi thứ, tôi đã tránh AR, và điều đó là tốt. Tôi thường xây dựng một kiến trúc phân lớp (sớm hay muộn bạn cũng chia phần mềm của mình thành các lớp, ít nhất là trong các dự án quy mô vừa đến lớn):
A1) bản thân cơ sở dữ liệu, bảng, quan hệ, thậm chí một số logic nếu DBMS cho phép nó (MySQL hiện cũng đã phát triển)
A2) rất thường xuyên, có nhiều hơn một kho lưu trữ dữ liệu: hệ thống tệp (các đốm màu trong cơ sở dữ liệu không phải lúc nào cũng là một quyết định tốt ...), các hệ thống kế thừa (hãy tự tưởng tượng "cách" chúng sẽ được truy cập, nhiều loại có thể .. nhưng đó là không phải là vấn đề ...)
B) lớp truy cập cơ sở dữ liệu (ở cấp độ này, các phương thức công cụ, người trợ giúp dễ dàng truy cập dữ liệu trong cơ sở dữ liệu rất được hoan nghênh, nhưng AR không cung cấp bất kỳ giá trị nào ở đây, ngoại trừ một số cú pháp)
C) lớp đối tượng ứng dụng: "đối tượng ứng dụng" đôi khi là các hàng đơn giản của bảng trong cơ sở dữ liệu, nhưng hầu hết chúng đều là các đối tượng phức hợp và có một số logic cao hơn được đính kèm, vì vậy đầu tư thời gian vào các đối tượng AR ở cấp độ này rõ ràng là vô ích , lãng phí thời gian quý báu của lập trình viên, bởi vì "giá trị thực", "logic cao hơn" của các đối tượng đó cần phải được thực hiện trên các đối tượng AR - dù có và không có AR! Và, ví dụ, tại sao bạn muốn có một phần trừu tượng của "Đối tượng mục nhập nhật ký"? Mã logic ứng dụng ghi chúng, nhưng liệu mã đó có khả năng cập nhật hoặc xóa chúng không? nghe có vẻ ngớ ngẩn và App::Log("I am a log message")một số cường độ có dễ sử dụng hơnle=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert();. Và ví dụ: sử dụng "Đối tượng nhập nhật ký" trong chế độ xem nhật ký trong ứng dụng của bạn sẽ hoạt động cho 100, 1000 hoặc thậm chí 10000 dòng nhật ký, nhưng sớm hay muộn bạn sẽ phải tối ưu hóa - và tôi cá là trong hầu hết các trường hợp, bạn sẽ chỉ sử dụng câu lệnh SQL SELECT nhỏ xinh đó trong logic ứng dụng của bạn (điều này hoàn toàn phá vỡ ý tưởng AR ..), thay vì gói câu lệnh nhỏ đó trong các khung ý tưởng AR cố định cứng nhắc với nhiều gói mã và ẩn nó. Thời gian bạn lãng phí với việc viết và / hoặc xây dựng mã AR có thể đã được đầu tư vào một giao diện thông minh hơn nhiều để đọc danh sách các mục nhập nhật ký (rất nhiều cách, bầu trời là giới hạn). Người lập trình nên dám phát minh ra các trừu tượng mới để nhận ra logic ứng dụng của họ phù hợp với ứng dụng dự định, và không triển khai lại các mẫu ngớ ngẩn một cách ngu ngốc, âm thanh tốt ngay từ cái nhìn đầu tiên!
D) logic ứng dụng - thực hiện logic của các đối tượng tương tác và tạo, xóa và liệt kê (!) Các đối tượng logic ứng dụng (KHÔNG, những tác vụ đó hiếm khi được neo trong chính các đối tượng logic ứng dụng: tờ giấy trên bàn của bạn cho biết tên và vị trí của tất cả các trang tính khác trong văn phòng của bạn? Hãy quên các phương pháp "tĩnh" để liệt kê các đối tượng, thật ngớ ngẩn, một sự thỏa hiệp tồi tệ được tạo ra để làm cho lối suy nghĩ của con người phù hợp với [một số-không-phải-tất-cả-AR-framework-like -] AR đang suy nghĩ)
E) giao diện người dùng - tốt, những gì tôi sẽ viết trong những dòng sau là rất rất, rất chủ quan, nhưng theo kinh nghiệm của tôi, các dự án được xây dựng trên AR thường bỏ qua phần giao diện người dùng của một ứng dụng - thời gian đã lãng phí vào việc tạo ra những điều trừu tượng khó hiểu . Cuối cùng, những ứng dụng như vậy đã lãng phí rất nhiều thời gian của người lập trình và cảm thấy giống như những ứng dụng từ người viết mã dành cho người lập trình, thiên về công nghệ bên trong và bên ngoài. Các lập trình viên cảm thấy tốt (công việc khó khăn cuối cùng đã hoàn thành, mọi thứ hoàn thành và chính xác, theo khái niệm trên giấy ...), và khách hàng "chỉ cần học rằng nó cần phải như vậy", bởi vì đó là "chuyên nghiệp" .. ok, xin lỗi, tôi lạc đề ;-)
Vâng, phải thừa nhận rằng tất cả điều này là chủ quan, nhưng đó là kinh nghiệm của tôi (loại trừ Ruby on Rails, nó có thể khác và tôi không có kinh nghiệm thực tế về cách tiếp cận đó).
Trong các dự án trả phí, tôi thường nghe thấy yêu cầu bắt đầu bằng việc tạo một số đối tượng "bản ghi hoạt động" như một khối xây dựng cho logic ứng dụng cấp cao hơn. Theo kinh nghiệm của tôi, điều này dễ thấy làlà một lý do nào đó để khách hàng (một công ty phát triển phần mềm trong hầu hết các trường hợp) không có một khái niệm tốt, một cái nhìn lớn, một cái nhìn tổng quan về sản phẩm cuối cùng nên là gì. Những khách hàng đó nghĩ theo khung cứng nhắc ("trong dự án mười năm trước nó hoạt động tốt .."), họ có thể làm thịt các thực thể, họ có thể xác định quan hệ thực thể, họ có thể phá vỡ quan hệ dữ liệu và xác định logic ứng dụng cơ bản, nhưng sau đó họ dừng lại và giao nó cho bạn, và nghĩ rằng đó là tất cả những gì bạn cần ... họ thường thiếu khái niệm đầy đủ về logic ứng dụng, giao diện người dùng, khả năng sử dụng, v.v. họ thiếu tầm nhìn rộng và họ thiếu tình yêu với và họ muốn bạn làm theo cách AR đó, bởi vì .. à, tại sao, nó hoạt động trong dự án đó nhiều năm trước, nó khiến mọi người bận rộn và im lặng? Tôi không biết. Nhưng "chi tiết" tách những người đàn ông khỏi những chàng trai, hoặc .. khẩu hiệu quảng cáo ban đầu như thế nào? ;-)
Sau nhiều năm (mười năm kinh nghiệm phát triển tích cực), bất cứ khi nào khách hàng đề cập đến "mẫu hồ sơ hoạt động", chuông báo thức của tôi đổ chuông. Tôi đã học được cách cố gắng đưa họ trở lại giai đoạn đặc biệt quan trọng đó , để họ suy nghĩ kỹ lưỡng, thử cho họ thấy những điểm yếu đặc biệt của họ hoặc chỉ tránh chúng nếu họ không quan tâm (cuối cùng, bạn biết đấy, một khách hàng chưa biết nó muốn gì, thậm chí có thể nghĩ nó biết nhưng không, hoặc cố gắng ngoại hóa công việc khái niệm cho TÔI một cách miễn phí, khiến tôi mất nhiều giờ, ngày, tuần và tháng quý giá trong thời gian của tôi, thời gian sống là quá ngắn ...).
Vì vậy, cuối cùng: TẤT CẢ ĐÂY là lý do tại sao tôi ghét "mô hình ghi hoạt động" ngớ ngẩn đó, và tôi đã và sẽ tránh nó bất cứ khi nào có thể.
CHỈNH SỬA : Tôi thậm chí sẽ gọi điều này là Không có khuôn mẫu. Nó không giải quyết bất kỳ vấn đề nào (các mẫu không có nghĩa là để tạo ra đường cú pháp). Nó tạo ra nhiều vấn đề: gốc rễ của tất cả các vấn đề của nó (được đề cập trong nhiều câu trả lời ở đây ..) là nó chỉ che giấu SQL cũ tốt được phát triển tốt và mạnh mẽ đằng sau một giao diện mà định nghĩa mẫu cực kỳ hạn chế.
Mô hình này thay thế sự linh hoạt bằng đường cú pháp!
Bạn thử nghĩ xem, AR giải quyết được vấn đề gì cho bạn?