4

I am working with a Laravel project and I am looking for a way to solve the issue of bloated models and cross referencing between them.

I had started extracting higher level methods to a repository but this doesn't solve the issue of one method needing to know about another method.

For example a task lookup method needs to lookup a slug in another table first. I don't believe I should be placing this code into either model or repository but i'd like a single method to achieve this lookup.

/Models/Slug
/Models/Task
/Repositories/SlugRepository
/Repositories/TaskRepository

I have now started experimenting with adding a gateway/service layer with a higher level methods which can access both of the underlying repositories to complete the task.

The task service would depend on the two repositories above.

/Service/Task
findBySlug()

I think this will work but I am not sure if I should now let the controllers still access the repository directly or force everything through the service/gateway layer.

Or perhaps do away with the repositories entirely and let the services access the models directly, (Laravel abstracts db access anyway).

And on top of it all I want to keep this as simple as possible!

Can anyone confirm this method as a good choice or not or perhaps suggest an alternative?

  • While the substance of this question might be fine, the question title itself is poorly worded, would you please clarify the question title? I'm not familiar with Laravel so I'm not sure It would be appropriate for me to do this. – opa May 7 '18 at 16:04
1

In the end and to keep things simple I went for a task repository and a slug service. The slug lookup needs access to another model which is why I brought it out to a service rather than repository.

I believe this setup maintained the correct separation by keeping the repositories from needing to know anything about other models and yet extracting the lookup logic to a more manageable location.

-1

The repositoy is part of the domain layer. How it achieve its targets is in the infrastructure layer. For example a method like Task getTask(SlugId id) could be perfectly in the Task repository. Now, the implementation of the repository could use a TaskDAO and a SlugDAO to work.

  • 2
    What is your answer to his question? "if I should now let the controllers still access the repository directly "? "Or perhaps do away with the repositories entirely and let the services access the models directly"? This reads like a comment, not so much like an answer. (btw. not downvoting) – joshp Sep 9 '17 at 18:52

protected by gnat Mar 8 '18 at 18:26

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.