Some of this has maybe been discussed in the forums and is also something that Bunny and I have discussed in private chats a few times. I just want to organize the ideas a little and I have a few specific questions.
The model/handler is the component that interacts with the DAO to get/update stored data on one side and processes "items"/artifacts on the other side. To share code, the model/handler will have a few standard methods:
We've previously discussed at length at how slow PHP is to instantiate objects. Thus on a "get" where will be showing the data in a view, we really only need to get the data as "rows" and not package them into any sort of item object. For multiple returned items we have an array of 'rows' (each row being an associative array of column values).
However, 'create', 'insert' etc... can benefit from return an actual data object (since we only need one). $user =& $user_handler->create(); Just like Xoops, I know, but I think it is a good system. Then we have $user->setVar('email', $email); etc... and finally $user->insert()/store(); We could also write $user_handler->store($user); but if we already have the object, why not make full use of it?
So now the questions:
1) Will it be too confusing to have two different return types? (arrays or objects)
2) On a 'get', should we allow the choice to return as an array or object? i.e. If we know we are planning to modify it and re-save to the database.
3) Will we ever run into a case where we 'get' a large number of items, but need these to be in 'object' form because we will be updating? Should we have a 'createFromArray' or 'convertToObject' function to convert from an array to object if we need to update it?
4) Could we use ONLY arrays? i.e. 'create' returns an associative array with the default values filled in. Setting values is just a matter of $user['email'] = $email; or $user_handler->setValue($user, 'email', $email); Having only an array makes it difficult to take advantage of things like checking if an object is 'dirty' making it difficult to tell what has changed.
5) Should we have ONLY objects? This makes things more unified but as our tests have shown can be very slow and as Xoops has shown can run into memory problems with some versions of PHP.
6) Are create/insert/update/delete (used mainly by actions) and get (used mainly by views) sufficiently independent that they should be put in separate handlers? i.e. user_view_handler and user_action_handler . This will give some performance gains on file loading time but will double the number of model/handler files/classes and their associated DAOs. Also, there definitely *are* cases where updates need to be made from a view (e.g. hit counters, last access date/time, access/activity logs). How do we handle those cases?
*Please* let me know your opinions on some or all of these points. We like to have a system which is as fast as possible, but also which will actually be usable and understandable.
Please don't read this until you've responded (I would like your unbiased opinion) but for the record here are my preferences: 1) No, 2) Yes, 3) Yes Yes, 4) Let's not 5) Let's not 6) I doubt it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first post assumes that the "item" object is distinct from the "model" object. This may not be completely in line with phpPatterns etc but I think it has a much more logical syntax, especially for the case when you are fetching, updating or deleting multiple items simultaneously.
i.e. $user =& $user_handler->getById(1234);
not $user_handler->getById(1234);
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off: instantiating objects in PHP is not "slow". It might be a bit slower than creating an array, but it doesn't carry a performance impact like accessing a database or doing regexes or evals. When you get up into the thousands of objects, the impact might slowly become measurable, but with thousands of objects around, performance would not be our biggest worry.
1) yes
2) no
3) no
4) yes
5) no
6) no. Also, views can't do any writing access to the DB, ever. More pointedly: they don't do any DB access, period. If they need any data, they ask a model, and a model can of course update a hit counter whenever it is asked for the current count.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings,
Some of this has maybe been discussed in the forums and is also something that Bunny and I have discussed in private chats a few times. I just want to organize the ideas a little and I have a few specific questions.
The model/handler is the component that interacts with the DAO to get/update stored data on one side and processes "items"/artifacts on the other side. To share code, the model/handler will have a few standard methods:
- getById, getByName?, getMany
- insert
- update, updateMany
- create
- delete, deleteById, deleteByName?, deleteMany
We've previously discussed at length at how slow PHP is to instantiate objects. Thus on a "get" where will be showing the data in a view, we really only need to get the data as "rows" and not package them into any sort of item object. For multiple returned items we have an array of 'rows' (each row being an associative array of column values).
However, 'create', 'insert' etc... can benefit from return an actual data object (since we only need one). $user =& $user_handler->create(); Just like Xoops, I know, but I think it is a good system. Then we have $user->setVar('email', $email); etc... and finally $user->insert()/store(); We could also write $user_handler->store($user); but if we already have the object, why not make full use of it?
So now the questions:
1) Will it be too confusing to have two different return types? (arrays or objects)
2) On a 'get', should we allow the choice to return as an array or object? i.e. If we know we are planning to modify it and re-save to the database.
3) Will we ever run into a case where we 'get' a large number of items, but need these to be in 'object' form because we will be updating? Should we have a 'createFromArray' or 'convertToObject' function to convert from an array to object if we need to update it?
4) Could we use ONLY arrays? i.e. 'create' returns an associative array with the default values filled in. Setting values is just a matter of $user['email'] = $email; or $user_handler->setValue($user, 'email', $email); Having only an array makes it difficult to take advantage of things like checking if an object is 'dirty' making it difficult to tell what has changed.
5) Should we have ONLY objects? This makes things more unified but as our tests have shown can be very slow and as Xoops has shown can run into memory problems with some versions of PHP.
6) Are create/insert/update/delete (used mainly by actions) and get (used mainly by views) sufficiently independent that they should be put in separate handlers? i.e. user_view_handler and user_action_handler . This will give some performance gains on file loading time but will double the number of model/handler files/classes and their associated DAOs. Also, there definitely *are* cases where updates need to be made from a view (e.g. hit counters, last access date/time, access/activity logs). How do we handle those cases?
*Please* let me know your opinions on some or all of these points. We like to have a system which is as fast as possible, but also which will actually be usable and understandable.
Please don't read this until you've responded (I would like your unbiased opinion) but for the record here are my preferences: 1) No, 2) Yes, 3) Yes Yes, 4) Let's not 5) Let's not 6) I doubt it
Just a quick clarification:
The first post assumes that the "item" object is distinct from the "model" object. This may not be completely in line with phpPatterns etc but I think it has a much more logical syntax, especially for the case when you are fetching, updating or deleting multiple items simultaneously.
i.e. $user =& $user_handler->getById(1234);
not $user_handler->getById(1234);
First off: instantiating objects in PHP is not "slow". It might be a bit slower than creating an array, but it doesn't carry a performance impact like accessing a database or doing regexes or evals. When you get up into the thousands of objects, the impact might slowly become measurable, but with thousands of objects around, performance would not be our biggest worry.
1) yes
2) no
3) no
4) yes
5) no
6) no. Also, views can't do any writing access to the DB, ever. More pointedly: they don't do any DB access, period. If they need any data, they ask a model, and a model can of course update a hit counter whenever it is asked for the current count.