Hey guys, Lately I have been working on a Virtual marketplace application using Laravel and PostgreSQL. So, when I was asked to build this huge application, the biggest challenge I faced was the design. Having a fair bit of prior experience in Laravel and upon following the current community trend, I decided to go with Laravel. And I hoped and expected that this, somewhat opinionated framework, would take care of my design to a large extent. When I actually started designing it, I realized that for a small/medium application Laravel already has things in place, you, as a developer just need to follow the guidelines set in place by the framework and use the features its providing out-of-box. However, for a larger application, with lot of interdependent modules and complex business flows, you need to make your own design decisions as well along with the existing features. This gave me an opportunity to take a look into the various existing design patterns to solve my design probl
Hi folks, Today I am gonna be sharing my experience of implementing and working with Repository Design Pattern in Laravel. As you must be aware that Repository Pattern is one of the widely used design patterns " which separates the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. In other words, business logic can access the data object without having knowledge of the underlying data access architecture " My first hand experience Around a year ago I started working on a Service Provider App with Laravel as the back-end exposing APIs for the front-ends like the Mobile and Desktop Apps. And like any other architect, while designing this huge looking application I had to take some important decisions on the architectural level. One of them being the buzzing, totally in, Repository Design Pattern bandwagon which everybody in the tech world was taking and if not that, at-least talking about. I went throug