It seems to me that a decent approach would be to create a new method in your repository that will handle the password validation. You can then call this method in your service.
Thank you, @theTrip73 for your reply.
After more coding nights, more reading and more research on related subjects, I've come with this "solution" (quoted, as I believe there's no definitive one, but just approaches, as you correctly mentioned):
The password confirmation validation is handle in the Service layer, as I'm giving it the responsibility to handle the application's logic. Therefore, the UserService calls the destroy() method on the UserRepository, as I'm giving this other layer, the responsibility to be only a bridge to my storage solution of choice. Therefore, the Repository should perform direct actions to what it is requested, not caring about what is it for and so on.
As I said, after getting more familiar with this kind of design/architecture, this is what, by now, feels more correct and "natural" to me.
I may post, in a later reply, some interesting links to books, videos and documentations that helped me clarify this and come up to this approach, in the case that somebody may be interested.
Have a nice day!
http://laravel.com/docs/ioc#practical-usage is what you're looking for probably. Repositories are used to abstract your data storage from your model. Services layers are for, lack of a better word, services like "messaging" or anything else which might need many different objects/logic but all end up as messages. The idea is to create a single coherent messaging class composed of independent objects that don't couple themselves together.
Sign in to participate in this thread!
The Laravel portal for problem solving, knowledge sharing and community building.
The community