I accept.

johnbdave said:

I accept.

Look how easy acceptance testing is!!! ;)

Interesting question! I'd like to know what the community thinks as well.

I 100% agree. You just summarized what I have thought for the past year dealing with this repository dilemna...

Didn't find a statisfying solution with Eloquent.

My conclusion is that Active Record + Repository Pattern is quite a no go.

As you pointed out, AR + Command Pattern make much more sense.

Great post! I agree with your excellent points. I started falling down that route and decided against it for the same reasons you pointed out. Trying to keep out simple as possible like Rails' DHH philosophy

I completely agree with your sentiment, and I'm working with others to try and address this problem. It's definitely something getting in the way of adoption of better practices.

That said, I'll try to answer these bits:

Why have you used repositories to implement your web application?

Testability, flexibility, and separation of concerns.

Repositories make it easier to test code that interacts with entities because you can mock out the whole mechanism in which entities are fetched. For instance, if you look at this:

$user = mysql_query(); // ...
do_something_with_user($user);

Then you're stuck with $user having to originate from MySQL. There is no other way to set $user - the code has to actually hit the database. By separating the fetching logic out, you can mock the way users are fetched:

class UserRepository {
   function get($id){
      return mysql_query(); // ...
   }
}

$user = new UserRepository;

class SomeClass {
   function __construct(UserRepository $u) {
      $this->u = $u;
   }

   function get($id) { return $this->u->get($id); }
}

// in code
$c = new SomeClass($user);

// in tests
$c = new SomeClass(Mockery::mock()); // or whatever mocking library

It also makes it much easier to implement wide (and safe) caching, etc. Feel free to ask if you want more about this.

Has it paid off?

Definitely. Here's the thing - if a separation of concern isn't paying off for you, then either you're not using it to its full extent, or you just don't need it yet.

Did you use repositories throughout for all data access, including things like validation, authentication, etc?

Yes, and you should. If you're going to follow a pattern, do it right!

Where is the line of diminishing returns (I think that's the right phrase? :))

Rather, it's a line of progressive benefits. Repositories aren't needed for the smallest codebases, where the way you handle data is so simple that you don't really need to test of this type (e.g. where you can get away with integration/functional tests and sqlite or something).

rizqidjamaluddin said:

I completely agree with your sentiment, and I'm working with others to try and address this problem. It's definitely something getting in the way of adoption of better practices.

That said, I'll try to answer these bits:

        <snip... snip.... snip snip snip....> ;)

Seriously, thanks so much for your thoughtful response, I really appreciate it :)

In short, I'm glad to hear of a real person who is using repositories in a real project! And I'm very interested in the fact that you're handling all of your data backend related tasks with repositories. I'd love to see how you're handling things like the unique validation rule.

Regarding your code samples: In my projects I'm injecting all eloquent models into any service class that uses them. So, as you did with your repository, I can easily pass in a mock User (for example). So for test-ability, I think I'm pretty close to the same benefits of your example code.

That said, for me the main reason for me to use repositories at this point is because it gives a logical place for me to abstract some "service layer" logic into. I'm not honestly sure if there is a super strict definition of "service" (there probably is), but basically it's where I'm putting most of the logic that might in a simple application live in a controller. That said, at the moment I have some query related logic in my service layer, which I don't really like. For example, I might have something like

class UserSecurityService extends BaseService implements UserEmailVerificationDelegate
{
//...snip
 public function verifyEmailConfirmationCode($confirmation_code)
 {
  $this->userModel->where('confirmation_code', '=', $confirmation_code)->first();
 }
 //...snip
}

In that example, I might prefer to do something like

$this->userRepository->findByConfirmationCode($confirmationCode);

I'd prefer that, and using repositories would allow me to do that. Of course, I'm sort of being fast and loose with the word "repository", as I could also just do this in a different class.

Anyway, you said

Definitely. Here's the thing - if a separation of concern isn't paying off for you, then either you're not using it to its full extent, or you just don't need it yet.

It's not that separation of concerns isn't working for me, or that my applications don't require it. They do, very much so. I'd go crazy without the concept. The issue is that I haven't QUITE needed repositories yet, at least not to the extent that I've wanted to rewrite Eloquent's functionality.