Laravel 4: Methods for Staying Organized

Laravel 4 already has a place for pretty much everything, so it feels organized out of the box. However, the larger your application is the more unorganized it starts to feel. Here are a few small things I do to help keep things organized.

Namespace Controllers and Models

This one is pretty simple, but I namespace all of my controllers and models. For instance, UserController.php might look like this:


My models generally are namespaced like so:


Map Table Prefixes to Namespaces

Let’s assume the following: we have a business and the business has many executives. This is a one-to-many relationship; the business can have many executives and each executive belongs to the business.

The tables businesses  and  business_executives seems reasonable for this setup. Since the executives belong to the business we prefix the executives table with business_. To help organize the related models I like to utilize namespacing. The related models would look like this:



Utilize Repositories

Jeffrey Way wrote an excellent article that covers the use of repositories within Laravel (scroll down to the Repositories heading), so I’ll refer you to that article if you’re not sure what repositories are.

However, in short repositories are an additional level of abstraction. They sit between your controllers and your models and act as a data-access layer, allowing your controllers to query data without accessing your models directly.

This is especially useful if you don’t want to muddy up your Eloquent models (keep them ‘pure’) or if you have specific functionality that requires several models; for instance, if your application is creating an event with several occurrences and must insert both Event and EventOccurrence models then you can perform both of these actions within a single method in the repository. An example might look like this:


The repository is also a great place to consolidate validations. In the previous example, validations for both models can be performed within the save() method, and validation rules for saving an event can be stored together in the repository rather than separately within the models (or together in the controller) – this helps keep your models clean and your controllers slim.

If you have any of your own methods for organizing projects please post them in the comments below!

  • Nikko Bautista

    These are all solid points – one thing though. In an event where you have a models that also relate to other models, or like you have a polymorphic model, how do you namespace those?

  • crhayes

    Hey Nikko, thanks for the comment. Setting up namespaces with related models is straightforward. Here is an example:

    The car model would look like:

    Hope that helps! Let me know if you have any other questions.

  • Guilherme Cardoso

    I don’t agree with validation in repositories. Shouldn’t they be a data layer, totally abstracted of any validation or business logic?

    • crhayes

      TBH I’m not sure what the general consensus on the matter is, although I know many people perform validation within a repository class. The data should always be validated before persistence, so IMO it’s a good way to consolidate the validation logic and make code more DRY.

      I published a Laravel package that helps move validation into service classes; I wrote a blog post about it here:

      For my projects I create validation services, inject those into my repositories, and then perform the validation check within the repository.

    • crhayes

      Just to follow up on this post. I’ve recently moved to using service classes for ‘application concerns’, such as sending emails, transactions, validations etc. I’m actually not utilizing repositories, because truthfully the way most people have advocated them really doesn’t provide that much benefit.

      A DbRepository returning Eloquent models is not abstracted enough… the Eloquent dependencies can too easily leak into your controller and view code. If you then switch to, say, MongoRepository (which no longer returns an eloquent object) your code could easily break. The repositories should likely return POPO (Plain-Old PHP Object) entity objects, and use the data mapper pattern to persist them (like Doctrine 2 does). Without implementing all of that infrastructure I can’t see the value of repositories, so I’ve chosen not to use them for now.