多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
### **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. >