Pourquoi le recto et le verso devraient-ils être écrits séparément ?

Comme nous le savons tous, les entreprises nous demandent généralement d'écrire le front-end et le back-end séparément. Pourquoi faisons-nous cela ? Cette fois, je vais vous expliquer pourquoi les parties avant et arrière doivent être écrites séparément. Ce qui suit est un cas pratique. Examinons-le ensemble.

Si vous n'avez pas essayé le workflow de séparation front-end et back-end, vous pouvez d'abord imaginer un tel changement de processus :
Changer le processus de
PM : "Je veux cette fonction"
Backend : "Créons d'abord un modèle à partir du frontend"
Frontend : "Le modèle est terminé"
Backend : "Laissez-moi le connecter, le style ici est faux"
Frontend : "J'ai fini de le modifier"
Backend : "Livraison de fonctions"
PM : "Cette activité sera ajoutée pendant la Fête du Printemps"
Backend : "Trouvons d'abord le frontend pour changer le modèle"
Frontend : "Le modèle est terminé"
After End : "Laissez-moi le connecter, le style ici est faux"
Front end : "Je l'ai modifié"
Back end : "Livraison de la fonction "

devient

PM : "Je je veux cette fonction"
Front-end : "Je veux une interface"
Back-end : "L'interface est terminée"
Front-end : « Je vais le connecter et livrer la fonction »
PM : « Cette activité sera ajoutée pendant la Fête du Printemps »
Front-end : « Une interface doit être ajoutée »
Back-end : « L'interface est terminée »
Front-end : « Laissez-moi le connecter et livrer la fonction »

On voit que le front-end et le back-end sont séparés. Le concept principal est le suivant : le backend n'a besoin que de fournir une interface API et le frontend appelle AJAX pour réaliser la présentation des données.

Situation actuelle et différences

En tant que développeur front-end, nous devrions essayer de nouvelles technologies, améliorer chaque problème de détail et constamment nous dépasser. Bien que la séparation du front-end et du back-end ne soit pas une technologie ou une idée nouvelle, de nombreux développeurs back-end et même les développeurs front-end n'y ont pas été exposés.

D'après ma compréhension personnelle, si dans un département, tout le personnel du département est des développeurs back-end et que certaines pages front-end sont également complétées par le personnel back-end, alors la séparation du front-end et du back-end Le -end leur est peut-être inconnu. Dans le domaine, la plupart des projets sont fortement couplés au front-end et au back-end, et la notion de front-end n'existe même pas.

Dans les entreprises ou les départements qui ne prêtent pas attention au front-end, il n'y a rien de mal à ne pas comprendre la séparation du front-end et du back-end. La plupart des entreprises entrepreneuriales ont un ou deux départements front-end dans chaque département, et une seule personne est responsable de plusieurs projets. Il est rare qu'elles collaborent pour mener à bien un projet. Parce qu'il n'y a pas de norme du tout (la norme ici fait référence à la structure organisationnelle du code), le personnel frontal coupe les images, écrit les pages et les envoie au back-end, et la structure du code back-end est utilisée comme la norme. Bien que certaines entreprises soient conscientes de la séparation front-end et back-end, elles ne savent pas comment la mettre en pratique. À cette époque, le personnel back-end du département pensait que la séparation du front-end et du back-end signifiait que le back-end n'avait plus besoin d'écrire du HTML et du JS et pouvait s'en remettre au front-end. cela ne peut s’appeler qu’une division du travail en amont et en aval.

Ce qui précède décrit une situation : je ne comprends pas la séparation du front-end et du back-end, et je ne sais pas comment la pratiquer. Il existe une autre situation ci-dessous : vous comprenez la séparation du front-end et du back-end, mais vous ne voulez pas l'essayer.

Concernant la deuxième situation, de nombreuses personnes ont donné des explications correspondantes. En fait, cela implique la question des « avantages et inconvénients de la séparation front-end et back-end ». De nombreux employés du backend penseront qu'il n'y a aucun problème avec ce qu'ils ont fait. Même si le backend applique le HTML front-end, c'est courant et a toujours été la tendance générale. Le framework backend MVC est également recommandé de cette manière. très raisonnable. À l'heure actuelle, les développeurs front-end n'ont souvent pas suffisamment leur mot à dire dans le département, ou pensent que les opinions des développeurs back-end sont toujours justes et n'ont aucune subjectivité.

