It really depends on how everything is set up and how your domain logic works. I guess I would consider any problem like this arising from poor design in the first place. Normally, for each user I'd have an instance (User) and a mapper for that user instance (UserMapper). Then to ban the user, we'd just call a setBanStatus (or something) method on that User instance. In the source, we'd see something like:
PHP Code:
<?php
class User extends DomainObjectAbstract
{
protected $id = null;
protected $banStatus = null;
//protected $username, etc...
public function setBanStatus ( $status )
{
$this->banStatus = $status;
}
//additional setter methods
public function getBanStatus ()
{
return $this->banStatus;
}
//additional getter methods
}
Then to map the user to the database, you'd want a class capable of CRUD -- create, read (aka, fetch), update (aka, save), delete (aka remove... below, create/update function in the same method):
PHP Code:
<?php
class UserMapper extends DataMapperAbstract
{
//the abstract class will take care of our database handle
//fetch and remove methods which use a `User`'s getId() method to target a user
public function save ( User $user )
{
$id = $user->getId();
$ban = $user->getBanStatus();
$prepare = $this->connection->prepare("
INSERT INTO Users (id, banStatus)
VALUES (:id,
:banStatus) ON DUPLICATE KEY
UPDATE banStatus = :banStatus2
");
$prepare->bindParam( ':id', $id, \PDO::PARAM_INT );
$prepare->bindParam( ':banStatus', $banStatus, \PDO::PARAM_STR );
$prepare->bindParam( ':banStatus2', $banStatus, \PDO::PARAM_STR );
$prepare->execute();
}
}
You could essentially ban a single user like:
PHP Code:
$bob = new User();
$bob->setId( 5 );
$bobMapper = new UserMapper();
$bobMapper->fetch ( $bob );
$bob->setBanStatus( 1 ); // 1 = ban?
$bobMapper->save ( $bob );
For multiple users I'd use a collection pattern, which is essentially a glorified array. Though the User interface I've provided above is subject to change, collection patterns will undoubtely change depending on how you need to use them. You could create a UserCollection, set conditions on the UserCollection in a setBanStatuses method, then when you need to update it in the UserCollectionMapper (which wouldn't need to have a create method, allegedly... depending on your needs, of course), just select all the users and update them.
Another approach is to violate dependency injection (which, in some ways, your original idea to create an array from a single instance does) and create a user mapper within the user collection mapper, but that seems like a bad idea entirely and could get extremely method.
Probably a better approach (and this depends entirely on how your database is setup) is to have a BanUser and BanUserCollection method, but then, as I said before, you'd probably also have a table of banned users in your database, which doesn't sound too fancy either. Another sloppy idea, the ban classes could possibly access the user table themselves. Rereading, my first idea seems the most logical, but again it all depends on how the logic in your interface works, how the database structure works, and how you want to handle different functions like updating users.
Though this is less of a response and more of a "reprogram what you're doing." In any case, I'm sure finding a nice balance between what you're doing and clean coding/interfacing/designing is possible.
Array input to function, a new approach
Reply With Quote
Originally Posted by djr33
Bookmarks