I like the active record pattern for it's ease of use but I find for large projects there is the potential for models to become large and messy. I prefer plain old php objects that are persistence ignorant. Is there any momentum or plans to implement ORM using a data mapper approach? What are the considerations/problems of such an approach?
I'm also like persistance ignorant object. For my project I wrote Simple implementation of doctrine1 and doctrine2 approach with Entities and Repositories.
Repository have access to persistance layer (for example DB) and Cache layer Entity is your Model (every Entity for example Entity\User extends Entity\Base\User - autogenerated base on repository configuration.) There is a lot of work to do to make this full ORM but main reason to make unit tests simple and fast.
Of course this approach still make some entity very huge and for this I wrote entity services (for exmaple Service\UserService).
I am actually in the process of writing a zephir mashup of the phalcon db/model code with Spot
https://github.com/vlucas/Spot https://github.com/brandonlamb/Spot
Spot is a great PHP datamapper, I have used it and really like for its simplicity and lack of bloat. I ended up forking and adding a bunch. I came across this after using Idiorm/Paris which lead to a custom rewrite of those libraries and finally discovered the data mapper pattern (I totally favor over active record).
By forking Spot, I re-tooled a lot, added a db2 adapter, added join support and whatnot for query builder.
Now I am taking phalcons zephir db code as a base, stripping out stuff like migration (just my opinion this is bloat) and mashing in Spot's code and converting to more datamapper pattern.
I just started a new repository this weekend, didnt get too far along yet. my vision is to have a very minimalist codebase, so nothing like createTable, addIndex or any of that schema/table/index manipulation. Really just get it down to a datamapper for CRUD operations.