Tôi nên chọn Doctrine 2 hay Propel 1.5 / 1.6, và tại sao? [đóng cửa]

Tôi muốn nghe từ những người đã sử dụng Học thuyết 2 (hoặc mới hơn) và Propel 1.5 (hoặc mới hơn). Hầu hết các so sánh giữa hai trình ánh xạ quan hệ đối tượng này đều dựa trên các phiên bản cũ - Học thuyết 1 so với Propel 1.3 / 1.4 và cả hai ORM đều trải qua các thiết kế lại đáng kể trong các phiên bản gần đây. Ví dụ, hầu hết những lời chỉ trích về Propel dường như tập trung vào các lớp "ModelName Peer ", không được chấp nhận trong 1,5 trong mọi trường hợp.

Đây là những gì tôi đã tích lũy được cho đến nay (Và tôi đã cố gắng làm cho danh sách này cân bằng nhất có thể ...):

• Tuyên truyền
  • Ưu
    • Cực kỳ thân thiện với IDE, bởi vì mã thực tế được tạo ra, thay vì dựa vào các phương thức ma thuật PHP. Điều này có nghĩa là các tính năng IDE như hoàn thành mã thực sự hữu ích.
    • Nhanh (Về mặt sử dụng cơ sở dữ liệu - không có nội quan thời gian chạy nào được thực hiện trên cơ sở dữ liệu)
    • Di chuyển sạch giữa các phiên bản lược đồ (ít nhất là trong bản 1.6 beta)
    • Có thể tạo các mô hình PHP 5.3 (tức là không gian tên)
    • Dễ dàng xâu chuỗi nhiều thứ vào một truy vấn cơ sở dữ liệu duy nhất với những thứ như useXxxphương thức. (Xem video "hoàn thành mã" ở trên)
  • Nhược điểm
    • Yêu cầu một bước xây dựng bổ sung, cụ thể là xây dựng các lớp mô hình.
    • Mã được tạo cần được xây dựng lại bất cứ khi nào phiên bản Propel được thay đổi, cài đặt được thay đổi hoặc lược đồ thay đổi. Điều này có thể không trực quan đối với một số và các phương thức tùy chỉnh áp dụng cho mô hình bị mất. (Tôi nghĩ sao?) - Không đúng; các phương thức tùy chỉnh không bị mất vì lớp được tạo là lớp cơ sở; Propel cung cấp một lớp thực thể đặc biệt để mở rộng.
    • Một số tính năng hữu ích (nghĩa là hành vi phiên bản, di chuyển lược đồ) đang ở trạng thái beta.
• Học thuyết
  • Ưu
    • Phổ biến hơn
    • Ngôn ngữ truy vấn của Doctrine có thể diễn tả các mối quan hệ phức tạp hơn giữa các dữ liệu dễ dàng hơn với chiến lược ActiveRecord của Propel.
    • Dễ dàng hơn để thêm các hành vi có thể sử dụng lại khi so sánh với Propel.
    • Nhận xét dựa trên DocBlock để xây dựng lược đồ được nhúng trong PHP thực tế thay vì một tệp XML riêng biệt.
    • Sử dụng không gian tên PHP 5.3 ở mọi nơi
  • Nhược điểm
    • Yêu cầu học một ngôn ngữ lập trình hoàn toàn mới (Ngôn ngữ truy vấn học thuyết)
    • Được triển khai dưới dạng "phương pháp ma thuật" ở một số nơi, làm cho IDE tự động hoàn thành không có giá trị.
    • Yêu cầu nội quan cơ sở dữ liệu và do đó chậm hơn một chút so với Propel theo mặc định; bộ nhớ đệm có thể loại bỏ điều này nhưng bộ nhớ đệm thêm phức tạp đáng kể.
    • Ít hành vi hơn được bao gồm trong cơ sở mã cơ sở. Một số tính năng mà Propel cung cấp ngoài hộp (chẳng hạn như Bộ lồng nhau) chỉ khả dụng thông qua các tiện ích mở rộng.
    • Freakin 'LỚN :)

Điều này tôi đã lượm lặt được mặc dù chỉ thông qua việc đọc tài liệu có sẵn cho cả hai công cụ - tôi chưa thực sự xây dựng bất cứ thứ gì.

Tôi muốn nghe từ những người đã sử dụng cả hai công cụ, để chia sẻ kinh nghiệm của họ về ưu / nhược điểm của mỗi thư viện và đề xuất của họ là gì vào thời điểm này :)

Bỏ xu hướng hiện tại để giới thiệu Học thuyết, tôi cần nói khác. Hãy nhớ rằng, sở thích cá nhân của tôi hướng đến trải nghiệm cá nhân của tôi, nhưng cách @Dan nói, cả hai đều rất mạnh mẽ.

Tôi không thích Học thuyết vì một số lý do bạn đã nêu trước đây, như kích thước và toàn bộ phương pháp ma thuật là điều phá vỡ thỏa thuận với tôi. Vì vậy, tôi sử dụng Propel , tại sao? chủ yếu là vì nó đơn giản và vì đơn giản trong phát triển phần mềm là tốt . Cá nhân tôi tin rằng việc tham lam với các thiết kế là xấu.

Sử dụng Propel, tôi đã quản lý để triển khai triển khai mẫu kho lưu trữ cho các hệ thống của riêng mình và nó hoạt động rất tốt, chưa kể đến hiệu suất của Propel, một trong những ORM nhanh nhất tôi từng thấy.

