Return to Answer

Code critique

You indicate that the constructor will be responsible for fetching and hydrating the Entity's values. I know this is tempting. Don't do it. You already have something named DataManager. Shouldn't it handle fetching and hydrating the Entity?

In your magic get/set, you should add some code to handle the cases where a concrete getter/setter exists. Inevitably, you will end up needing special logic or transformations done to data going in our out of the object. Allowing getters and setters to be added later without having to change calling code will make life easier.

Your __set method does not need to return a value.

One example where I think you already need a setter is for the password property. I posted an example about this previously.

/*
 * @param string $clearPassword
 */
public function setPassword($clearPassword)
{
 $this->salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36);
 $this->password = crypt($clearPassword, $this->salt);
}

Me trying to talk you out of writing your own ORM

"I want to create my own class for more convenient work with the database...I don't need to use all their functions"

This indicates that you may not fully understand how to use other ORM tools. Implementing your own ORM is a massive undertaking. What are you ultimately trying to achieve? Write an application? Write an ORM library? Go down this path if you feel you must but, your time is probably better spent learning how to use of the existing tools.

You think you don't need all their (other ORM tools) functions but you eventually will as your application grows and matures. Here is a small list of things that you will eventually need but don't yet realize it:

• Associations - How will you map Entity associations?
• Transactions - How will you deal with transactions?
• Custom SQL - Where would you keep any custom sql?
• Database Migrations - After your app is in production, how will you manage schema changes?

Your Entity class annotations look similar to that of Doctrine's. It uses proxies and cached code to get around the performance issues related to reflection.

Since you seem to favor the Repository Pattern, why not simply use Doctrine?

Code critique

You indicate that the constructor will be responsible for fetching and hydrating the Entity's values. I know this is tempting. Don't do it. You already have something named DataManager. Shouldn't it handle fetching and hydrating the Entity?

In your magic get/set, you should add some code to handle the cases where a concrete getter/setter exists. Inevitably, you will end up needing special logic or transformations done to data going in our out of the object. Allowing getters and setters to be added later without having to change calling code will make life easier.

Your __set method does not need to return a value.

One example where I think you already need a setter is for the password property. I posted an example about this previously.

/*
 * @param string $clearPassword
 */
public function setPassword($clearPassword)
{
 $this->salt = base_convert(sha1(uniqid(mt_rand(), true)), 16, 36);
 $this->password = crypt($clearPassword, $this->salt);
}

Me trying to talk you out of writing your own ORM

"I want to create my own class for more convenient work with the database...I don't need to use all their functions"

This indicates that you may not fully understand how to use other ORM tools. Implementing your own ORM is a massive undertaking. What are you ultimately trying to achieve? Write an application? Write an ORM library? Go down this path if you feel you must but, your time is probably better spent learning how to use of the existing tools.

You think you don't need all their (other ORM tools) functions but you eventually will as your application grows and matures. Here is a small list of things that you will eventually need but don't yet realize it:

• Associations - How will you map Entity associations?
• Transactions - How will you deal with transactions?
• Custom SQL - Where would you keep any custom sql?
• Database Migrations - After your app is in production, how will you manage schema changes?

Your Entity class annotations look similar to that of Doctrine's. It uses proxies and cached code to get around the performance issues related to reflection.

Since you seem to favor the Repository Pattern, why not simply use Doctrine?