Các ORM của PHP: Học thuyết so với Propel


126

Tôi đang bắt đầu một dự án mới với symfony được tích hợp sẵn với DoctrinePropel , nhưng tất nhiên tôi cần phải đưa ra lựa chọn .... Tôi tự hỏi liệu những người có kinh nghiệm hơn ở ngoài đó có những ưu và nhược điểm chung để đi với một trong hai

Cảm ơn rất nhiều.

EDIT: Cảm ơn tất cả các câu trả lời, công cụ hữu ích. Không có câu trả lời thực sự chính xác cho câu hỏi này vì vậy tôi sẽ chỉ đánh dấu là đã được phê duyệt câu trả lời phổ biến nhất.


5
Các bạn, có bất kỳ phản hồi cập nhật? Thấy rằng cách này đã lỗi thời
Qiniso

Câu trả lời:


76

Tôi sẽ đi với Học thuyết. Dường như với tôi rằng đó là một dự án tích cực hơn nhiều và là ORM mặc định cho symfony, nó được hỗ trợ tốt hơn (mặc dù chính thức các ORM được coi là bằng nhau).

Hơn nữa, tôi thích cách bạn làm việc với các truy vấn (DQL thay vì Tiêu chí):

<?php
// Propel
$c = new Criteria();
$c->add(ExamplePeer::ID, 20);
$items = ExamplePeer::doSelectJoinFoobar($c);

// Doctrine
$items = Doctrine_Query::create()
       ->from('Example e')
       ->leftJoin('e.Foobar')
       ->where('e.id = ?', 20)
       ->execute();
?>

(Việc thực hiện học thuyết đối với tôi trực quan hơn nhiều).

Ngoài ra, tôi thực sự thích cách bạn quản lý các mối quan hệ trong Học thuyết.

Tôi nghĩ rằng trang này từ tài liệu của Học thuyết đáng để đọc: http://www.doctrine-project.org/documentation/manual/1_2/en/int sinhtion : doctrine-expained

Tóm lại: Nếu tôi đang bắt đầu một dự án mới hoặc phải lựa chọn giữa việc học tập Học thuyết và Tuyên truyền, tôi sẽ đi đến Học thuyết bất cứ ngày nào.


42
Trong Propel 1.5, truy vấn này cũng có thể được viết dưới dạng example_Query :: create () -> tham giaWith ('FooBar') -> filterId (20) -> find () (hoặc findPK (20) sau khi tham gia Chìa khóa). Như bạn có thể thấy, nó lấy cú pháp hay từ Doctrine và thêm một chút nữa. Việc phát hành được lên kế hoạch vào cuối Q1 2010, nhưng bạn có thể kiểm tra nó ngay bây giờ trong các dự án Symfony của bạn.
Jan Fabry

Đầu vào tuyệt vời, tôi không biết rằng :-)
phidah

9
thực hiện giáo lý có vẻ phức tạp hơn nhiều đối với tôi. Nhận Entity quản lý get kho ... này và rằng
SoWhat

1
học thuyết đã làm phức tạp mọi thứ ... chỉ cần không phải là hướng đi
Geomorillo

40

Tôi thiên vị, vì tôi giúp một chút trong lần phát hành tiếp theo của Propel, nhưng bạn phải xem rằng Propel thực sự là ORM đầu tiên có sẵn, sau đó bị trễ một chút khi Doctrine được tạo, nhưng bây giờ đã phát triển lại. Symfony 1.3 / 1.4 đi kèm với Propel 1.4, trong đó hầu hết các so sánh dừng lại ở Propel 1.3. Ngoài ra, bản phát hành tiếp theo của Propel (1.5) sẽ chứa rất nhiều cải tiến, đặc biệt là trong việc tạo ra Tiêu chí của bạn (dẫn đến ít mã hơn để bạn viết).

Tôi thích Propel vì nó có vẻ ít phức tạp hơn Doctrine: hầu hết mã nằm trong một vài lớp được tạo, trong khi Doctrine đã phân chia chức năng trong rất nhiều lớp. Tôi muốn hiểu rõ về các thư viện tôi đang sử dụng (không quá nhiều "ma thuật"), nhưng tất nhiên, tôi có nhiều kinh nghiệm hơn với Propel, vì vậy có lẽ Doctrine không quá phức tạp trong hậu trường. Một số người nói Propel nhanh hơn, nhưng bạn nên tự kiểm tra điều này và xem xét liệu điều này có vượt trội hơn những khác biệt khác không.

Có lẽ bạn cũng nên xem xét tính khả dụng của các plugin Symfony cho các khung khác nhau. Tôi tin rằng Propel có một lợi thế ở đây, nhưng tôi không biết có bao nhiêu plugin được liệt kê vẫn cập nhật với phiên bản mới nhất của Symfony.