Au contraire, il est également possible que les développeurs back-end recommandent fortement la séparation front-end et back-end, mais les développeurs front-end ne veulent pas la pratiquer. À ce stade, le front-end pensera que les développeurs back-end s'amusent. Dans le passé, les projets se déroulaient en douceur sans séparer le front-end et le back-end. les extrémités sont séparées, cela entraînera une charge de travail supplémentaire et des coûts d'apprentissage, qui dépendent des capacités techniques et de ce que nous avons vu.

Bien sûr, c'est aussi là que je pense personnellement qu'il existe certaines situations actuelles et des différences dans la séparation du front-end et du back-end.

Scénarios et exigences

Tous les scénarios ne conviennent pas aux scénarios d'application de séparation front-end et back-end, mais la plupart des projets peuvent être réalisés grâce à la séparation front-end et back-end.

Étant donné que je suis principalement engagé dans le développement front-end d'applications back-end au niveau de l'entreprise, je crois personnellement que pour le développement d'applications back-end, les avantages de la séparation front-end et back-end sont loin l'emportent sur les inconvénients.

Nous pouvons transformer la plupart des applications d'arrière-plan en applications SPA (applications d'une seule page), et la principale caractéristique des applications d'une seule page est l'actualisation partielle. Cela peut être réalisé en appelant AJAX via le routage de contrôle frontal et en fournissant. interfaces en arrière-plan. De plus, cette méthode offre une expérience plus conviviale, les pages Web se chargent plus rapidement, les coûts de développement et de maintenance sont également considérablement réduits et l'efficacité est considérablement améliorée.

De même, la séparation front-end et back-end est également essayée dans les sites Web d'affichage et les pages d'applications mobiles. Lorsque les frontaux et les back-ends ne sont pas séparés, le serveur doit traiter le côté Web séparément et renvoyer du HTML complet, ce qui augmentera inévitablement la complexité du serveur et aura une mauvaise maintenabilité. Le côté Web doit charger du HTML complet, ce qui affecte les performances. de la page Web dans une certaine mesure. C'est très peu convivial pour un endroit où les performances mobiles sont reines.

Avec le développement et l'itération de la technologie front-end, le framework front-end MVC a vu le jour. En utilisant les frameworks front-end traditionnels actuels, tels que React, Vue, Angular, etc., nous pouvons facilement créer un site Web. qui peut être affiché sans rendu côté serveur. En même temps, ce type de framework fournit une fonction de routage frontale. Le backend ne peut plus contrôler les sauts de routage et lancer toute la logique métier appartenant à l'origine au. du front-end au front-end. Cela peut être considéré comme la séparation la plus complète du front-end et du back-end. Ce qui suit est un morceau de code pour le routage des contrôles front-end :

