2

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

  • 2
    In short. 2 is better. – Ozair Kafray Nov 21 '13 at 6:22
  • I agree and recommend to have a look at ORMs like Doctrine or Propel. And try to avoid arrays whenever possible since they are kind of anti-OOP (e.g. no type hinting)... see the php manual for alternatives like Traversable, Iterator and ArrayAccess. – Paul Voss Nov 21 '13 at 10:00
  • Slight peeve, when you say class creation, you mean object creation. Class creation would be the act of writing the class code. – Tomas Zubiri Nov 22 '18 at 8:09
  • These are two questions, would you care to separate them into two please? The first one is, should my class store the data from the database as a (presumably raw) single $_data variable or as separate properties? he second one is, should my function return an object or an array? These merit two different answers, since the second one has already been answered, I recommend extracting the first one into its own question. I'll post my answer as soon as you do this. Thanks, and good job on the interesting questions! – Tomas Zubiri Nov 22 '18 at 8:45
2

#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.

1

"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.

  • I like this answer, there is a time and place for each of these design patterns, if you just want to get this done and move on, using arrays is a viable solution. Creating a load of classes or using ORM might be overkill in some situations. But in general, for core elements of an application, using classes is a worthy time investment. – Tomas Zubiri Nov 22 '18 at 8:08
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.