저희 회사는 비교적 간단하고 간단하며 두 번째 옵션을 채택합니다.
PHP 프레임워크가 사용됩니다. 프런트엔드는 페이지를 작성하기만 하면 백엔드 로직이 처리됩니다. 框架语法或者php语法를 사용하여 페이지 등을 설정해야 하는 경우 백엔드 직원이 렌더링 페이지를 출력하도록 하세요(일부 js는 백엔드에서 작성하기도 하며 프런트엔드는 정적 페이지만 작성하면 됩니다).

프론트엔드 페이지는 문제없이 쓸 수 있고, 백엔드 페이지는 대체적으로 꽤 빠릅니다. 백엔드 담당자가 뷰 데이터를 렌더링할 때 스타일에 문제가 있는 것을 발견하면 이를 문제 시스템에 제출합니다. (예, 내부 사용으로 제한되고 프런트엔드와 백엔드에서 사용되는 문제 시스템 프로젝트가 있습니다. -엔드 담당자가 버그를 제출) 그러면 모든 프런트엔드 및 백엔드 담당자 최종 개발자가 매일 문제 시스템에 자체적으로 문제가 있는지 확인하고 해결합니다.

사실 규칙이 정해져 있고 모든 것이 규칙을 따르는 한 프런트엔드와 백엔드 간의 협력은 편리하고 명확할 것입니다.

실제 프런트엔드와 백엔드는 인터페이스 데이터를 가져온 다음 이를 순회하는 JS여야 합니다. 페이지가 변경된 경우에도 프런트엔드여야 합니다

첫 번째는 프런트엔드와 백엔드 분리를 의미하는 MVVM 모드를 구현하는 것입니다. 프런트엔드는 페이지를 렌더링하기 위해 백그라운드 프레임워크나 백그라운드 메서드를 마스터할 필요가 없습니다. 페이지에서 완전히 분리될 수 있어 유지 관리가 더 쉽습니다. 또한 백엔드 API 인터페이스는 더 많은 플랫폼에서 사용할 수 있으며 보조 개발이 필요하지 않습니다. 단점은 페이지가 홈페이지인 경우 데이터를 얻고 렌더링하기 위해 많은 API가 필요하다는 점입니다. 하지만 MVC 아키텍처가 훨씬 더 편리합니다
MVC를 구현하는 두 번째 방법은 백엔드가 로직 설정을 담당하고 프런트엔드가 페이지 렌더링을 담당하지만 프런트엔드는 MVC 백엔드 개발의 템플릿에 대해 어느 정도 이해하고 있어야 한다는 것입니다. .개인적으로는 이것이 실제로 백엔드를 더 편리하게 만들고 프런트엔드를 더 어렵게 만드는 방식이라고 생각합니다.
세 번째 설명입니다.
사실 또 다른 종류의 프론트엔드 작업과 백엔드 작업이 있습니다. 물론 이는 프로젝트에 널리 적용되지 않는 측면입니다. 예를 들어 NODE.JS
는 실제로 주로 회사의 프런트엔드 및 백엔드 구성과 프로젝트에 따라 달라집니다. 예를 들어 우리와 같이 백엔드에 B가 하나 더 있고 프런트엔드가 하나 적은 회사에서는 MVC 아키텍처를 사용할 수 있으며 프런트엔드 렌더링은 백엔드에서 처리됩니다. 물론 프론트엔드 인력이 많으면 MVVM 모델이 확실히 더 적합합니다. 물론 이것은 표면적인 문제일 뿐입니다

이건 그냥 사람의 문제인 것 같은데 별 문제가 없는 것 같아요

