Notre entreprise est relativement simple et directe et adopte votre deuxième option.
Le framework PHP est utilisé. Le front-end n'a qu'à écrire la page, puis la logique back-end est traitée. Si vous avez besoin d'utiliser 框架语法或者php语法 pour définir des pages ou quelque chose du genre, laissez le personnel back-end afficher la page de rendu (certains js sont également écrits par le back-end, et le front-end n'a besoin que d'écrire la page statique).

Les pages front-end peuvent être écrites sans aucun problème, et les pages back-end sont généralement assez rapides. Si le personnel back-end rencontre un problème avec le style lors du rendu des données de vue, il le soumet au système problématique (oui, nous avons un projet système problématique, qui est limité à un usage interne et est utilisé par le front-end et le back-end. -le personnel final pour soumettre les bogues), puis tout le personnel front-end et back-end. Les développeurs finaux vérifieront chaque jour s'il y a leurs propres problèmes sur le système problématique, puis les résoudront.

En fait, tant que les règles sont établies et que tout suit les règles, la coopération entre le front et le back-end sera pratique et claire.

Le vrai front-end et le back-end doivent être JS pour obtenir les données de l'interface et ensuite les parcourir. Si la page est modifiée, cela doit également être une chose front-end

La première consiste à implémenter le mode MVVM, ce qui signifie la séparation front-end et back-end. Le front-end n'a pas besoin de maîtriser le framework d'arrière-plan ou les méthodes d'arrière-plan pour restituer la page. peut être complètement séparé de la page, facilitant ainsi la maintenance. De plus, l’interface API backend peut être utilisée sur davantage de plates-formes et ne nécessite pas de développement secondaire. L'inconvénient est que si la page est la page d'accueil, elle nécessite de nombreuses API pour obtenir les données et les restituer. Mais l'architecture MVC est beaucoup plus pratique
La deuxième façon d'implémenter MVC est que le backend est responsable de la définition de la logique et le frontend est responsable du rendu de la page, mais le frontend doit avoir une certaine compréhension des modèles dans le développement backend MVC. Personnellement, je pense que cela rend le backend plus pratique et rend le frontend plus difficile.
La troisième explication.
En fait, il existe un autre type de travail front-end et back-end. Bien sûr, c'est un aspect qui n'est pas largement applicable aux projets. Par exemple, NODE.JS
En fait, cela dépend principalement de la configuration front-end et back-end de votre entreprise et du projet. Par exemple, une entreprise comme la nôtre qui a un B de plus dans le backend et un front-end de moins peut utiliser une architecture MVC, et le rendu front-end est géré par le backend. Bien entendu, si vous avez de nombreuses personnes front-end, le modèle MVVM est nettement plus adapté. Bien sûr, ce n'est qu'un problème superficiel

Cela semble être juste un problème humain, je pense qu'il n'y a rien de mal à cela

Notre entreprise utilise les deux types que vous avez mentionnés. Concernant le premier, je me demande si votre entreprise a retiré les pages frontales des projets Java ou PHP ou si elles sont toujours imbriquées dans ceux-ci ? S'il est imbriqué dans un projet Java ou PHP, cela ne posera pas de problème si le front-end est intégré dans le moteur de modèles back-end. Les projets back-end de notre société sont tous imbriqués dans des projets Java et ne sont pas déplacés séparément. .J'utilise souvent le front-end. Il n'y a rien de mal avec la méthode d'écriture du moteur de modèles back-end. Quant au deuxième type, le coût du débogage conjoint est relativement élevé. Personnellement, je pense qu'il n'est pas élevé. Je ne sais pas dans quelles circonstances le débogage conjoint est plus gênant pour vous.

Donnez-leur un statique et laissez-les jouer à l'ajax par eux-mêmes

Identique à l'affiche originale, développement mixte, bien qu'il y ait de nombreux problèmes, mais vous ne pouvez rien y faire si vous ne le faites pas plus tard, vous ne pouvez pas les battre.
Il existe de nombreuses façons de séparer les extrémités avant et arrière. Bien entendu, l’idéal est de connecter le front-end et le back-end avec des interfaces pures, afin qu’ils ne soient pas mélangés.
Mais la réalité n'est pas la même. Par exemple, si l'entreprise dispose d'un back-end et d'un front-end existants, vous ne pouvez ajuster la page que dans le code back-end.
Notre solution consiste à empêcher le backend de déplacer la page.
Les avantages sont
1. Contrôle frontal exclusif de la page
2 La séparation des responsabilités front-end et back-end
Les inconvénients sont
1. Besoin d'apprendre le modèle back-end
2. 3. De nombreux échafaudages frontaux ne peuvent pas être utilisés

Je pense que soit il n'y a pas de séparation, le front-end ne conçoit que des pages statiques, et le back-end est responsable de l'intégration,
Soit le front-end et le back-end sont complètement séparés, et le back-end écrit les API ; , et le front-end utilise jquery ajax ou réagir, vue pour appeler ces API, et la page est entièrement écrite par le front-end.

En cas de séparation complète, le backend doit écrire une interface standardisée, et chaque interface doit fournir une documentation claire (à la fois les instances de données renvoyées par des flux normaux et les instances de données renvoyées par des flux anormaux ! Principalement la structure hiérarchique de la valeur de retour et la dénomination de variables) , pour faciliter le développement front-end pour utiliser ces données), lorsque l'interface change, le document doit être mis à jour à temps, et il est préférable d'en informer le développeur front-end. Si vous ne le faites pas, la coopération avant et arrière deviendra un gâchis ! !

Le document d'interface est donné en arrière-plan. Lorsque le front-end écrit une page statique, il peut simuler de fausses données selon le document d'interface, et finalement annuler l'opération simulée une fois l'interface écrite

Le premier type a plus d'exigences sur le front-end. Les données de la page sont restituées via la connexion entre les interfaces API, et le back-end n'a besoin que de fournir l'interface. De cette façon, la division du travail est plus claire et chaque poste ne doit faire que ce pour quoi il est bon

Le deuxième type nécessite plus de back-end. Le front-end n'a besoin que de fournir des pages de modèles statiques, et le back-end restitue les données via le cadre de modèles. Certains effets nécessaires doivent également être écrits avec des ajax et des J pour obtenir. Lorsqu'un problème survient, un débogage conjoint du front-end et du back-end est requis.

Je travaille en PHP back-end Personnellement, si l'entreprise a plus d'expérience en développement front-end et a utilisé anglajs, ajax et d'autres frameworks, elle peut utiliser la première méthode, qui sépare le front-end et le back-end. Au contraire, en utilisant le deuxième type, le front-end n'a besoin que de créer des pages statiques, et le back-end restituera et traitera les données