After trying some examples I found out that when I use a repository the possibility of using eloquent is eliminated.

This doesn't make sense to me, from what I've read about repositories and eloquent, it still returns a eloquent model.

Take a look at http://culttt.com/2014/03/17/eloquent-tricks-better-repositories/

TerrePorter said:

After trying some examples I found out that when I use a repository the possibility of using eloquent is eliminated.

This doesn't make sense to me, from what I've read about repositories and eloquent, it still returns a eloquent model.

Take a look at http://culttt.com/2014/03/17/eloquent-tricks-better-repositories/

Thank you for the answer.

What I mean is that the returned object do not retain the eloquent methods.

A quote from the laravel archived forum:

Toby said:

Now I go and implement EloquentUserRepository, writing something like return $this->model->find($id); for the find method (where $this->model is an injected instance of the User model.) If I call that method from a controller, service, whatever, I'm going to get back an Eloquent model. I'll be tempted to do some things with my user that aren't obviously specific to Eloquent — for example, I might call one of the relationships and expect to get some more models.

But now if I go and implement FileUserRepository to get user data from the filesystem, I can't return an Eloquent model, right? I could return a stdClass object with the entity's attributes, but that wouldn't have any of the Eloquent methods available to it — so back in my controller/service when I call the relationship, it would break.

Read the full discussion here

I have not really worked in using repositories in my projects yet.

The only problem I see with the referenced post is as my understanding goes with repositories they are not 100% exchangeable. What i mean is if I have a repository that expects a eloquent model to be supplied it has to be a eloquent model.

So the example of changing the repository from EloquentUserRepository to FileUserRepository already fails my understanding of how they work.

However, if you go from EloquentUserRepository to MongoUserRepository as both would likley use the ModelRepository structure would work.

I don't see why the original user could not make the FileUserRepository return a eloquent collection and there by fit the preset requirements.

Thanks for the link, interesting read.

TerrePorter said:

I have not really worked in using repositories in my projects yet.

The only problem I see with the referenced post is as my understanding goes with repositories they are not 100% exchangeable. What i mean is if I have a repository that expects a eloquent model to be supplied it has to be a eloquent model.

So the example of changing the repository from EloquentUserRepository to FileUserRepository already fails my understanding of how they work.

However, if you go from EloquentUserRepository to MongoUserRepository as both would likley use the ModelRepository structure would work.

I don't see why the original user could not make the FileUserRepository return a eloquent collection and there by fit the preset requirements.

Thanks for the link, interesting read.

After some tests and headaches, I found out that trying to call $this on the passed object won't return back the relationship. I had to find the user again and ask about the role.

What I mean is something like this

	//User Role Accessor
	public function getRoleName($id){
		$user = $this->getUserById($id);
		return $user->roles()->first()->name;
	}

But as I was reading further in to details about repositories i found that was a bad practice.

More info here about best practices.

I'll just keep digging around for more information about this topic, because it still is confusing.

So anyone else want to make a suggestion? Or maybe give me some info about best practices with laravel framework?

Thank you.

We had a fight on this in our team :)) ,

finally we found out that by returning the eloquent model from the repository method we are absolutely breaking the encapsulation of our database layer. but it is o.k, repositories are really good for making testing easier ( I am kind of not agree on this. The architecture of our platform should not be affected by testing problems see DHH's talk on 2014 rails talk ).

For just satifsfying the adventure I created a package which uses a friend classes approach to implement the near complete repository pattern.

RezaShadman said:

We had a fight on this in our team :)) ,

finally we found out that by returning the eloquent model from the repository method we are absolutely breaking the encapsulation of our database layer. but it is o.k, repositories are really good for making testing easier ( I am kind of not agree on this. The architecture of our platform should not be affected by testing problems see DHH's talk on 2014 rails talk ).

For just satifsfying the adventure I created a package which uses a friend classes approach to implement the near complete repository pattern.

Thank you for your reply and the very interesting video.But I still don't get it quite much.

Can I use query scopes inside my repositories? It seems I can only do a raw db query and return the result. Query scopes seemed more convenient

Is there a better way to organize my query scopes, accessors and mutators?

Throwing all these functions inside my model file doesn't seem a good practice.

Edit: Would be a good idea to use presenters?

Just put all the logic in my repository and use presenters to access a model's attributes?

Any suggestions?

You can and should organize their scopes in your repository, or use "criteria", which are separate classes containing their scope to facilitate this implementation.

For mutators, there is a design pattern called presenter, who also abstracts of your model that responsibility.

Presenter: https://github.com/laracasts/Presenter

Repository: https://github.com/guilhermegonzaga/repository