Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to hierarchical architecture for large projects in web development". The explanation in this article is simple and clear, easy to learn and understand. Please follow the ideas of Xiaobian and go deep into it slowly to study and learn "how to hierarchical architecture for large projects in web development" together!

Goodbye, model.

Did you delete your models list? Delete it before you delete it! We're going to create a new directory in the app directory named after our app, like QuickBill. We will continue to use the interfaces and classes we wrote in the previous chapters.

Note the use scenarios: Remember that if you are building a small Laravel app, it is appropriate to write a few Eloquent models in the models directory. In this chapter, however, we focus primarily on developing large, complex projects that are suitable for hierarchical architectures.

So, we now have an app/QuickBill directory, which is level with other directories in the app directory such as Http and Console. Under the QuickBill directory we can also create several other directories, such as the Repositories and Billing directories. Once the directories are created, don't forget to register them in the QuickBill namespace via PSR-4 auto-loading in the composer.json file:

"autoload": { "classmap": [ "database/seeds", "database/factories" ], "psr-4": { "App\\": "app/", "QuickBill\\": "app/QuickBill" } },

For now, let's put all the Eloquent model classes under the QuickBill directory. This makes it easy to use QuickBill\User, QuickBill\Payment. The Repository directory contains repository classes such as PaymentRepository and UserRepository. The repository class contains all the data access functions, such as getRecentPayments and getRichestUser. The Billing directory contains classes and interfaces for invoking third-party payment services such as Stripe and Balanced. The entire directory structure should now look like this:

// app // QuickBill // Repositories -> UserRepository.php -> PaymentRepository.php // Billing -> BillerInterface.php -> StripeBiller.php // Notifications -> BillingNotifierInterface.php -> SmsBillingNotifier.php User.php Payment.php

Where is the data validation located? Where to do data validation often puzzles developers. Consider writing data validation methods into your Entity classes (e.g. User.php and Payment.php). The method name can be set to validForCreation or hasValidDomain. Or you can create a validator class UserValidator specifically, place it in the Validation namespace, and inject it into your Repository class. You can try both ways and see which you prefer! Of course in Laravel 5.* You don't need to create your own validator class, Laravel comes with a validator class that meets all your needs.

By getting rid of the model directory, you can usually overcome the psychological barriers to good architectural design and build a directory structure that is more appropriate for your application. Of course, every application you build will have some similarities, because no matter how complex the application is, it needs a data access layer (Repository), some external service layers, and so on.

Don't be afraid of directories: Don't be afraid to create more directories to organize and manage your apps. It is always necessary to divide the whole application into several functional components, each focusing on a certain responsibility. It always helps to think outside the box of "models." For example, as we discussed earlier, you can create a repository directory to store all your data access classes.

The core idea is layering.

You may have noticed that the key to optimizing the application directory structure is to divide the responsibilities of different components, or create different layers for different responsibilities. The controller is only responsible for receiving and responding to HTTP requests and then invoking the appropriate business logic layer classes. Your business logic/domain logic layer is the core of your application, which includes code for reading data, validating data, performing payments, sending emails, and all the other functions in your application. In fact, your domain logic layer doesn't need to know anything about the Web! The Web layer is simply a transport mechanism for accessing applications, and everything about Web and HTTP requests should not go beyond the routing and controller layers. Good architectural design can be challenging, but good architectural design also leads to maintainable, cleaner code.

For example, instead of fetching Web requests directly inside a business logic class, it is better to pass Web requests to the business logic class through a controller. This simple change decouples your business logic classes from the "Web" layer and makes it easy to test your business logic classes without worrying about simulating Web requests:

class BillingController extends BaseController { public function __construct(BillerInterface $biller) { $this->biller = $biller; } public function postCharge(Request $request) { $this->biller->chargeAccount(Auth::user(), $request->input('amount')); return view('charge.success'); } }

The chargeAccount method is now easier to test, since we no longer need to use the User and Request classes in the BillerInterface implementation class, we just pass the user and amount to the method.

One of the keys to writing maintainable applications is separation of duties. Always check if a class is too broad and know what it shouldn't know. Always ask yourself,"Does this class care about X?" If the answer is no, then extract the logic and put it in another class, and inject it with dependency injection.

How do I know if a class is too broad? A useful way to do this is to examine why you changed the code. For example, when we want to adjust the notification logic, do we need to modify the implementation code of Biller? Of course not, the Biller implementation is only concerned with payments, and it should interact with notification logic only through contracts. Using this line of thinking when working with code can help you quickly identify areas of improvement in your application.

Where do you keep everything?

When developing apps with Laravel, you may be confused about where to put all kinds of "things." For example, where do auxiliary functions go? Where do you want the event listener? Where do you want the view component? The answer may surprise you-"anywhere!" Laravel doesn't have a lot of conventions on file systems for this. However, this answer is not satisfactory, so let's start a discussion on this question and discuss where these "things" can be placed together.

auxiliary function

We can create a helpers.php file in the app directory and put custom helper functions into this file. Of course, since this file does not contain classes, it is not suitable to reference the functions in it through namespaces, so you need to register it globally in composer. json:

"autoload": { ... "files": [ "app/helpers.php" ] },

Then run composer dump-auto to re-register the automatic load mapping relationship. Then you can use the helper functions defined in app/helpers.php in your application.

event listener

Event listeners certainly shouldn't be in routes.php, so we'll have to find another place to store them. In fact, in Laravel 5.* When we create a time listener with the php artisan make:listener command, the system automatically creates a Listeners subdirectory in the app directory and places the generated listener classes in that directory. So we can put custom event listener classes in this directory.

error handler

In Laravel 5.* Version, by default all exceptions are handled by App\Exceptions\Handler, you can also use custom exception classes to handle, custom exception classes can be placed in the app/Exceptions directory.

other

In general, you can keep classes neat in your application directory structure by following the PSR-4 specification. Combined with what you have learned so far, you should be able to give a reasoned answer to the question of what code to put where. But never refuse to experiment. The beauty of Laravel is that you can make conventions that work best for your application. Explore and discover the structure that works best for your application, and don't forget to share your insights with others!

For example, you might be inspired by our previous example to create a Providers directory in QuickBill to store all your custom service providers, with a directory structure similar to this:

// app // QuickBill // Billing // Extensions //Pagination -> Environment.php // Providers -> EventPusherServiceProvider.php // Repositories User.php Payment.php

Notice in the example above that we have two namespaces, Providers and Extensions. All your custom service providers can be placed under the Providers namespace, and the Extensions namespace can be used to store classes that you extend to the core of the framework.

Thank you for reading, the above is the content of "how to hierarchical architecture of large projects in web development", after learning this article, I believe that everyone has a deeper understanding of how to hierarchical architecture of large projects in web development, and the specific use situation needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.