4
Các cải tiến truy vấn mới trong Propel 1.5 thực sự rất tốt.
Tom

23

Nó là về sở thích cá nhân. Tôi sử dụng Propel bởi vì (trong số những thứ khác) Tôi thích thực tế là mọi thứ đều có phương thức getter & setter cụ thể của riêng nó. Trong học thuyết, đây không phải là trường hợp.

Tuyên truyền:

$person->setName('Derek');
echo $person->getName();

Học thuyết:

$person->name = 'Derek';
echo $person->name;

Lý do tôi thích có getters & setters là tôi có thể đặt tất cả các loại logic trong chúng, nếu tôi cần. Nhưng đó chỉ là sở thích cá nhân của tôi.

Tôi cũng nên nói thêm rằng mặc dù trước đây Propel đã di chuyển chậm, nhưng hiện tại nó đang được phát triển tích cực trở lại. Nó đã phát hành một số phiên bản mới trong vài tháng qua. Phiên bản gần đây nhất của Propel bao gồm "giao diện truy vấn lưu loát" tương tự như của Doctrine , vì vậy bạn không phải sử dụng Tiêu chí nữa nếu bạn không muốn.


7
trong Học thuyết bạn có thể ghi đè lên setters và thu khí cho mỗi tài sản và cũng có logic tùy chỉnh (xem doctrine-project.org/documentation/manual/1_2/en/... - tìm kiếm ATTR_AUTO_ACCESSOR_OVERRIDE để đến phần có liên quan)
Marek Karbarz

Điều đó có vẻ ổn, nhưng bạn vẫn đặt thuộc tính bằng cách gọi: $ x-> propname = 'abc'; Đây là vấn đề vì nó không xuất hiện để hỗ trợ truyền nhiều tham số.
lo_fye

20

Cần lưu ý thuyết 2hiện tại phát triển phát hành [ed] và chức năng gần như hoàn toàn khác biệt so với phiên bản ổn định hiện hành của Học thuyết 1. Nó dựa trên mô hình dữ liệu Mapper thay vì Active Record, và sử dụng một 'quản lý thực thể' để xử lý kiên trì Hợp lý. Khi được phát hành, nó sẽ có sự tương đồng gần hơn với Hibernate của Java (Doctrine 1 giống với ActiveRecord của Rails).

Tôi đã phát triển với phiên bản alpha của Học thuyết 2, và phải nói rằng đó là đầu và vai trên Học thuyết 1 (chỉ là ý kiến ​​của tôi và tôi chưa bao giờ sử dụng Propel). Rất có thể cộng đồng Học thuyết sẽ hướng tới nó khi nó được phát hành.

Tôi sẽ khuyến khích bạn kiểm tra Doctrine, nhưng nếu bạn thích kiểu Active Record mà Propel và Doctrine sử dụng bây giờ, bạn có thể muốn sử dụng Propel.


4
Một phiên bản ổn định của Doctrine 2 đã được phát hành gần đây. doctrine-project.org/blog/doctrine2- phát hành
Trevor Allred

5

Hai tài liệu tham khảo có phần lỗi thời, tuy nhiên bạn vẫn đề cập đến một số điểm chung, về cơ bản, bạn phải đánh giá trải nghiệm của mình với khung như vậy, một nhược điểm lớn đối với học thuyết là không thể có IDE cho phép bạn tự động viết mã trong đó. một người chiến thắng, học đường cong propel và học thuyết rất khác nhau, việc đẩy mạnh sẽ dễ dàng hơn, nếu dự án của bạn sẽ cần quản lý mô hình dữ liệu phức tạp sử dụng học thuyết, nếu bạn muốn làm việc nhanh chóng với ORM, tài liệu tốt nhất và tìm thêm hỗ trợ trong Propel Sử dụng Internet, trưởng thành hơn nhiều và tôi tin rằng được sử dụng nhiều nhất.

http://propel.posterous.com/propel-141-is-out


Trong thế giới symfony, dường như Doctrine được sử dụng nhiều nhất - đặc biệt là cho các dự án mới hơn. Tất nhiên có rất nhiều dự án sf 1.0 vẫn sử dụng Propel vì Doctrine không có sẵn cho symfony cho đến 1.1.
phidah

5

Tôi khuyên bạn nên sử dụng propel 1.6, tốt hơn cho chức năng tự động hoàn thành của IDE.


26
-1 Tự động hoàn thành một IDE không phải là lý do của sự lựa chọn kỹ thuật
Clement Herreman

14
@ClementHerreman Tôi đồng ý nó không phải là các tiêu chí này, nhưng tôi tin rằng cách hiệu quả người ta có thể được với một công nghệ cụ thể chắc chắn nên một lý do cho việc lựa chọn nó. Và với sự tôn trọng hoàn toàn, do đó tôi không đồng ý với downvote của bạn ... bất kể bạn có đồng ý với câu trả lời hay không, nó không "sai" (hoặc là nó?), Và nó được sử dụng (trừ khi nó sai, trong trường hợp đó là sai , bạn nên nói rõ điều này).
Sepster

