PHP ORMs: Doctrine vs. Propel


126

Saya memulai proyek baru dengan symfony yang sudah terintegrasi dengan Doctrine dan Propel , tetapi saya tentu saja harus membuat pilihan .... Saya bertanya-tanya apakah orang yang lebih berpengalaman di luar sana memiliki pro dan / atau kontra umum untuk pergi bersama salah satu dari dua ini?

Terima kasih banyak.

Sunting: Terima kasih atas semua tanggapan, hal-hal yang bermanfaat. Tidak ada jawaban yang benar-benar benar untuk pertanyaan ini jadi saya hanya akan menandai sebagai menyetujui orang yang mendapat suara terbanyak yang populer.


5
Guys, apakah ada tanggapan yang diperbarui? Melihat hal ini ketinggalan zaman
Qiniso

Jawaban:


76

Saya akan pergi dengan Doktrin. Tampaknya bagi saya bahwa ini adalah proyek yang jauh lebih aktif dan menjadi ORM default untuk symfony itu lebih baik didukung (meskipun secara resmi ORM dianggap sama).

Selain itu saya lebih suka cara Anda bekerja dengan kueri (DQL daripada Kriteria):

<?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();
?>

(Implementasi Ajaran jauh lebih intuitif bagi saya).

Juga, saya benar-benar lebih suka cara Anda mengelola hubungan dalam Ajaran.

Saya pikir halaman ini dari dokumentasi Doctrine layak dibaca: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction:doctrine-explained

Singkatnya: Jika saya memulai proyek baru atau harus memilih antara mempelajari Ajaran dan Propel, saya akan pergi untuk Ajaran kapan saja.


42
Di Propel 1.5, kueri ini juga dapat ditulis sebagai Example_Query :: create () -> joinWith ('FooBar') -> filterId (20) -> find () (atau findPK (20) setelah joinWith jika Id adalah primer Anda kunci). Seperti yang Anda lihat, dibutuhkan sintaks yang bagus dari Doctrine, dan menambahkan sedikit lebih banyak. Rilis ini direncanakan untuk akhir Q1 2010, tetapi Anda dapat mengujinya sekarang di proyek Symfony Anda.
Jan Fabry

Masukan yang bagus, saya tidak tahu bahwa :-)
phidah

9
implementasi doktrin tampaknya jauh lebih rumit bagi saya. Get Entity manage get repository ... ini dan itu
SoWhat

1
doktrin lebih dari hal-hal rumit ... hanya notorm adalah cara untuk pergi
Geomorillo

40

Saya bias, karena saya sedikit membantu pada rilis Propel berikutnya, tetapi Anda harus mempertimbangkan bahwa Propel memang ORM pertama yang tersedia, kemudian sedikit tertinggal ketika Doctrine dibuat, tetapi sekarang memiliki pengembangan aktif lagi. Symfony 1.3 / 1.4 hadir dengan Propel 1.4, di mana sebagian besar perbandingan berhenti di Propel 1.3. Juga, rilis Propel berikutnya (1,5) akan berisi banyak perbaikan, terutama dalam pembuatan Kriteria Anda (menghasilkan lebih sedikit kode untuk Anda tulis).

Saya suka Propel karena tampaknya kurang kompleks daripada Doktrin: sebagian besar kode ada di beberapa kelas yang dihasilkan, sedangkan Doktrin telah membagi fungsi di banyak kelas. Saya suka memiliki pemahaman yang baik tentang perpustakaan yang saya gunakan (tidak terlalu banyak "sihir"), tetapi tentu saja, saya memiliki lebih banyak pengalaman dengan Propel, jadi mungkin Doktrin tidak begitu rumit di belakang layar. Beberapa mengatakan Propel lebih cepat, tetapi Anda harus memeriksanya sendiri, dan mempertimbangkan apakah ini melebihi perbedaan lain.

Mungkin Anda juga harus mempertimbangkan ketersediaan plugin Symfony untuk kerangka kerja yang berbeda. Saya percaya Propel memiliki kelebihan di sini, tetapi saya tidak tahu berapa banyak plugin yang terdaftar masih up-to-date dengan versi terbaru dari Symfony.


4
Peningkatan kueri baru di Propel 1.5 memang sangat bagus.
Tom

23