저희 회사는 말씀하신 두 가지 유형을 모두 사용하고 있습니다. 첫 번째에 관해서는 귀하의 회사가 Java 또는 PHP 프로젝트에서 프런트 엔드 페이지를 가져왔는지, 아니면 여전히 그 안에 중첩되어 있는지 궁금합니다. Java나 PHP 프로젝트에 중첩되어 있는 경우에는 백엔드 템플릿 엔진에 프론트엔드를 내장시켜 놓으면 문제가 되지 않습니다. 저희 회사의 백엔드 프로젝트는 모두 Java 프로젝트에 중첩되어 별도로 이동되지 않습니다. .. 프론트엔드를 자주 사용합니다. 백엔드 템플릿 엔진의 작성방법에는 이상이 없습니다. 두 번째 유형의 경우, 공동 디버깅 비용이 상대적으로 높습니다. 개인적으로 어떤 상황에서 공동 디버깅이 더 번거로운지 모르겠습니다.

스태틱을 제공하고 스스로 Ajax를 플레이하게 하세요

원래 포스터와 똑같고, 혼합 개발이지만, 문제가 많지만 나중에 안 하면 이길 수가 없어요.
앞부분과 뒷부분을 분리하는 방법은 다양합니다. 가장 이상적인 것은 물론 프런트 엔드와 백 엔드 사이의 순수한 인터페이스 도킹이므로 서로 섞이지 않습니다.
하지만 현실은 그렇지 않습니다. 예를 들어 회사에 기존 백엔드와 프런트엔드가 있는 경우 백엔드 코드에서만 페이지를 조정할 수 있습니다.
저희 솔루션은 백엔드의 페이지 이동을 중지하는 것입니다.
장점은
1. 프론트엔드 단독 제어
2. 프론트엔드와 백엔드 책임 분리
단점은
1. 디버깅이 불편함
3. 많은 프런트엔드 스캐폴딩을 사용할 수 없습니다

분리 없이 프론트엔드가 정적인 페이지만 디자인하고 백엔드가 통합을 담당하거나
프런트엔드와 백엔드가 완전히 분리되어 백엔드가 API를 작성하는 경우도 있을 것 같습니다. , 프런트 엔드는 jquery ajax 또는 반응, vue를 사용하여 이러한 API를 호출하고 페이지는 프런트 엔드에 의해 완전히 작성됩니다.

완전히 분리되는 경우 백엔드는 표준화된 인터페이스를 작성해야 하며 각 인터페이스는 명확한 문서를 제공해야 합니다(정상 흐름에서 반환된 데이터 인스턴스와 비정상 흐름에서 반환된 데이터 인스턴스 모두! 주로 반환 값의 계층 구조 및 이름 지정) 변수), 이러한 데이터를 사용하여 프런트 엔드 개발을 용이하게 하기 위해) 인터페이스가 변경되면 문서를 적시에 업데이트해야 하며 프런트 엔드 개발자에게 알리는 것이 가장 좋습니다. 이렇게 하지 않으면 앞뒤의 협력이 엉망이 됩니다! !

인터페이스 문서는 백그라운드에서 제공됩니다. 프런트 엔드가 정적 페이지를 작성할 때 인터페이스 문서에 따라 일부 가짜 데이터를 모의할 수 있습니다. 마지막으로 모의 작업을 취소하려면 인터페이스가 작성될 때까지 기다리세요

첫 번째 유형은 프런트 엔드에 더 많은 요구 사항이 있으며, 페이지 데이터는 API 인터페이스 간의 연결을 통해 렌더링되며 백 엔드에서는 인터페이스만 제공하면 됩니다. 이런 방식으로 업무 분업이 더 명확해지고 각 직위는 자신이 잘하는 일만 하면 됩니다

두 번째 유형에는 더 많은 백엔드가 필요합니다. 프런트엔드는 정적 템플릿 페이지만 제공해야 하며 백엔드는 템플릿 프레임워크를 통해 데이터를 렌더링해야 합니다. 문제가 발생하면 프런트엔드와 백엔드의 공동 디버깅이 필요합니다.

저는 백엔드 PHP로 작업합니다. 개인적으로 회사에서 프론트엔드 개발 경험이 많고 anglajs, ajax 및 기타 프레임워크를 사용해 본 적이 있다면 프론트엔드와 백엔드를 분리하는 첫 번째 방법을 사용할 수 있습니다. 반대로 두 번째 유형을 사용하면 프런트 엔드는 정적 페이지만 생성하면 되고 백 엔드는 데이터를 렌더링하고 처리합니다