Vì vậy, câu trả lời cơ bản của tôi là Propel , vì nó hoàn thành phần mềm tốt với ít mã hơn và nó trao quyền cho IDE cung cấp cho bạn thông tin tốt mà không mất điểm phần mềm ORM đang kết nối với cơ sở dữ liệu và làm cho nó tốt ...

Hy vọng tôi có thể giúp

Thông tin của bạn về Học thuyết 2 là sai ...

• DQL là khá nhiều SQL, vì vậy không có nhiều để tìm hiểu.
• Học thuyết 2 không sử dụng bất kỳ 'phép thuật' nào (chỉ những gì bạn mong đợi trong bất kỳ thư viện PHP cập nhật nào).
• Doctrine 2 không chủ động thực hiện nội quan cơ sở dữ liệu ... ánh xạ được lưu trữ trong các tệp thực thể / ánh xạ của bạn và nó giả định rằng cơ sở dữ liệu của bạn sẽ phù hợp với điều đó.
• Bộ nhớ đệm hầu như không "phức tạp đáng kể".
• Học thuyết 2 không có 'hành vi' vượt trội

Tôi chưa từng sử dụng Propel trước đây, nhưng Doctrine 2 mới hơn nhiều và có một cơ sở mã chất lượng thực sự cao. Nhưng có vẻ như Propel sử dụng Active Record, Doctrine 2 sử dụng mẫu Data Mapper.

Nhược điểm của Doctrine 2 mới hơn là thiếu ví dụ của bên thứ ba, nhưng nó nhanh chóng được xây dựng.

Tôi đề nghị Học thuyết 2 ...

Từ ý kiến ​​của bạn, có vẻ như bạn đang cố gắng chọn Propel hoặc Doctrine để thay thế hoặc đáp ứng nhu cầu của bạn về ORM trong một ứng dụng cũ.

Điều đó đang được nói, tôi nghĩ rằng điều quan trọng là không đánh mất sự thật rằng việc chuyển sang một trong hai có thể là một cải tiến tuyệt vời cho ứng dụng của bạn. Vì vậy, không có câu trả lời sai thực sự.

Do đó, giải pháp bạn chọn phần lớn tùy thuộc vào sở thích của bạn dựa trên câu trả lời của bạn cho các câu hỏi sau:

1. Cái nào tích hợp tốt nhất vào giải pháp hiện tại của bạn?
2. API nào bạn thích?
3. Cái nào bạn muốn đóng góp cho? (bản vá, tài liệu, báo cáo lỗi, v.v ...)

Cá nhân, tôi muốn giới thiệu Học thuyết 2 vì đó là cộng đồng, tài liệu và kiến ​​trúc.

Tôi khuyên bạn nên sử dụng Propel vì nó được tích hợp tốt, nhanh và mạnh mẽ. Để tạo mã tốt hơn là tải các lớp trong thời gian chạy, nó giúp giảm bớt các bước gỡ lỗi và cho bạn thấy những gì bạn đã tạo. Vì vậy, bước xây dựng không phải là vấn đề.

Doctrine2 không có hành vi chính thức và mẫu thiết kế DataMapper rất tuyệt nhưng khó sử dụng trong cuộc sống thực. Oh và DQL là một nỗi đau, nhưng sắp xếp ngôn ngữ để học ...

Nếu bạn muốn suy nghĩ với các đối tượng (không có DQL / SQL / bất cứ điều gì), hãy chọn Propel.

Doctrine2 là một phần của Symfony2 de facto nhưng mọi thứ sẽ sớm chuyển sang, hãy xem bài viết cuối cùng của Fabien Potencier.

Chúc mừng, William

Cả hai đều rất tốt. Có một số trường hợp cạnh trong đó người ta có thể làm một cái gì đó, hoặc làm một cái gì đó tốt hơn, so với cái khác. Bất cứ nơi nào tôi gặp vấn đề với một trong hai, đó là do sự thiếu hiểu biết của tôi hơn là những điều họ không thể làm.

Điều này có nghĩa là tài liệu và hỗ trợ quan trọng hơn khả năng nội tại của mã. Bạn có biết ai có thể giúp bạn khi bạn gặp vấn đề không? Làm thế nào tốt để bạn nhận được với các tài liệu? Có ai trong số họ 'cảm thấy' tự nhiên hơn với yoU không?

Tôi đã chọn Propel 1.63 cho một ứng dụng mysql kế thừa lớn (200 bảng hoặc hơn) - các yếu tố ở đây bao gồm: Hỗ trợ IDE cho phép các nhà phát triển mới tìm đường dễ dàng khi hoàn thành mã; hỗ trợ lược đồ cơ sở dữ liệu chéo, hiệu suất; hỗ trợ bản địa tốt hơn cho enums và sử dụng một số hành vi. Trên thực tế, tôi đã bắt đầu với Doctrine vì đây là sự hỗ trợ tốt nhất của Symfony2 nhưng một khi Propel cải thiện đáng kể sự hỗ trợ của họ với Symfony (nền tảng tiếp theo tôi cuối cùng sẽ chuyển sang) tôi đã chuyển đổi do xử lý tốt hơn các vấn đề trên. Không hối tiếc chút nào Propel là một người chiến thắng quyết định.