Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Preference Doctrine or Propel?
  • I've been looking at the docs for both Doctrine and Propel. It seems as though Doctrine is the more popular of the two. Can someone give me their own perspective on the pros and cons or both? I am actually leaning towards Propel. Thanks,
  • It's a difference in approach. Propel is an ActiveRecord implementation while Doctrine2 is based on DataMapper. ActiveRecord: 1 record in the database equals 1 object in PHP. It's easily recognizable because almost always it will have all it's data manipulation methods on the model instances that also model the data from the database. Thus syntax like Model_Example::find(1) or $example->save() DataMapper: makes a division between the logic that is specific to storage engine and the logic that is specific to the data you're working with. This means a bit more abstraction. It is most often recognized by having 'Entity' classes that model the data and other classes that contain the logic for storing that data. My personal preference is the DataMapper pattern as it is a lot clainer, and thus I prefer Doctrine.
  • Yes, I believe i understand what you're saying. With Propel, I don't think it would be able to insert and update multiple tables based on relationship. Is this the basic concept you're trying to relay? And the abstraction of using a different database and driver?
  • That is not related to the design pattern being used by the ORM, those are implementation features, ORM's based on both patterns can do that. Read http://msdn.microsoft.com/en-us/magazine/dd569757.aspx to get an idea of the concepts behind both patterns. From the outside, the main difference is that: - Active record uses a single object to hold both logic and data. Data is therefore closely tied to the logic provided (i.e. database access). - Datamapper uses separate objects for data (entity objects), data related logic and ORM logic. You therefore have methods that operate on the data, and methods that interact with the data (the traditional ORM methods like save). So the datamapper pattern provides more abstraction, and separation of concerns. It would for example be a lot easier to swap the ORM database logic with ORM rest api logic, the data objects would be blisfully unaware of that.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion