Table data gateway
Posted: Fri Oct 29, 2010 11:34 am
EDIT | This is really just a brain dump of what is on my mind right now. if it's toally incoherent I apologize in advance 
A while back I implemented a simple, generic (no frills) table data gateway. Basic CRUD-S methods thats it's
My implementation will act only on a single table at a time, no JOIN's are possible, this was by choice. While this works great for in 95% of situations, there are some occassions where I wish I had something more like a data mapper, especially when working with the crud methods, a load()/save() usage would be slightly more readable I think.
I am thinking, I could probably implement something of a row data gateway using the TDG, by encapsulating the CRUD methods and providing a load()/save() interface, in addition to possibly providing mutable properties as part of the RDG - something the TDG does not do provide it's strictly a function based interface.
At which point does a RDG implementation become a data mapper, because of most examples I have seen a data mapper is essentially that, with possibly finder() methods added to the mix, which the underlying TDG would facilitate much more effectively (at least in my vision of what I want achieved). ActiveRecord has been said many times, to simply be a RDG with business logic. So if you inherited from a RDG and implemented business logic you effectively have achieved ActiveRecord.
One draw back to using a simple TDG class as I have built, is the responsibility of programmatically tying togather tables as opposed to using JOIN's. For instance I have a workorder table, with a few ID's - customer, user, etc. Before I return that result to the caller, I must iterate the recordset, and map the details from the customer, user, etc to the array. Not a great deal of work, but a full fledged ORM would assumingly handle this for me.
Eventually I would like to implement a lightweight ORM, if for no other reason than to accomodate this feature.
I am not sure how I envision everything to unfold so I'm just asking for opinions, for the time being lets say:
1. I see the TDG being the lowest level and providing a base for all other operations
2. I see RDG being used to provide/dictate the schema of an individual record
3. Data mapper using both TDG and RDG to meet the requirements of users who prefer data mapper
4. Some kind of ORM that handles the mismtach between object and table(s)
The latter I can see possibly being implemented by using recordset meta information stored in RDG and conventions. When a table is queried, the columns are checked and foriegn key relations are determined based on convention, for instance id_customer would cause a 1:1 mapping of workorder to customer, so querying the workorder model would automatically include the customer details as well.
Obviously 1:1 and 1:n and n:m would need to be made more obvious in the meta data, and I am not very confident this information belongs in a RDG
Anyways, I have lost my chain of thought for the time being, interested in hearing others opinions on their experience implementing any of the patterns mentioned above.
Cheers,
Alex
A while back I implemented a simple, generic (no frills) table data gateway. Basic CRUD-S methods thats it's
My implementation will act only on a single table at a time, no JOIN's are possible, this was by choice. While this works great for in 95% of situations, there are some occassions where I wish I had something more like a data mapper, especially when working with the crud methods, a load()/save() usage would be slightly more readable I think.
I am thinking, I could probably implement something of a row data gateway using the TDG, by encapsulating the CRUD methods and providing a load()/save() interface, in addition to possibly providing mutable properties as part of the RDG - something the TDG does not do provide it's strictly a function based interface.
At which point does a RDG implementation become a data mapper, because of most examples I have seen a data mapper is essentially that, with possibly finder() methods added to the mix, which the underlying TDG would facilitate much more effectively (at least in my vision of what I want achieved). ActiveRecord has been said many times, to simply be a RDG with business logic. So if you inherited from a RDG and implemented business logic you effectively have achieved ActiveRecord.
One draw back to using a simple TDG class as I have built, is the responsibility of programmatically tying togather tables as opposed to using JOIN's. For instance I have a workorder table, with a few ID's - customer, user, etc. Before I return that result to the caller, I must iterate the recordset, and map the details from the customer, user, etc to the array. Not a great deal of work, but a full fledged ORM would assumingly handle this for me.
Eventually I would like to implement a lightweight ORM, if for no other reason than to accomodate this feature.
I am not sure how I envision everything to unfold so I'm just asking for opinions, for the time being lets say:
1. I see the TDG being the lowest level and providing a base for all other operations
2. I see RDG being used to provide/dictate the schema of an individual record
3. Data mapper using both TDG and RDG to meet the requirements of users who prefer data mapper
4. Some kind of ORM that handles the mismtach between object and table(s)
The latter I can see possibly being implemented by using recordset meta information stored in RDG and conventions. When a table is queried, the columns are checked and foriegn key relations are determined based on convention, for instance id_customer would cause a 1:1 mapping of workorder to customer, so querying the workorder model would automatically include the customer details as well.
Obviously 1:1 and 1:n and n:m would need to be made more obvious in the meta data, and I am not very confident this information belongs in a RDG
Anyways, I have lost my chain of thought for the time being, interested in hearing others opinions on their experience implementing any of the patterns mentioned above.
Cheers,
Alex