Itu datang ke preferensi pribadi. Saya menggunakan Propel karena (antara lain) Saya suka fakta bahwa semuanya memiliki metode pengambil & penyetel beton sendiri. Dalam Ajaran, ini tidak terjadi.

Mendorong:

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

Doktrin:

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

Alasan saya suka memiliki getter & setter adalah bahwa saya dapat menaruh semua jenis logika di dalamnya, jika saya perlu. Tapi itu hanya preferensi pribadi saya.

Saya juga harus menambahkan bahwa meskipun Propel bergerak lambat di masa lalu, sekarang Propel masih dalam pengembangan aktif lagi. Ini telah merilis beberapa versi baru dalam beberapa bulan terakhir. Versi Propel terbaru termasuk "antarmuka permintaan yang lancar" mirip dengan Doctrine , jadi Anda tidak perlu menggunakan Kriteria lagi jika Anda tidak mau.


7
di Doctrine Anda dapat mengganti setter dan getter untuk setiap properti dan juga memiliki logika khusus (lihat doctrine-project.org/documentation/manual/1_2/en/… - cari ATTR_AUTO_ACCESSOR_OVERRIDE untuk sampai ke bagian yang relevan)
Marek Karbarz

Itu terlihat ok, tetapi Anda masih menyetel properti dengan memanggil: $ x-> propname = 'abc'; Ini bermasalah karena tampaknya tidak mendukung melewati beberapa parameter.
lo_fye

20

Perlu dicatat Doctrine 2 saat ini sedang dalam pengembangan dirilis [ed] dan fungsinya hampir sepenuhnya berbeda dari versi stabil saat ini dari Doktrin 1. Ini bergantung pada pola Data Mapper alih-alih Rekaman Aktif, dan menggunakan 'manajer entitas' untuk menangani kegigihan. logika. Ketika dirilis akan lebih mirip dengan Hibernate Java (Doctrine 1 lebih seperti RailR 'ActiveRecord).

Saya telah mengembangkan dengan rilis alpha Doctrine 2, dan harus mengatakan itu adalah kepala dan bahu di atas Doctrine 1 (hanya pendapat saya, dan saya tidak pernah menggunakan Propel). Kemungkinannya bagus bahwa komunitas Doktrin akan bergerak ke arahnya ketika dirilis.

Saya akan mendorong Anda untuk memeriksa Doctrine, tetapi jika Anda lebih suka gaya Rekaman Aktif yang digunakan Propel dan Doctrine sekarang, Anda mungkin ingin tetap menggunakan Propel.


4
Versi stabil Doctrine 2 baru-baru ini dirilis. doctrine-project.org/blog/doctrine2-released
Trevor Allred

5

Kedua referensi tersebut agak ketinggalan jaman sehingga Anda tetap membahas beberapa generalisasi, pada dasarnya Anda harus mengevaluasi pengalaman Anda dengan kerangka kerja tersebut, kelemahan utama dari doktrin adalah ketidakmampuan untuk memiliki IDE yang memungkinkan Anda melakukan auto-code pada propel tersebut. seorang pemenang, kurva belajar dorongan dan doktrin sangat berbeda, lebih mudah untuk mendorong, jika proyek Anda akan perlu mengelola model data yang kompleks menggunakan doktrin, jika Anda ingin bekerja cepat dengan ORM yang didokumentasikan dengan baik dan temukan lebih banyak dukungan di Propel Penggunaan internet, jauh lebih matang dan saya percaya yang paling banyak digunakan.

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


Dalam dunia symfony, sepertinya Doktrin adalah yang paling banyak digunakan - terutama untuk proyek-proyek baru. Tentu saja ada banyak proyek sf 1.0 yang masih menggunakan Propel karena Doctrine tidak tersedia untuk symfony hingga 1.1.
phidah

5

Saya akan menyarankan untuk menggunakan propel 1.6 yang lebih baik untuk fungsi autocomplete IDE.


26
-1 Pelengkapan otomatis IDE seharusnya tidak menjadi alasan pilihan teknis
Clement Herreman

14
@ClementHerreman Saya setuju itu tidak harus dengan kriteria, tapi saya percaya seberapa produktif seseorang dapat menjadi dengan teknologi tertentu tentunya harus menjadi alasan untuk memilih itu. Dan dengan segala hormat saya tidak setuju dengan downvote Anda ... terlepas dari apakah Anda setuju dengan jawabannya, itu tidak "salah" (atau itu?), Dan itu berguna (kecuali itu salah, dalam hal ini , Anda harus menyatakan ini).
Sepster

2
IMO jika produktivitas Anda lebih ditingkatkan dengan pelengkapan otomatis alih-alih kualitas, intuitif, dan konsistensi perangkat lunak, maka sesuatu yang aneh sedang terjadi. Lihat codinghorror.com/blog/2009/01/… . Tetapi Anda benar, pada titik tertentu jawaban ini tidak salah , hanya saja tidak cukup baik, bahkan mungkin tidak baik.
Clement Herreman

1
@ClementHerreman, jika tidak membantu jangan menggunakannya lagi;), +1
amd

