I have a User model which has "Payments" in quotes because depending on the user, there could be multiple sources of payments, like StripePayments or BraintreePayments. Instead of writing all the business logic inside the User model via something like a getPayment() method, I'd like to delegate it out to another layer. The business logic entails retrieving only, and the retrieved data could be of a single payment source or mixed.

At my company, "repositories" have been used for this kind of stuff, but I feel the pattern is misused, and I'd like to know if there's another suitable pattern. This is something I would've traditionally put into the service layer or even a helper, if I couldn't find a place for it.

Any suggestions on this? I'm using PHP and Laravel for this.

  • Why do you feel the repository pattern is misused? – Aleksander Oct 12 at 14:18
  • @Aleksander Many reasons. You can correct me if I'm wrong, but one reason is that I think the repo pattern should encompass all CRUD, replacing the need to do it directly from the model, and pertain to a single entity per repo. Currently, they're just complex getters, and I'm looking for an alternative. – musicliftsme Oct 12 at 14:30
  • It seems you mean that an entity and a (ORM) model are the same thing which is not true especially in the context of repositories. While repositories should support one entity, that entity could be made of many (ORM) models. Also, you said the logic about getting payments were only retrieving them, but that’s the easy part, the hard part is to know which type of payment to retrieve. This is where your logic should be. Everything about retrieving can be done in the repository along with ORM helpers. – Steve Chamaillard Oct 22 at 14:50

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.