2
IMO nếu năng suất của bạn được cải thiện nhiều hơn bằng cách tự động hoàn thành thay vì chất lượng phần mềm, trực giác và tính nhất quán, thì điều gì đó kỳ lạ đang xảy ra. Xem mã hóa kinh dị.com / blog / 2009/01 / . Nhưng bạn đã đúng, đến một lúc nào đó câu trả lời này không sai , chỉ là không đủ tốt, thậm chí có thể không tốt.
Clement Herreman

1
@ClementHerreman, nếu không muốn nói là hữu ích không sử dụng nó nữa;), 1
amd

Có bất kỳ phản hồi cập nhật cho điều này? Đây là cách hết hạn.
Qiniso

2

Tôi không phải là người dùng ORM không có khung PHP 5, nhưng đây là một số bài viết so sánh tốt (trong trường hợp bạn chưa thấy chúng):

http://codeutopia.net/blog/2009/05/16/doctrine-vs-propel-2009-update/

http://trac.symfony-project.org/wiki/ComparedPropelAndDoctrine

Cả hai đều được yêu thích đối với Doctrine như là một thế hệ ORM mới hơn cho Symfony.


1
Đối với hồ sơ, sự so sánh này hoàn toàn lỗi thời - phiên bản hiện tại của Propel sử dụng PDO, không sử dụng hỗ trợ các mối quan hệ nhiều-nhiều và có tài liệu tuyệt vời. Cũng đáng xem xét: một số người trong chúng tôi thích kiểu truy vấn của trình xây dựng tiêu chí dài hơn các ngôn ngữ truy vấn độc quyền như DQL - nó có hỗ trợ IDE và đó là một lớp, vì vậy bạn có thể mở rộng nó. Tôi vẫn đang cố gắng chọn, nhưng tôi thấy rất nhiều điểm cộng cho Propel over Doctrine, nếu bạn không quan tâm đến việc tạo mã tĩnh và có thể thấy những lợi thế của mã PHP "thực" so với ngôn ngữ truy vấn độc quyền , đó chỉ là chuỗi cho một IDE.
mindplay.dk

2

Sau khi sử dụng cả hai trong một số năm, tôi thích Propel 2 hơn Doctrine chỉ đơn giản dựa trên cách bạn xây dựng logic truy vấn của mình. Học thuyết có chiều sâu như nó có thể có được và quản lý nhiều khía cạnh của nó phù hợp với mức độ sâu sắc đó. Propel Tôi cảm thấy có một cách linh hoạt và hướng đối tượng hơn trong việc xây dựng và quản lý các tương tác truy vấn.

Đối với tôi điều này dẫn đến ít mã hơn trong mô hình và nhiều cấu trúc hơn xung quanh cách logic có thể / sẽ được xử lý. Điều này dẫn đến việc xây dựng nhiều tương tác là chức năng phổ biến. (Sau tất cả 90% những gì bạn sẽ làm với cơ sở dữ liệu sẽ chỉ là một mức độ hoạt động thô sơ.)

Cuối cùng, cả hai đều mạnh mẽ, có thể quản lý và sẽ hoàn thành công việc. Các dự án cá nhân và sở thích của tôi sử dụng Propel ORM 2 và các dự án trong tương lai, nếu vẫn được viết bằng PHP sẽ đi theo con đường đó.

Tôi đã sử dụng cả hai trên cơ sở hàng ngày trong 3-4 năm qua.


1

Tôi khuyên bạn nên sử dụng Plugin Db Downloader . Đây thực sự là một plugin rất mạnh mẽ hỗ trợ cả hai, và khá mạnh mẽ. Tôi thực sự thích sử dụng nó tốt hơn một trong hai.


@Mike: cảm ơn, không biết về plugin nhưng dường như nó chỉ hỗ trợ tối đa Sf1.2. Cuối cùng tôi đã đi với Doctrine, cảm thấy như đó là lựa chọn đúng đắn, mặc dù viết SQL trực tiếp là cần thiết cho những thứ phức tạp hơn.
Tom

-2

Nếu tôi không sai, cả hai ORM đều sử dụng lược đồ dựa trên XML và việc tạo các định nghĩa lược đồ này khá cồng kềnh. Nếu bạn cần một lược đồ đơn giản dựa trên PHP với phong cách trôi chảy. Bạn có thể dùng thử LazyRecord https://github.com/c9s/LazyRecord, nó hỗ trợ di chuyển tự động và nâng cấp / hạ cấp trình tạo tập lệnh. Và tất cả các tệp lớp được tạo tĩnh mà không có chi phí thời gian chạy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.