With growing our business in the process of work, bring certain difficulty to project management and maintenance, especially the personnel exists abnormal changes in the team, can appear some problems, the problems in the project will have emerged, others may write code when add requirements or change requirements need to be adjusted, I don’t know where to start.

In fact, for a team, a good project structure and programming habits are a great growth for both the team and individuals. Here is a brief description of how the directory structure of the company’s projects has been iterated over the past three years. Big changes have also been made.

In order to reduce the dependency between projects, both the front end and the back end of our company are built with microservices. The company already had a rudimentary directory structure in place when the team was very young. The front-end part mainly adopts the popular Vue, and the evolution of the directory structure in this paper is also extended for the Vue project.

Directory structure prototype

In the initial stage of project creation, the whole project was still in bad condition. Data requests were all written in **. Vue files, and there was no unified plan for the whole project. As a result, once some contents of the project were changed, it was likely to affect the whole project. For the maintenance of the project can be described as a mess.

However, in order to solve these problems, we planned the directory structure for the first time. In fact, this time, we mainly referred to the directory structure recommended on Vuex’s official website.

├ ─ SRC / / project directory │ ├ ─ API / / data request │ ├ ─ assets / / resources │ │ ├ ─ baseData / / static data │ │ └ ─ images / / smaller image resources │ ├ ─ components / / component │ │ ├─ ├─ exercises, ├─ exercises, exercises, exercises, exercises, exercises, exercises, exercises, exercises, exercises, exercises, exercises │ ├─ ├─ main.js // ├─ ├─ garbage //Copy the code

This kind of project structure is relatively normal in a single page, each folder does its own thing, for the overall project maintenance is relatively easier.

  1. API: Mainly responsible for providing methods for data requests
  2. Assets: provide data resources and smaller picture resources needed by the business.vue-cliWill compile the smaller images intobase64
  3. Components: carries all the components needed in the servicebaseandbusinessFurther compartmentalize the base components
  4. Routes: Writes the route structure
  5. Mixins: Mixing of common code
  6. Store: State management in a page
  7. Style: Page and component styles
  8. Views: Stores pages
  9. Utils: Tools needed in a page or component, and secondary encapsulation of other third-party tools
  10. Main.js: entry file for the program
  11. Static: a large static resource file

Although the above adjustments have been made to the project, with the development of business, the project will still be more and more chaotic. Where are the chaotic places?

  • First, the business components of all the pages are all in one place, which is not particularly easy to find
  • Second, all the pages are storedviewsUser management, for example, may have user details, changes, additions, but these are stored with other business pages
  • The third point is thatrouterThe more content businesses there are, the bigger the business is, which is also a big burden for a project

In fact, for the above problems are not particularly big problems, can use files or folders to split each part of the business is relatively independent.

To improve the

Before proceeding, great consideration was made. First of all, there was the storage problem among modules. Although this problem could be solved by dividing folders, it also brought about the problem of resource loading. There is no need to use a store, however this will load some unwanted resources when loading page resources. After repeated attempts, the final use of multiple pages and single page combination of the form. Resources are used in vUE instances only when certain resources are needed.

├ ─ SRC / / project directory │ ├ ─ API / / data request │ ├ ─ assets/resources/static │ │ ├ ─ baseData / / static data │ │ └ ─ images / / smaller image resources │ ├ ─ │ component / / business component ├ ─ domain / / business page │ ├ ─ mixins / / mixed with │ ├ ─ the instance / / page instance │ ├ ─ middleware / / middleware │ ├ ─ publicComponents / / utility components │ │ ├ ─ base / / ├─ ├─ exercises, ├─style, ├─ exercises, ├─ exercises, exercises, exercises, exercises, exercises, exercises, exercises ├ ─ └─ garbage //Copy the code

By adjusting the directory structure above, the contents of the whole project become clearer. The main purpose of joining a domain is to separate the page presentation from the business logic, and put the business processing into the domain for processing.

