fnwbr's avatar

Repository Pattern with Data-Tables & Filters?

Hello guys,

I'm starting to rewrite an app with Laravel 5 which currently does not use any framework, it is basically only PHP with some hand-made / some thrown-in libraries for templating, database stuff etc.

It consists out of a e-commerce / online-shop frontend part, where visitors can simply browse through categories, view items, put them into their cart and then order them. Just pretty basic stuff. Furthermore there is a backend part, where basically the shop manager can create/edit/delete items/customers/orders, print invoices, edit shipping fees and all that stuff.

The thing is: The backend also has some heavy filtering options and huge data tables when it comes to the customers or items. Each entity has many attributes and the backend user needs to be able to filter by every attribute (also including filter mixes, where they filter out by using multiple attributes connected by AND/OR) and he needs to be able to sort by nearly every attribute (integers, strings, timestamps, pricing values etc.).

My question is: Does it make sense to use the repository design pattern in this scenario? Lately everybody seems to use them and I definitely see the benefits of using them. Or should I use repositories only on the frontend part? (Does not make sense in my opinion) Or is it actually totally easy to implement all these filtering/sorting stuff into a repository-pattern-using application and I'm just missing something? Or should I just use Eloquent inside my Commands/Controllers? (Furthermore I'm 99% sure that I won't have to switch data source every; and if this will become the case, then rewriting the app is definitely do-able)

Thanks for reading, I look forward to every answer/opinion on this!

0 likes
4 replies
Alias's avatar

Going to throw it out there, but why would you do all of this sorting a filtering in the backend? Using (I assume you are using it) SQL to sort data in this fashion will be slow, and if you're not careful could easily cause a grid-lock in your database if it's not handled properly.

Why not return your data in a structured JSON format, and let the client side code handle how it's displayed/filtered/sorted? It's super easy with something like AngularJS, and will have no performance impact on your server.

But to answer your question, in my eyes: If your project is small, the repository pattern is probably overkill. However as your project grows, and you start to test code, using the repository pattern keeps your code testable and logical. It doesn't matter whether or not you're going to swap out another data source, it just provides a clean way to access your data. Let your controllers handle the flow, and repositories handle the data.

1 like
fnwbr's avatar

Thanks for your responses, will read through those links.

@Alias Would returning the whole data in JSON format work, if there are like multiple thousands of entries? Say I have 50.000 items in my database, each one having between one to three image- and one or two category-relationships assigned, and many attributes on the items themselves. I actually have never thought about using such large sets on the client-side with Javascript.

Ultimately: Let's say I'm ditching the repository pattern completely for now - the application itself is not that large, only the database might be large, in some cases - would it be condemnable to use Eloquent in "its full glory" in Commands / Events / ..., wherever you would actually make use of the repository?

pmall's avatar

The repository pattern is just a way to abstract and uniformize the data accession. It will not change the way you access the data for each implementation.

Please or to participate in this conversation.