### **Bye, Bye Models** ###
Is your *models* directory deleted yet? If not, get it out of there! Let's create a folder within our ``app`` directory that is simply named after our application. For this discussion, let's call our application ``QuickBill``, and we'll continue to use some of the interfaces and classes we've discussed before.
> ### **Remember The Context** ###
>
> Remember, if you are building a very small Laravel application, throwing a few Eloquent models in the ``models`` directory perfectly fine. In this chapter, we're primarily concerned with discovering more "layered" architecture suitable to large and complex projects.
>
So, we should have an ``app/QuickBill`` directory, which is at the same level in the application directory structure as ``controllers`` and ``views``. We can create several more directories within ``QuickBill``. Let's create a ``Repositories`` directory and a ``Billing`` directory. Once these directories are established, remember to register them for PSR-0 auto-loading in your ``composer.json`` file:
For now, let's put our Eloquent classes at the root of the ``QuickBill`` directory. This will allow us to conveniently access them as ``QuickBill\User``, ``QuickBill\Payment``, etc. In the ``Repositories`` folder would belongs classes such as ``PaymentRepository`` and ``UserRepository``, which would contain all of our data access functions such as ``getRecentPayments``, and ``getRichestUser``. The ``Billing`` directory would contain the classes and interfaces that work with third-party billing services like Stripe and Balanced. The folder structure would look something like this:
~~~
<!-- lang:php -->
// app
// QuickBill
// Repositories
-> UserRepository.php
-> PaymentRepository.php
// Billing
-> BillerInterface.php
-> StripeBiller.php
// Notifications
-> BillingNotifierInterface.php
-> SmsBillingNotifier.php
User.php
Payment.php
~~~
> ### **What About Validation** ###
>
> Where to perform validation often stumps developers. Consider placing validation methods on your "entity" classes (like ``User.php`` and ``Payment.php``). Possible method name might be: ``validForCreation`` or ``hasValidDomain``. Alternatively, you could create a ``UserValidator`` class within a ``Validation`` namespace and inject that validator into your repository. Experiment with both approaches and see what you like best!
>
By just getting rid of the ``models`` directory, you can often break down mental roadblocks to good design, allowing you to create a directory structure that is more suitable for your application. Of course, each application you build will have some similarities, since each complex application will need a data access (repository) layer, several external service layers, etc.
> ### **Don't Fear Directories** ###
>
> Don't be afraid to create more directories to organize your application. Always break your application into small components, each having a very focused responsibility. Thinking outside of the "model" box will help. For example, as we previously discussed, you could create a ``Repositories`` directory to hold all of your data access classes.
>
- Dependency Injection
- The Problem
- Build A Contract
- Take It further
- Too Much Java?
- The IoC Container
- Basic Binding
- Reflective Resolution
- Interface As Contract
- Strong Typing & Water Fowl
- A Contract Example
- Interface & Team Development
- Service Provider
- As Bootstrapper
- As Organizer
- Booting Providers
- Providing The Core
- Application Structure
- MVC Is Killing You
- Bye, Bye Models
- It's All About The Layers
- Where To Put "Stuff"
- Applied Architecture: Decoupling Handles
- Decoupling Handlers
- Other Handlers
- Extending The Framework
- Manager & Factories
- Cache
- Session
- Authentication
- IoC Based Extension
- Request Extension
- Single Responsibility Principle
- Open Closed Principle