Implement Data Mapper pattern instead of Active Record

[bwhitty]

Opening this issue to discuss how the Model layer is going to be implemented.

I propose we implement the Data Mapper [1] pattern instead of the currently planned Active Record pattern. I say this because that while the Active Record pattern may be easy at first and faster to implement, it violates the single responsibility principle in that it concerns itself with both domain logic and persistence [2]. Also as Titon is a framework, it needs to be as flexible as possible so decoupling is key.

To go along with the Data Mapper pattern, there is also usually a service layer. All this service layer does is marry domain objects to their data mappers and are the end-user interface. You would then use a service in, say, the controller layer [3].

This whole pattern adds extra complexity through layers of abstraction, but it is much more extensible and testable. Thoughts?

1: http://martinfowler.com/eaaCatalog/dataMapper.html 2: http://russellscottwalker.blogspot.com/2013/10/active-record-vs-data-mapper.html 3: http://www.slideshare.net/aaronsaray/enterprise-php-mappers-models-and-services

[milesj]

This is definitely something I've been thinking about and it will most likely be the case. However, for ease of convenience, I was also planning on adding active record as well, for individuals who prefer that style of coding.

[Arilas]

I've also prefer Data Mapper. It's more powerful in future, but needs some sort of additional functionality:

1. UnitOfWork - which contains origins of data, that received from DB
2. Proxies - for just-in-time relation between models (entities)
3. SchemaTool - for database generation based on Annotations and/or Attributes and Hack Types (there's problem with date/time/datetime formats, and also text/varchar/char, etc)

And some other things.