Laravel年を取ると頭が固くなります。頭突きが強くなるとか言うことではありません。した勘違いが持続することがあります。間違いを拾って、よく考えればおかしいのだけれど、そのまま持続してしまうこともあります。リポジトリーの過去記事でEloquentをそのまま返すより、一般的な配列要素を返したほうがより良いと書きました。交換可能であると考えれば、より一般性の高い配列のほうが良いからです。これは一概に言えません。リポジトリーの利用者が本来そうであるようにEloquentモデルであると認識せず、stdClassインスタンスの配列、もしくはコレクションとして参照するだけであれば、交換可能性を壊すことはありません。コレクションはArrayAccess、Countable、IteratorAggregate、JsonSerializableの実装です。これらはPHPのクラスやライブラリクラスです。配列をLaravelのコレクションに変換するのも簡単です。Eloquent特有のメソッドを呼び出したりしない限り十分に一般的で交換可能です。ネット上でたまにビューにEloquentの結果を渡すことを疑問に思う声をみかけます。MVCパターンを壊すのではないかという疑問です。Eloquentもモデルに含まれるもので、それを参照すること自身は初めからパターンから外れるわけでありません。モデルのロジックが入るという点で、クエリーが発生するようなメソッドを組むのはパターンを崩してしまいます。ORMでも、その他のクラスインスタンスでも、プロパティを参照するのは問題ありません。全部を全部、ビューへインスタンスではない普通の変数で渡す必要はありません。値を取得するメソッドを呼び出すことも問題ありません。値を設定したり、取得と関係ないメソッドを呼び出すのは、役割の分離という観点からは違反することになるでしょう。(MVCにはビューからモデルへの操作があるパターンもあるため、絶対に間違いとは言い切れないのです。ビューの内容をセッションで保存しておけば、Laravelでもコントローラーから受けた変更をビューに渡し、ビューで変更を確認したら、イベント経由でモデルを変更というやり方も可能です。