Apakah ada tanggapan terkini untuk ini? Ini sudah ketinggalan zaman.
Qiniso

2

Saya bukan pengguna PHP 5 non-framework ORM, tetapi berikut adalah beberapa postingan perbandingan yang bagus (jika Anda belum melihatnya):

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

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

Kedua konklusi favorit terhadap Doktrin sebagai generasi ORM baru untuk Symfony.


1
Sebagai catatan, perbandingan ini benar-benar ketinggalan jaman - versi Propel saat ini menggunakan PDO, menggunakan dukungan banyak-ke-banyak hubungan, dan memiliki dokumentasi yang bagus. Juga patut dipertimbangkan: sebagian dari kita lebih suka verbose kriteria-builder-gaya permintaan daripada bahasa permintaan eksklusif seperti DQL - itu memiliki dukungan IDE, dan itu adalah kelas, sehingga Anda dapat memperluasnya. Saya masih mencoba untuk memilih, tetapi saya melihat banyak nilai tambah untuk Propel di atas Doktrin, jika Anda tidak keberatan dengan pembuatan kode statis dan dapat melihat keuntungan dari kode PHP "nyata" sebagai lawan dari bahasa query yang dipatenkan , yang hanya berupa string ke IDE.
mindplay.dk

2

Setelah menggunakan keduanya selama beberapa tahun saya lebih suka Propel 2 daripada Doktrin hanya berdasarkan bagaimana Anda membangun logika kueri Anda. Doktrin adalah sedalam yang dapat diperoleh dan mengelola banyak aspeknya sesuai dengan tingkat kedalaman itu. Propel Saya merasa memiliki cara yang lebih fleksibel dan didorong objek untuk membangun dan mengelola interaksi kueri.

Bagi saya ini menyebabkan lebih sedikit kode dalam model dan lebih banyak struktur di sekitar bagaimana logika dapat / akan diproses. Ini menghasilkan hanya membangun banyak interaksi sebagai fungsi umum. (Setelah semua 90% dari apa yang akan Anda lakukan dengan database hanya akan menjadi beberapa tingkat operasi kasar.)

Pada akhirnya, keduanya kuat, dapat dikelola dan akan menyelesaikan pekerjaan. Proyek pribadi saya dan minat saya menggunakan Propel ORM 2 dan proyek masa depan, jika masih ditulis dalam PHP akan pergi rute itu.

Saya telah menggunakan keduanya setiap hari selama 3-4 tahun terakhir.


1

Saya sarankan menggunakan DbFinder Plugin . Ini sebenarnya adalah plugin yang sangat kuat yang mendukung keduanya, dan cukup bagus. Saya sebenarnya suka menggunakannya lebih baik daripada keduanya.


@ Mike: terima kasih, tidak tahu tentang plugin tetapi tampaknya hanya mendukung hingga Sf1.2. Saya akhirnya pergi dengan Doktrin pada akhirnya, rasanya itu adalah pilihan yang tepat, meskipun menulis SQL langsung diperlukan untuk hal-hal yang lebih kompleks.
Tom

-2

Jika saya tidak salah, kedua ORM menggunakan skema berbasis XML, dan membuat definisi skema ini cukup rumit. Jika Anda memerlukan skema sederhana berbasis PHP dengan gaya fasih. Anda dapat mencoba LazyRecord https://github.com/c9s/LazyRecord ini mendukung migrasi otomatis dan meningkatkan / menurunkan generator skrip. Dan semua file kelas dihasilkan secara statis tanpa biaya runtime.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.