|
|
Posted by "Michael Sims" on 09/19/05 22:04
Chris W. Parker wrote:
> Let's take for example a class called 'Customer' that (obviously)
> manipulates customers in the database. Here is a very basic Customer
> class. (Data validation and the like are left out for brevity.)
[snip]
> Where I get tripped up is when I realize I'll need to at some point
> get more than one customer at a time and thus I want to add a method
> called 'get_customers()'.
>
> Since an object should be a single instance of something (e.g. ONE
> customer) how do I justify adding the method 'get_customers()'? Or
> better yer, how do I properly add a method like that? (A method where
> instead of using a SQL statement to return ONE customer's data I
> instead return a record set with more than one customer.)
[snip]
Basically you're implementing DAO's (Data Access Objects), similar to what an ORM
(Object Relational Mapper) tool would do for you. There are lots of different
approaches for implementing DAO's, but personally I prefer to use a DAO class that
represents one entity in my database (in your example, the Customer), and then have
another separate class which is responsible for data operations on my DAO (the peer
class). (This is the approach that many existing ORM tools use, both in the PHP and
Java worlds.) In other words, Customer is only used to access the data that has
been retrieved, but Customer itself doesn't have any methods for retrieving,
updating, deleting, or saving. The CustomerPeer class handles all the data
operations on Customer. If you want a particular Customer instance, you ask the
peer to retrieve it for you, and it returns the appropriate object. If you want to
save changes to a Customer, you retrieve the right instance, set its attributes,
then give it back to the peer class which handles the database interaction. So, the
Customer class is completely ignorant of the database, and is only concerned with
giving you access to the data that is related to that Customer (and any other app
specific methods that it makes since for the Customer class to handle).
The advantage to using this approach is that you can easily have your peer class
return an array of Customer objects, each one representing only one customer.
Chris W. Parker wrote:
> Well, yes I think it does, but what I'm missing is how this new object
> interacts with the original one if it does at all. And what would I
> call it? 'Multiple_Customers'? Or.. perhaps just 'Customers'! :)
>
> Do I extend the Customer class or is it a stand alone class?
As stated, I wouldn't recommend creating a new class to hold the Customers. Just
use a normal PHP array of Customer objects.
In your spare time, take a look at Propel (http://propel.phpdb.org/), an ORM for
PHP5. I wouldn't suggest trying to introduce something like this in the middle of
an existing project, but consider toying around with it for a future project. I
used this for my last application with great success. It used 20 DAO's, similar to
your Customer object, and Propel saved me a lot of tedious work in implementing all
of the data-related methods+getters/setters for these 20 objects. If you have any
questions about it feel free to drop me a line or check out the Propel mailing list
which is very helpful.
HTH...
Navigation:
[Reply to this message]
|