Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am wondering, in view templates, what would contribute to me choosing between using arrays or objects for getting things printed out in arrays

{{$user->zip_code}} vs {{$user['zip_code']}}

I'm working in blade templates in Laravel/PHP fwiw.

My feeling is that it makes sense to use objects: we can use methods if we need to to display/format data, it looks a lot cleaner in the views, and bc of how PHP works fails gracefully if the item isn't set (an unset array value will puke, so you either need to make sure all possible properties are present but false, or do a {{(isset($user['zip_code'])) ? $user['zip_code'] : ''}} for everything you use in a view.

However, I have encountered some contrasting opinions like: the less the view knows about the layers below it, the better. As such, "flat" values (arrays) are better to use in the view. We should not trust the view not to explode if a value is not set, that should be handled in the controller.

Because our object properties are not encoded in the models in this system, we can't rely on each object always having the same info in a model level.

Wondering if there are other factors at play here. Orr.. Does it not matter

share|improve this question
add comment

3 Answers

It's a developer perception. The OOP design concept was introduced in PHP with introduction to version 5 and has been a successful one. At the initial level the use of array seems to be much easier than the use of Objects due to the use of pointer notation instead of dot notation as in other OOP based languages. But as you move ahead on the platform OBJECTS will be more preferred way of handling data. It makes the code much better to be maintained in the larger complex system and easier for the other developers from PHP background to understand.

share|improve this answer
add comment

Use objects.

Objects are most always better. I say most always because people will always have their preferences/opinions/skillset (when they takeover or further change your codebase). In particular, whether it's Twig, Blade, etc... it is relatively irrelevant.

Er, I digress into philosophy...

Main reason is if you rename 'zip_code' to 'ZipCode' (or something similar) then your template variables will BREAK! However, if you're using an object based implementation [ie, a real PHP Model or Object representation of $user] then the 'magic' __get will be implemented looking at your object's parameter(s), OR you can implement a getZipCode() method that would return was is needed.

Point being is it'll be more robust if you use objects.

share|improve this answer
add comment

Object or array is of little consequence here really, they are just there to provide the view with a data store that it can access. What is important is that you are providing the view with data designed for the view and not simply reusing other objects because it feels like they fit. A User is different to your authentication service than it is to your view.

It may seem convenient to simply pass the same User object that is used in authentication to the view and display the username on the page; however, when you want to be able to also display a nickname later on you'll then be introducing a nickname property into your authentication service. Likewise when you go to test your view you would then have to mock the User object that including information for authentication when really you just wanted to display the anme.

A better method would be to create a ViewModel class (or array) and add the user's information to this. Pass this object to your view. Now if you want to add a nickname you do not need to alter anything with the authentication service, you simply need to pull the nickname from the appropriate data store into your view model and continue on. Likewise now that the view is using its own model you can provide sensible defaults to display in the event that there's an error (for example the user can't be found in the database).

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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