Thinking more about a shared API for a User object...
There's issues about the architecture for the User object itself. In=20
pLog right now, the UserInfo object is a strict "value object." It just=20=
has get/set methods for properties such as name, password, email, etc.=20=
The Users object is a dao (data access object), a "helper class" that=20
populates the UserInfo object, containing all the necessary SQL. I=20
think that's great, separating the SQL in a separate class. You still=20
have to have access to both classes, though, when you need to access=20
Seems the User object should be a value object (a place where one=20
sets/gets name, email, etc., replacing UserInfo). It could be a base=20
class that gets subclassed to add properties that are specific to=20
particular projects. So PlogUser extends User to add a method=20
getBlogs(). But what happens when I want both pLog and WhizzyForum and=20=
WhizzyForumUser extends User, too? I think that's multiple inheritance.
It would be nice if the User object had some potential for persistence=20=
beyond the session. Like a method load() to populate it, or save() to=20
save it to the database. That way you could
which would see if the user already exists in the database and create a=20=
new user if not. Later you could
to update the user's database record.
This could be problematic if the SQL was hard-coded in the User object,=20=
but a UserDao helper object could contain all the database-specific=20
SQL. So one could instantiate the User object with $user =3D new=20
User('plogUserDao') or $user =3D new User('whizzyForumUserDao') =
on the backend database. (I think that's a Factory pattern, am I right,=20=
I suppose that approach could be extended for authentication, so:
is actually a wrapper to $userDao->isUserInRole('admin') which could be=20=
implemented differently in either the plogUserDao class or the=20
I don't know how well this would stand up to the test of actual=20
implementation but it's interesting to think about.