11

I'm about to start developing a new web application in CodeIgniter. In the past, I have used DataMapper ORM for my object mapping needs and have been completely satisfied with it's capabilities. However, my satisfaction only goes as far as my knowledge. Hence, I am considering switching to Doctrine.

I looked into Doctrine's documentation - it appears you have to define your models quite extensively; add getters and setters, provide direction references, provide mapping, etc. At first glance, this appears as tremendous overhead in direct comparison to DataMapper ORM.

Can anybody with experience with both ORMs comment on what drove you from one to the other?

What critical functionality does Doctrine acheive that DataMapper ORM cannot?

Is the manual model definition a step backwards or forwards? I presume it's a performance thing.

tereško
  • 58,060
  • 25
  • 98
  • 150
Jordan Arsenault
  • 7,100
  • 8
  • 53
  • 96

1 Answers1

22

DataMapper ORM and Doctrine follow a completely different set of conventions. The DataMapper ORM is (confusingly enough) not a data mapper but an active record implementation. That means that your model classes are tightly integrated with the ORM library. Your models build on the built-in DataMapper models. You get a lot of magic for free but in exchange you marry your models to the DataMapper ORM.

Doctrine on the other hand uses a true data mapper pattern. It's models are plain old PHP objects. They have no external dependencies. Doctrine can take any old PHP object, store it in a database and later retrieve it again. It's models are not coupled with the ORM at all.

The things you read about in the Doctrine documentation about getters, setters, relational integrity, etcetera, they are just good OO development practices. They are not a requirement for Doctrine but they make your life easier. You should be using them for your DataMapper ORM models too! If you want, you could use magic getters and setters or even just plain old public properties on your Doctrine models. Just because Doctrine says that you shouldn't do it does not mean that you cannot do it. Doctrine will happily use your models with public properties, but there are some caveats. That's all.

Sander Marechal
  • 22,978
  • 13
  • 65
  • 96
  • Sander, you seem really knowledgeable on this topic so maybe you can help me out. When you say "[doctrine's] models are plain old PHP objects", do you mean the 'entitites'? How do you gel the concept of 'entities' with CI models? Are they a replacement? Right now I have my model-ish functions (like "getRecentPosts()") in Doctrine entity repositories. Is this a good path to follow? – MikeMurko Oct 19 '11 at 16:35
  • 1
    Yes, I meant the entities. CI (I assume you mean Codeigniter) doesn't have that. It's models are coupled with the rest of CI. But you can [use Doctrine2 with Codeigniter](http://wildlyinaccurate.com/integrating-doctrine-2-with-codeigniter-2/). And yes, `getRecentPosts()` is exactly the kind of function that you want to put in the repository. – Sander Marechal Oct 20 '11 at 06:36