Ưu điểm của việc sử dụng Doctrine cho PHP?

Question

Chỉ cần đi qua các dự án Doctrine có một quan hệ đối tượng Mapper và một lớp trừu tượng DB. Doctrine cung cấp những lớp trừu tượng PHP nào khác không? Và việc sử dụng thực tế nào bạn có thể đặt ORM, ngoài việc tìm nạp các đối tượng thông qua các truy vấn được viết bằng ngôn ngữ truy vấn Doctrine? Ngôn ngữ truy vấn có thực sự là thứ bạn muốn phát triển toàn bộ ứng dụng web không? Nó có hoạt động tốt không?

Nói chung, việc xây dựng một ứng dụng trên Doctrine giúp việc duy trì và hiểu dễ dàng hơn? Nó có được thiết kế quá mức và đang xây dựng trên một lớp trừu tượng hợp lý cho các dự án có quy mô vừa và nhỏ không? (< 50 màn hình GUI), trái ngược với trực tiếp làm việc với MySQL.

Answer 1

Doctrine cung cấp các lớp trừu tượng PHP nào khác không?

1. Thực hiện mẫu DataMapper thay vì ActiveRecord.
2. Hỗ trợ annotations, XML và YAML cho lược đồ.
3. Sử dụng DQL.
4. Sử dụng lợi ích của PHP 5.3+.
5. Nhanh và có cộng đồng lớn.
6. Ngoại trừ ORM có ODM.

Ngôn ngữ truy vấn có thực sự muốn phát triển toàn bộ ứng dụng web không?

Chỉ là một phần của ứng dụng chịu trách nhiệm duy trì các đối tượng kinh doanh nên biết về sự tồn tại của Doctrine. Và phần đó không phải là 100% dựa trên Doctrine.

Nói chung, việc xây dựng ứng dụng trên Doctrine giúp dễ dàng duy trì và hiểu hơn?

Chắc chắn. Mã dễ đọc, dễ hiểu và dễ bảo trì hơn.

Được thiết kế quá mức và có hợp lý cho các dự án có quy mô vừa và nhỏ không?

Thực ra Doctrine khá đơn giản về nguyên tắc cơ bản của nó. Và đó là một lựa chọn rất tốt cho các ứng dụng nhỏ, trung bình và thậm chí một số ứng dụng lớn.

---

Học thuyết không phải là câu trả lời cho mọi thứ và đôi khi có chút rắc rối. Tuy nhiên đối với các nhiệm vụ điển hình, nó cực kỳ hữu ích. IMHO ORM/ODM tốt nhất cho PHP tại thời điểm này.

Answer 2

Tôi muốn thêm một vài điểm vào câu trả lời của Crozin, nhưng rất tiếc là không thể nhận xét. Dưới đây là:

• Học thuyết không sử dụng các phương pháp ma thuật __get() và __set() để truy cập thuộc tính thực thể, tất cả thuộc tính thực thể phải có trình lấy/lấy. Điều này cải thiện hoàn thành mã IDE và bạn không cần phải nhìn vào cấu trúc bảng DB tất cả các thời gian.
• Học thuyết hoàn toàn tóm tắt bạn từ các tên trường bảng thực. Khi bạn ánh xạ các thuộc tính thực thể cho các trường DB - bạn sử dụng các tên thuộc tính ở khắp mọi nơi. Tương tự cho tên bảng.
• Học thuyết sử dụng mẫu kho lưu trữ ẩn các chi tiết về việc nhận thực thể.
• Học thuyết sử dụng phương pháp "mã đầu tiên", vì vậy bạn có thể tạo các thực thể trước và sau đó tạo cơ sở dữ liệu cho chúng một cách tự động. Trường hợp ngược lại cũng có thể.
• Học thuyết có trình tạo truy vấn mạnh mẽ, vì vậy bạn có thể sử dụng mẫu trình tạo cho các truy vấn có các phần có điều kiện.
• Học thuyết sử dụng khóa và ràng buộc nước ngoài để thực hiện các hành động xếp tầng và giữ cho dữ liệu nhất quán.
• UnitOfWork thuyết là một điều khá tuyệt vời và thông minh, không có tương tự trong ORMs php khác

IMHO tại học thuyết thời điểm cung cấp hỗ trợ hoàn thành mã IDE tốt nhất và DB lớp trừu tượng giữa tất cả ORMs php sẵn. Nó không được thiết kế quá mức và tuân theo các nguyên tắc SOLID.

Answer 3

Tôi muốn thêm điểm vào câu trả lời của GerKirill. Sự vắng mặt của hỗ trợ cho các phương pháp getter/setter ma thuật là một điểm yếu, IMHO, không phải là một sức mạnh. Nếu bạn đã từng cuộn qua hàng tá trang của các getters/setters giống nhau, bạn sẽ nhận ra rằng các phương thức này là một sự lãng phí rất lớn của không gian (chưa kể đến thời gian biên dịch). Không ai vô tình thiết lập một biến đối tượng, và một setter không ngăn cản bạn làm điều đó ... khi bạn muốn thay đổi thuộc tính, bạn chỉ cần gọi setter (làm thế nào để một setter "bảo vệ" thuộc tính - nếu bạn sẽ thực hiện một lỗi đánh máy và trực tiếp đặt giá trị thuộc tính sai, bạn sẽ thực hiện cùng một lỗi đánh máy và gọi sai setter). Và nó là rất hiếm hoi cho một setter hoặc getter để làm bất cứ điều gì khác hơn là có được hoặc thiết lập một tài sản. Nếu bạn phải làm một cái gì đó đặc biệt để thiết lập hoặc lấy một thuộc tính, thuộc tính đó phải là một phương thức (xem http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html), hoặc bạn nên tái cấu trúc mã của bạn, hoặc bạn nên gọi hàm xác nhận thuộc tính (thường là tại thời điểm đối tượng tạo). Đây là một trong những trường hợp trốn học không có thách thức gây tai họa cho thế giới OO. Hãy suy nghĩ về nó trước khi bạn đăng trả lời nhận được sự khôn ngoan tiêu chuẩn.