Probleme mit der Website-Architektur

Derzeit verfügt unsere Website über vier mobile Endgeräte (IOS, ANDROID, PC, TV). Zusätzlich zum PC-Terminal greifen andere Endgeräte auf Daten über das API-JSON-Datenformat zu, das PC-Terminal jedoch nicht, sofern nicht Beispielsweise verwenden einige Listenseiten usw. die API, während andere PC-Seiten beim Rendern der Seite direkt im Hintergrund generiert werden. Das Problem, auf das wir jetzt stoßen, ist, dass die von diesen vier Terminals benötigten Schnittstellen unverständlich sind. Auch wenn die Schnittstellen gleich sind, sind die Datenstrukturen oder Felder unterschiedlich. Unser aktueller Ansatz besteht darin, das MVC-Modell auf der Serverseite sowie eine Bibliothek zu verwenden. Für die Schnittstelle rufen wir einfach die Klassen und Methoden in der Bibliothek auf. Für den PC haben wir eine einfache Bezeichnung implementiert Eigentlich indirekter Zugriff. Wenn ich beispielsweise die Benutzerliste abrufen möchte, sieht das im Controller, der die Heimatadresse bereitstellt, so aus:

<code>// .....
$userList = User::getList()
return $this->success($userList);</code>

Dann schreiben Sie auf der PC-Seite Folgendes auf die Vorlage:

<code>{{ userlist = Tag_User_getList() }}
// ....</code>

Grundsätzlich handelt es sich um eine solche Struktur, die jedoch viele Nachteile mit sich bringt. Beispielsweise ist es nicht möglich, die PC-Seite von der mobilen Seite zu trennen. Zweitens werden die von der mobilen Seite benötigten Daten nicht unbedingt benötigt PC-seitig und umgekehrt. Möglicherweise werden dadurch einige ungenutzte Daten usw. gelesen.
Dann würde ich gerne fragen, wie sie dieses Problem in einigen großen Projekten lösen? Zum Beispiel Taobao, JD.com usw.

Antwortinhalt:

Derzeit verfügt unsere Website über vier mobile Endgeräte (IOS, ANDROID, PC, TV). Zusätzlich zum PC-Terminal greifen andere Endgeräte auf Daten über das API-JSON-Datenformat zu, das PC-Terminal jedoch nicht, sofern nicht Beispielsweise verwenden einige Listenseiten usw. die API, während andere PC-Seiten beim Rendern der Seite direkt im Hintergrund generiert werden. Das Problem, auf das wir jetzt stoßen, ist, dass die von diesen vier Terminals benötigten Schnittstellen unverständlich sind. Auch wenn die Schnittstellen gleich sind, sind die Datenstrukturen oder Felder unterschiedlich. Unser aktueller Ansatz besteht darin, das MVC-Modell auf der Serverseite sowie eine Bibliothek zu verwenden. Für die Schnittstelle rufen wir einfach die Klassen und Methoden in der Bibliothek auf. Für den PC haben wir eine einfache Bezeichnung implementiert Eigentlich indirekter Zugriff. Wenn ich beispielsweise die Benutzerliste abrufen möchte, sieht das im Controller, der die Heimatadresse bereitstellt, so aus:

<code>// .....
$userList = User::getList()
return $this->success($userList);</code>

Dann schreiben Sie auf der PC-Seite Folgendes auf die Vorlage:

<code>{{ userlist = Tag_User_getList() }}
// ....</code>

Grundsätzlich handelt es sich um eine solche Struktur, die jedoch viele Nachteile mit sich bringt. Beispielsweise ist es nicht möglich, die PC-Seite von der mobilen Seite zu trennen. Zweitens werden die von der mobilen Seite benötigten Daten nicht unbedingt benötigt PC-seitig und umgekehrt. Möglicherweise werden dadurch einige ungenutzte Daten usw. gelesen.
Dann würde ich gerne fragen, wie sie dieses Problem in einigen großen Projekten lösen? Zum Beispiel Taobao, JD.com usw.

Sie sagen, dass Sie keine Ahnung haben, was mit Ihrer Website los ist? Es scheint, dass 4 Websites zusammengedrängt werden. Da jede ihre eigene Schnittstelle hat, warum sollten wir die Schnittstelle vereinheitlichen? Wenn die aktuelle Datenkonsistenz erreicht ist, müssen Sie sich über das Schnittstellenproblem keine Sorgen machen, größere Änderungen sind nicht möglich. Es ist in Ordnung, unnötige Felder an der Schnittstelle herauszufiltern. Machen Sie nichts Tiefgreifenderes. Es ist bereits ein Chaos, und je mehr Sie es ändern, desto chaotischer wird es.

Ich persönlich bin der Meinung, dass die API-Schnittstelle beim Entwerfen so standardisiert wie möglich sein sollte ... ein Satz Schnittstellen, mehrere Aufrufe.