"Stut" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Ed Lazor wrote:
>> On Oct 12, 2006, at 4:36 PM, Stut wrote:
>>> If I then go on to create an admin interface for the users, I would 
>>> create another completely separate class called UserCollection to handle 
>>> more than one user. I may at that point choose to expose any 
>>> data-massaging methods in User to UserCollection to avoid code 
>>> duplication, but that would be the extent of the way UserCollection uses 
>>> the User class since the User class is optimised to work on a single 
>>> user at any one time.
>>
>> We use a similar approach for the user class.  I haven't ever implemented 
>> something like the UserCollection class though.  I'm curious about that. 
>> Does your UserCollection class extend the basic user class?  Or is it 
>> something else entirely; I dunno, maybe UserCollection has a property 
>> defined as an array of User class?  I think that's what people were 
>> saying earlier in the thread as being a "very bad thing" in terms of 
>> memory utilization, etc.
>
> Indeed, that would be a very bad thing, unless you've already considered 
> that. I've previously mentioned that I have an ActiveRecord-style 
> implementation for a lot of my DB access. The base class for that system 
> has a static function called FindAll which will return an array of 
> objects. However, it only does a single SQL statement. The base class also 
> has a method LoadFromArray which, shockingly, loads the object from an 
> array. This means that from a single DB request I can get an array of 
> objects each representing one entitity (potentially a row, but not 
> necessarily).

The very idea of one object per row makes me want to throw up. I have one 
object per table, and each object can deal with any number of rows. I don't 
use getters and setters to access the columns from any row, I simply input 
an array (typically one row from the $_POST array) and output an array which 
may contain any number of rows. I find this to be far easier and no less 
efficient.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to