'use strict'export default function (router) {
    router.map({        '/': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            }
        },        '/m/:params': {            component: function (resolve) {                require(['./Mobile.vue'], resolve)
            }
        },        '/p': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            },            subRoutes: {                '/process/:username': {                    component: function (resolve) {                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

La réalisation de la séparation front-end et back-end élèvera les exigences en matière de personnel technique, en particulier de personnel front-end, à un niveau supérieur.Le travail frontal ne consiste pas seulement à couper des pages, à écrire des modèles ou à en traiter. Pour une logique js simple, le front-end doit traiter divers formats de données renvoyés par le serveur, et doit également maîtriser une série de logiques de traitement des données. , les idées MVC et divers frameworks grand public.

Avantages et signification

Nous pouvons également considérer la signification de la séparation front-end et back-end comme la signification du rendu front-end. J'ai principalement résumé les quatre points suivants : <🎜. >

Libérer complètement le front-end

Le front-end n'a plus besoin de fournir de modèles au back-end ou le back-end intègre le code du back-end dans le html du front-end, tel que :

<!--服务器端渲染 --><select>
    <option value=&#39;&#39;>--请选择所属业务--</option>
    {% for p in p_list %}    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}</select>

Ceci est couplé entre l'avant et l'arrière et a une mauvaise lisibilité.

<!--前端渲染 --><template>
    <select id="rander">
        <option value=&#39;&#39;>--请选择所属业务--</option>
        <option v-for="list in lists" :value="list" v-text="list"></option>
    </select></template><script>export default {    data: {        return {            lists: [&#39;选项一&#39;, &#39;选项二&#39;, &#39;选项三&#39;, &#39;选项四&#39;]
        }
    }，
    ready: function () {        this.$http({            url: &#39;/demo/&#39;,            method: &#39;POST&#39;,
        })
        .then(function (response) {            this.lists = response.data.lists // 获取服务器端数据并渲染
        })
    }
}
</script>

Ce qui précède est un morceau de code rendu par le front-end. Le front-end appelle l'interface backend via AJAX. La logique des données est placée sur le front-end et maintenue par le front-end.

Améliorer l'efficacité du travail et rendre la division du travail plus claire

Le flux de travail de séparation front-end et back-end permet au front-end de se concentrer uniquement sur les questions frontales, et le back-end ne s'en soucie que sur les activités back-end. Le développement des deux peut être effectué en même temps, et il n'y a pas de temps dans le back-end. Lorsqu'il fournit une interface, le front-end peut d'abord écrire les données ou appeler un json local. L'ajout de pages et la modification des itinéraires ne doivent pas perturber le backend, ce qui rend le développement plus flexible.

Amélioration des performances locales

Grâce à la configuration du routage front-end, nous pouvons réaliser un chargement des pages à la demande. Il n'est pas nécessaire de charger toutes les ressources du site dès que la page d'accueil est chargée. Le serveur n'a plus besoin d'analyser la page frontale. L'interaction avec la page et l'expérience utilisateur ont été améliorées.

Réduire les coûts de maintenance

Grâce au framework MVC front-end actuel, nous pouvons localiser et découvrir le problème très rapidement. Les problèmes côté client ne nécessitent plus la participation du personnel back-end et le
débogage<.>. Refactorisation du code et amélioration de la maintenabilité. Sentiments et compréhension :

En cours de route, les projets se succèdent, depuis la page de routage de contrôle en arrière-plan et de rendu en arrière-plan au début jusqu'au routage de contrôle frontal actuel, front- fin des données de rendu, du workflow et des méthodes ont beaucoup changé. A chaque fois que je rencontrerai la situation suivante, je soupirerai d'émotion devant les avantages apportés par la séparation du front-end et du back-end :

1 Lors de la réalisation de la page front-end au début du projet, Je n'ai plus besoin du backend pour moi

Configurer l'environnement du serveur

2. Les fichiers front-end du projet peuvent être jetés dans le serveur lorsque vous avez besoin d'appeler l'interface backend. de les mettre au préalable3 L'ajout d'une page de projet nécessite de configurer le routage Je n'ai plus besoin de demander à mes collègues back-end de l'ajouter pour moi, je peux le gérer moi-même sur le front-end4. les fichiers front-end ne contiennent plus de logique de code back-end, et cela semble beaucoup plus confortable
5. Les sauts de page sont plus fluides qu'avant. C'est fluide, le rendu partiel et le chargement partiel sont très rapides
6. Les modèles de page peuvent. être réutilisé, et le développement de composants frontaux améliore l'efficacité du développement

et ainsi de suite. Face au développement rapide du front-end, nous devons nous adapter aux changements dans les méthodes et les processus de travail qu'il entraîne. La méthode de travail actuelle consistant à séparer le front-end et le back-end doit être la tendance à l'avenir. Développeur -end, nous devrions assumer la responsabilité de vulgariser le nouveau front-end Connaissances et responsabilité de faire la différence.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture connexe :

Comment Angularjs implémente-t-il les onglets de style mvvm ? Case + Code

Une collection de codes très pratique pour les projets vue2.0

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!