Support the ongoing development of Laravel.io →
posted 10 years ago
Architecture

I've been redoing my controllers to inject repositories and using those classes isntead as the only means to extract db data. So far so good. Eg. below.

public function show($id) {
		$client = $this->clientRepo->find($id);

		$layout_data = [
			'client_id' => $client->id,
			'client_name' => $this->clientRepo->getName($id),
			'client_address' => $this->clientRepo->getAddress($id),
			'cash_client' => $this->clientRepo->isCashClient($id),
			'has_services_to_invoice' => $this->clientRepo->hasServicesToInvoice($id)
			];

		$this->layout = View::make('layouts.clients.base_new', compact('layout_data'));
	}

Passing an array of data to the View has been working out really great, and it's nice knowing its completely independent of whichever implementation of interface I choose.

However, I'm struggling to figure-out best practices around using objects w/ relationships. One of my views, for example, has a model that makes a call to another model, and then some. eg .below

{{ $client->contacts->first()->hasUserAccount() }}

or

@foreach($clients as $client)
    if ($client->isCashClient()) ...
@endif

Is it fine to send models directly to the view, or is there a better way to send data to the view that allows me access to those relationships to display in the View?

Does any of this make sense? :)

Thanks!

Last updated 3 years ago.
0

Makes perfect sense.

Welcome of the 'using active record with repository pattern' contradiction.

Ideally, in a perfect world, you would return orm-agnostic php object from your repositories, having relationships as collections, etc... Which, let's face it, is a lot to implement.

So all its down to having a perfect architecture vs having something done quickly (and which work the same :) ) , it's almost always a tradeoff.

Eloquent is awesome as a RAD tool, because it's really flexible, making things like fetching relationships from the view possible. When I use Eloquent or ActiveRecord, I usually use it to its full potential, without overengineering things to much with repositories or so on. Or switch to a Data Mapper if I want a strict separation of concerns.

Just to say, for me i think leaking a little 'logic' in the view is ok, in 90% cases, unless you plan to reuse them in a non-laravel application (or even non-php), in which case you probably won't be using blade anyway.

0

Thanks Remi.

What I'm choosing to move forward with is have the repository classes return multidimensional arrays, and the views only reference $view_data['client_name'] or $client_pets['pet_name'].

But I agree, I do not see ever moving away from Eloquent models, and certainly not Laravel.

0

RemiCollin This is the smartest thing I've heard on this forum lately. +1

0

Sign in to participate in this thread!

Eventy

Your banner here too?

unohuim unohuim Joined 1 Sep 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2025 Laravel.io - All rights reserved.