How should I design the class for a database entity?

Question

I'm studying OOP PHP and have watched two tutorials that implement user login\registration system as an example. But implementation varies. Which way will be more correct one to work with data such as this?

1. Load all data retrieved from database as array into a property called something like _data on class creation and further methods operate with this property

2. Create separate properties for each field retrieved from database, on class creation load all data fields into respective properties and operate with that properties separately?

Then let's say I want to create a method that returns a list of all users with their data. Which way is better?

1. Method that returns just an array of userdata like this:

   Array([0]=>array([id] => 1, [username] => 'John', ...), 
         [1]=>array([id] => 2, [username] => 'Jack', ...), 
         ...)
   

2. Method that creates a new instance of it's class for each user and returns an array of objects

Answer 1

#2: Create separate properties for each field retrieved from database, on class creation load all data fields into respective properties and operate with that properties separately?

This second option (using a class) is far better in the long term. A common PHP anti-pattern is to pass around everything as key-value arrays, and it eventually becomes a huge pain in the ass. Having a private $this->__data object is the first step down that perilous path.

It will be much easier to understand, debug, and refactor, and as a bonus your IDE can usually help you autocomplete things.

Answer 2

"Then let's say I want to create a method that returns a list of all users with their data. Which way is better?"

1. Arrays: These will be fast, easy, and simple. If you have a few elements in each array, things will be easy to track and focus on. e.g. You'll know that index 0 has the user id, index 1 has the name etc. There is a reason why zend framework 2 uses arrays for configuration rather than large objects. For basic needs this is the way to go.

2. Objects: These will consume more memory and ultimately be (a little-bit) slower. However, type hinting if you need it, and fancy names given to each piece of data is your boon.

The "Best" method depends on your needs. I'd probably go with option 1 most of the time as PHP is a slow language and I like things to be fast. For more complicated systems, I'd use doctrine.

Answer 3

I would say that both situations are not appropriated:

1. The use of arrays to represent business objects is not a good practice. Client code needs to know the exact key of each array cell to correctly adress the data. Documented methods focusing on each field of the entity is definitely better for client-code. Moreover, depending on the size of the database, you might consume a lot of memory and searching into this data structure will be slow.
2. This is better from an OOP perspective. However, you will encouter the same issues as in point 1. As said by Aal, an ORM (Object Relational Mapper) such as Doctrine, will help you to solve memory consumption and slow search issues (see above) because ORMs usually implement querying languages and loading techniques such as Lazy/Eager loading.

To conclude, go for an ORM, or something old fashioned but still valid in small applications like the Active Record or Data Access Object patterns.