2

I'm reading Taylor Otwell's book in which he suggests using the repository pattern. I get the theory behind it. That it's easy to switch implementations and decouples your code. I get the code too. And it is very nice to be able to switch by App::bind() with some other implementation. But I've been thinking for the last two hours how I should approach things for a new CRM I'm building. Almost no code yet but it might end up big.

I would prefer to simply use eloquent models and collection injected through the controller. That should make everything testable if I'm not mistaken.. . Allowing for mocks and such.

Does the repository pattern maybe offer any benefits towards scalability? In cases when more servers or resources are needed..

And why would anybody want to replace the Eloquent ORM once committed to its use? I mean most projects need a relational database. If I would build a UserRepositoryInterface and an implementation DbUserReponsitory, I cannot see when I would ever need or want to switch that with something else. This would count for most entities in my project (order, company, product, ...). Maybe to use another ORM to replace Eloquent? But I don't see myself doing this for this project.

Or am I missing something? My main concern is to have code that is readable and easy to test. Haven't really been testing that well up to now :)

toonevdb
  • 329
  • 1
  • 13
  • That was just an example. There would be other reasons to use a repository rather than just swapping out different types of databases. Working with an external API would be another good example where you'd want a different repository because API's could easily be updated and have new versions added that you may want to utilize in your code. With that said, you can decide to use a repository for some things and do without for others. – user1669496 Oct 21 '13 at 15:57

2 Answers2

1

Dependency injection is nothing new in terms of design patterns, will it hurt your code, not necessarily. Will it hurt your ability to easily write / re-factor old code and swap it in easily... absolutely it will.

Design patterns exist as solutions to common problems. I would tell you straight away that ignoring the IoC container in Laravel and not dependency injecting will have a big impact on you later down the line if you're writing complex applications. Take for example that you may want different bindings based on request type, user role / group, or any other combination of factors, by swapping out the classes without impacting your calling code will be beyond invaluable to you.

My advice, do not ignore the IoC container at all.

As a sidenote, Service Providers are also your friend, I'd suggest you get well acquainted with them if you want to write great apps in Laravel 4.

David Barker
  • 14,484
  • 3
  • 48
  • 77
  • Thank you. I will implement them. But I wasn't planning on ignoring anything. It's just a bit new and want to get started in the right way. And I've also read about service providers. But first I wanted a controller or 2 :) – toonevdb Oct 21 '13 at 16:36
  • Sure, well doing this will definitely get you going in the right fashion. Decoupling allows for much easier testing and TDD (test driven development) is a very good practice to get used to. Good luck! – David Barker Oct 21 '13 at 16:37
1

It does not necessarily mean that ignoring the Repository pattern will give you headaches on the long run, but it certainly makes re-factoring code much easier thus you can easily write Test repositories and bind them with your controllers to easily test your business logic.

So even if it is not likely that you will replace Eloquent or any other part, encapsulating chunks of logic and operations in repositories will still be beneficial for you.

Glad To Help
  • 5,299
  • 4
  • 38
  • 56
  • Thanks. I see your point. If it improves my ability to write better tests I'll certainly use them. And for the reasons stated by David Barker too. Something I wonder then, is it good to return eloquent collections/models from the repository classes or better plain objects/arrays ? – toonevdb Oct 21 '13 at 16:39
  • Just send back the eloquent models that the repo produces. If you're sending back JSON the Response class will automatically convert it for you. Alertnatively it's just as good having the eloquent model available to you in views. Let Laravel do the heavy lifting for you, most of the time you don't need to tell it how you want it if you're data types are correctly set in your ajax requests. – David Barker Oct 21 '13 at 16:58
  • In addition to what @DavidBarker mentioned, that will also set your code free from any Eloquent dependency and your views/clients will not be concerned whether data comes from Eloquent, some third-party API or plain XML/CSV files – Glad To Help Oct 21 '13 at 17:04