In order to save space, only change the file function

  1. Component: Stores only the business components that depend on the page. Folders are used to divide pages within folders
  2. Domain: Used to process business parts, such as data processing before submission and data processing before data request
  3. Instance: an instance of a page, owned by multiple pages, divided internally by folders
  4. Middleware:VueThe generic middleware in the example is split internally using two folders, respectivelymiddleware.style.jsandmiddleware.javascript.js
  5. PublicComponents: A component common to all pages, divided into foldersbaseandbusinessFurther division of business components and base components

It should be noted that the understanding and cognition of instance and routes is based on the business module, while routes are based on the function of a module. For example, in instance, the content related to business A is divided, but there is only one page for this part of business, so there is no need to use routes at this time, and business B has A lot of content, so we need to use Routes to further divide the content.

To put it bluntly, the role of instance is to divide businesses, so that the two businesses are also divided in the same project. However, routes are divided twice on the basis of services. What should belong to the business is processed only within the jurisdiction of the business module.

In the development process of the system, with the increasing content in the project, it will generally bring a big problem. When the file business in views is particularly large, it needs to define many methods in the page, as well as the processing of business. When it comes to modifying the use of code, the feeling is simply not too cool, a file on the code, and method dependence on each other who can not do without who, ha ha ha, this feeling is too sweet. And writing a function requires frequent scrolling up and down during development. In order to solve this problem and finally consider the problem of more content on the page, for implementation, structure and behavior are separated from the use of mixed form.

Add the mixing of page business in the mixing file. The JavaScript in the views file is put into the corresponding ***.js file according to the business in the page, reducing the JS code for business processing in the page. After tweaking, it’s time to introduce domain files in Miaxins.

The final version

In order to achieve the separation of structure and performance, mixing was used to solve this problem indirectly, but it violated the original intention of mixing. As time passes, this is not a long-term solution, and internal adjustment is still needed. Before the emergence of domain, it is written in ***.vue. Is it possible to extract this content and inject it directly into the page? It’s ok to try, but the part of JavaScript that you’ve pulled out is still bloated.

In fact, the domain not only controls the page but also controls the behavior. The content of the domain is divided into controller and Service. All page performance is processed and managed by controller, while Service is responsible for the processing of a single business and the management of page data.

Vue scaffolding has been upgraded to use Vue3.0 scaffolding.

├─ API // Data Request ├─ Assets // Static Resources ├─ Components // Components ├─ Instance // Page Instances ├─ Middleware ├─mixins ├─ exercises, ├─ basic // Exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // exercises // ├ ─ └─ //Copy the code

Front-end students should know that the front-end through structure (HTML), performance (Style), behavior (JavaScript) to complete the entire page, but this adjustment is the original domain of the second division, so that the entire page structure, Style, behavior away from.

Some of you might ask, well, how do services, Controllers, and Views relate to each other? In fact, the es6 class used here introduces the Controller and related service into the page during page creation. During page creation, the Controller is created at the same time, and the Service is injected into the Controller as a parameter when the Controller is instantiated.

When a part of the business needs to be adjusted temporarily, it can directly create a new class and inject it into the business, without changing the original code. When the business needs to change back, it can directly replace the injected service.

test.vue

<template>
    <div>
        <p>{{controller.pageService.page}}</p>
        <p>{{controller.pageService.size}}</p>
    </div>
</template>

<script>
import TestController from "@/controllers/test/view/TestController";
import TestService from '@/services/test/view/TestService';

export default {
    data:() = > ({
        controller: new TestController(
            newTestService(); ) })}</script>
Copy the code

TestController.js

export default class TestController {
    constructor(pageService){
      this.pageService = pageService; }}Copy the code

TestService.js

export default class TestService {
    constructor(){
        this.page = 1;
        this.size = 20; }}Copy the code

After splitting the domain, the project as a whole becomes easier to adjust and expand the page. No matter how the business changes, even if the business logic is changed, it does not need to change the original code but only need to adjust the injected instance. So far, so good.

conclusion

This paper records the overall adjustment and consideration of the project structure, the main purpose is to achieve the overall structure, performance, behavior of the relative separation. By adjusting the directory structure, the maintenance and expansion of the overall project is more controllable.

If you have any questions, please leave a comment below. For its business separately written scaffolding QJ -web- CLI welcome to download.