Should views be weaned from object methods in favor of assoc. arrays?

Question

Yii

Divide and Conquer is taught by MVC patterns and so on. I looked at several frameworks and objects in views are used everywhere. In general, it seems to be okay, but when it comes time for optimization, many frameworks recommend abandoning objects in favor of regular queries and array ass. But then the Divide and Conquer logic breaks down, as soon as you start optimizing, you have to rewrite the views too! So I thought, maybe you should immediately teach views to use only assoc. arrays? Fortunately, you can also work with objects as with arrays. Then, when optimizing, it will be enough to prepare assoc arrays of data, instead of objects, and that's it.
Or I misunderstood and it is possible to optimize such things more easily?
// upd
It just seems to me that the view should be as "stupid" as possible, it should not know that this variable is an object, and this is an array. She just needs to show variables, cycle through arrays. And so the view imposes logic on controllers and models that this or that variable should be exactly an object.

Answer 1

In fact, such an optimization will not make sense - if we add a layer between the controller and the view that will convert the object that the controller worked with into an array that the view will work with, this will only worsen performance. For optimization, it will be necessary to abandon objects altogether and work only with arrays. And this step should never be taken until you are 146% sure that it is necessary.
In addition, such "optimization" can even worsen things, because it will not be possible to implement lazy data calculation. A simple example - if the order is not confirmed, then you do not need to display the amount of its goods, but if it is confirmed, you need to. Imagine that the amount is not stored anywhere and is calculated on the fly from the items in the order basket. If using an object, the total would not be performed at all for unconfirmed orders because the getTotal() method would not be called in the template. And when converting to an array, you will need to calculate everything, because it is not known what is useful in the template and what is not.
Premature optimization is the root of all evil (s). Optimization is a distinct process of deliberately degrading (usually) an architecture in favor of resource usage. Therefore, complaining that optimization makes something break there, in my opinion, is pointless.
On the contrary, it is the controllers that give the data and, by definition, they impose the logic of its work on the template. And that's okay.
But when you start building an architecture based on the fact that there should be arrays in the view, because sometime in the indefinite future, perhaps the objects will consume too many resources and have to be redone - this doesn’t seem normal to me.
Yes, you can add ArrayAccess support to all classes, but what's the point? If the view will work with the object, then this is just a waste of time. If the view will work with an array, then ArrayAccess will not help here - there is no object anymore. I see no reason to do such a hot swap.
It's like making a framework-agnostic application so that you can replace Symphony with Laravel at any time - the idea is cool and the design will probably be better in the end (but far from a fact, because such a complication can only make things worse), but in practice such moves are very rare and even when they do, they are not painless.
It is much more efficient to do the minimum necessarydesign, and then, if necessary, spend extra time on transferring. By and large, what you propose is Big Upfront Design and I am not a supporter of this approach. It is better to make changes iteratively based on the current needs of the paying business and not look too far into the future. There is a non-zero probability that while you are implementing the ArrayAccessable Interface classes in the classes, the customer will go bankrupt and your beautiful, extensible, maintainable code will turn out to be useless.
Of course, I am exaggerating in this particular case, but my experience shows that such an attitude is the most beneficial for me and for the customer.
PS I wrote all this as an alternative point of view for everyone who will read this question later. Use whatever floats your boat, as they say, there is no silver bullet in architecture.

Answer 2

I personally adhere to this logic - very convenient.
UPD: fully agree with //upd

Answer 3

I have arrays in most views, because I also use AngularJs.

Answer 4

In most cases, you will need a certain data format that is inconvenient to format in the View - readability worsens, lines are repeated. Objects can have their own getter functions that will pre-process the data and return it to the View in a convenient form. (Sometimes even it is not necessary to format, but to carry out a little processing logic.)
Objects after -> in normal IDEs have code autocomplete, which is a big plus in development.
And arrays and even bare SQL queries should be used when they are already snickering (sorry for the expression) and there is nothing to do but optimize saving on matches.
PS I do not mean those cases when complex queries are formed and large data is selected, but rather I am talking about ordinary development.
Who is too lazy to read -stop saving on matches, enjoy the development, and don't look for crap =)

Answer 5

And I like the approach that is used in template engines. From the template, a single interface to data. And between the data and the template, the adapter, which somewhere works with them as with an array, somewhere as with an object, somewhere uses getters in order of priority.

Answer 6

So what prevents an object from implementing the ArrayAccess interface and accessing it in any of the ways?