"Stut" <stuttle@xxxxxxxxx> wrote in message news:452F5DA6.9070103@xxxxxxxxxxxx > 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
