Laravel in large-scale infrastructure projects

Laravel framework of large-scale projects

 Only a MVC project is not enough, we need a more complete project structure

1. Controller too bloated
2. Model too bloated
3. Medium and large infrastructure projects
   1. Create a directory
   2. Repository
   3. Service
   4. Presenter
4. unit test
5. Conclusion

For beginners to learn Laravel division two, one is a nice program will fill in the MVC architecture, resulting in controller and model aberrant hypertrophy, as the future is difficult to maintain; one is often not aware of the program in which a class rewrite hesitate undecided, after all, is a traditional PHP page of a file. This article in sorting out the most suitable for large-scale infrastructure project Laravel, and both easy to maintain , easy to expand and easy to re-use features, and easy to test .

Controller too bloated

---

RoR is affected, beginners often think MVC architecture is  model,  view,  controller :

• Model is the repository.
• Controller responsible for interacting with HTTP, call the model and view.
• View is HTML.

If in accordance with this definition, the following needs to rewrite Where is it?

1. Send Email, using the external API.
2. Use logic written in PHP.
3. The display format on demand for conversion.
4. Whether to display certain information on demand.
5. Display different information on demand.

Where 1, 2 is a commercial logic, 3, 4, 5 belonging to the display logic, if in accordance with the general definition of the MVC, model is a database, and the view is HTML, these requirements can not be written in the model and view, can only barely write controller.

Therefore, a large number of programs written for beginners will start in controller, the controller causes hypertrophy difficult to maintain.

Model too bloated

---

 Since logic written in the controller is not convenient maintenance, then I would have written in the logic model like?

When you move the logic model from the controller, although the controller table thin, but fat model, from the original model represents the database has now become also responsible for business logic and display logic, the result was even worse.

Model represents the database? Think of it as a  Eloquent classgood, logical database in the repository should be written in, which is why Laravel 5 has not  models目录, Eloquent class is only placed  app in the root directory only.

Medium and large infrastructure projects

---

That change how we write it? Do not confine our thinking in the MVC:

1. Model  : just as Eloquent class.
2. Repository  : auxiliary model, processing logic database, and then injected into the service.
3. -Service  : Auxiliary Controller, business logic, and then injected into the controller.
4. The Controller  : receiving a HTTP request, call another service.
5. Presenter  : display logic processing, and then poured into view.
6. View  : Use blade to bind data to HTML.

Where the blue is the original MVC, and purple is the focus of this article to introduce:  Repository  mode, Service  mode and  Presenter  mode.

The arrow indicates the object dependency injection direction. 11 on dependency injection, please refer to the detailed depth discussions dependency injection

We can still find MVC architecture, due  SOLID  the single responsibility principle and Dependency Inversion principle:

1. We will be separated from the database logic model, assisted by the repository model, the model dependency injection into the repository.
2. We will separate from the business logic controller, assisted by the service controller, the service dependency injection into the controller.
3. We will show logic from out of view, the auxiliary view by the presenter, the presenter dependency injection into view.

Create a directory

In the  app build directory  Repositories, Services and  Presenters directories.
 

 Do not be afraid to create the directory! !

Do not be afraid to establish a directory other than the default Laravel other directory , according to  SOLID  's single responsibility principle, the more the class function, the more responsibility, and therefore violates the single responsibility principle, so you should split your program into smaller portions each part has its own function, not a class feature package hills sea, the so-called universal category , the entire project should not only three parts MVC, let go and build the appropriate directory according to your needs, and proper class into the directory, as long as we have namespace of the class classification can help us.

Repository

Due to limited space, the repository into a separate special article discussion, please refer to how to use the Repository pattern?

Service

Due to limited space, the service into a separate special article discussion, please refer to How to Use Service mode?

Presenter

Due to limited space, the presenter into a separate special article discussion, please refer to how to use the Presenter mode?

unit test

---

Now that model, view, controller object dependencies have been disassembled, are also used dependency injection, so that each part can be individually to unit test, to test such service, it will be the mock repository, or other service can be mock.

Presenter may be a separate unit test run, the other to be mock-Service, the acceptance test is not necessarily run in order to test the display logic.

Conclusion

---

• This article talked about architecture is just the beginning, you can add more directories in accordance with the actual needs of the class, if you find that your MVC violate  SOLID  upon principles, boldly MVC apart from the reconstruction of the class, then according to the following methods:

  1. Create a new class or interface.
  2. The dependency object dependency injection to class.
  3. Deal with his responsibilities in the class.
  4. The class or interface controller or injected into view.

• Finally, with unit testing, the test reconfigurable architecture is the same as the original demand results.