Jeder Hype ist sehr lustig, wenn man ihn von der Seite betrachtet. Weniger lustig, wenn Sie sich direkt darauf einlassen.
Hype Go fiel irgendwo im Jahr 2014, als die Autoren von Anwendungen mit 1000 U / min (Anfragen pro Minute) plötzlich entschieden, dass sie dringend Parallelität benötigen, weil ihre 1000 U / min in 1000 U / min umgewandelt werden sollten (was auch nicht so viel ist). tatsächlich).
Das Ergebnis des Hype war, dass sich viele Leute, die sich an die MVC-Architektur der Anwendung gewöhnt hatten, dem Go anschlossen, sei es Spring, Django oder Ruby on Rails. Und diese Architektur, wie eine Eule auf einem Globus, begann sie auf Go zu ziehen. So erschienen Kader wie Beego und
Revel . Revel ist sicher gestorben, obwohl sie immer noch versuchen, es abzupumpen. Aber ich möchte separat über Beego sprechen.
Richard Eng hat mit seiner Artikelserie
„A word the Beegoist“ einen wesentlichen Beitrag zur Förderung von Beego in der Masse
geleistet . Praktisch das "Evangelium von Richard". Ironischerweise schreibt Richard selbst nicht darüber, obwohl er Go fieberhaft fördert.
Im Gegenzug habe ich mit Go gearbeitet, und noch schlimmer, mit Beego habe ich viel gearbeitet. Und ich kann sagen, dass dies eindeutig nicht der Weg ist, den die Entwicklung auf Go gehen sollte.
Schauen wir uns einige grundlegende Aspekte von Beego an und warum sie verschiedenen Best Practices in Go und in der gesamten Branche widersprechen.
Ordnerstruktur
Robert C. Martin, besser bekannt als
Onkel Bob , hat wiederholt die Idee geäußert, dass die Struktur einer Anwendung ihre Essenz vermitteln sollte. Er gibt sehr gerne ein Beispiel mit einer Kathedrale, die von oben betrachtet werden kann, und versteht sofort, dass dies eine Kathedrale ist.
Robert hat Ruby on Rails wiederholt wegen seiner Ordnerstruktur kritisiert - Controller, Modelle, Ansichten, das ist alles. Das Problem bei diesem Ansatz ist, dass die meistverkaufte Socken-App genau wie eine App zum Bestellen von Lebensmitteln aussieht. Und um die Essenz der Anwendung zu verstehen, müssen Sie in einen Modellordner klettern und sehen, mit welchen Entitäten wir am Ende fertig sind.
Es ist dieses kranke Beego-Verhalten, das sich wiederholt. Während sich derselbe Frühling dem domänengesteuerten Design und der Essenz der Ordnerstruktur zugewandt hat, schreibt Beego die Verwendung einer Struktur vor, die bereits zu einem Antimuster geworden ist.
Das Problem ist jedoch noch schwerwiegender. Für Go gibt es keine Trennung zwischen der Ordnerstruktur und der Paketstruktur. Daher werden in Beego und UsersController und OrdersController unter einem Paket - Controller - zusammengefasst. Und wenn Sie zwei Arten von Controllern haben, diejenigen, die der Benutzeroberfläche dienen, und diejenigen, die für die API verwendet werden, ist es außerdem üblich, letztere in einer anständigen Gesellschaft zu versionieren? Dann mach dich bereit für Freaks wie apiv1.
ORM
Seltsamerweise verwendet Beego, ein erfolgloser Ruby on Rails-Klon, das ActiveRecord-Muster nicht. Sein ORM ist ein äußerst seltsamer Anblick. Wenn es für vollständig grundlegende Vorgänge wie das Lesen einer Zeile / das Schreiben einer Zeile immer noch geeignet ist, sieht es beispielsweise wie ein einfaches Beispiel aus (im Folgenden werden Beispiele direkt aus der Dokumentation entnommen):
qs.Filter("profile__age__gte", 18)
Das Hauptproblem bei Beego ORM ist jedoch nicht einmal, dass Sie sich mit der proprietären Sprache befassen müssen, sondern dass die schlechtesten Go-Praktiken verwendet werden, unabhängig davon, ob es sich um Import-Nebeneffekte handelt:
import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" )
Oder Modelle in init () registrieren:
func init(){ orm.RegisterModel(new(User)) }
Tun Sie sich selbst einen Gefallen, auch wenn Sie sich aus unerklärlichen Gründen für die Arbeit mit Beego entscheiden, verwenden Sie Beego ORM nicht. Wenn Ihr Leben ohne ORM nicht schön ist (und was machen Sie in der Welt von Go, Liebes?), Verwenden Sie
GORM . Es wird zumindest unterstützt. Andernfalls hilft Ihnen
"database / sql" .
Bienenwerkzeug
Das Befehlszeilentool, das einfach
Bee heißt, wird von Ruby on Rails kopiert. Aber nur wenn es in der Welt von RoR Schienen und Rechen gab, dann ist Biene so ein Müll für alles. Er und die MVC-Anwendung für 'boostrap' und führen die Migration aus, und File Watcher wird gestartet. Letzteres ist ein weiteres Problem. Was ist schließlich einer der Hauptvorteile von Go? Was lokal beginnt, ist so nah wie möglich an dem, was in der Produktion beginnt. Wenn Sie keine Biene verwenden, natürlich.
Automatisches Routing
Go ist eine stark typisierte Sprache, die weder Generika noch Anmerkungen unterstützt. Wie kann man ein MVC-Framework darauf aufbauen? Natürlich durch Lesen von Kommentaren und Generieren von Dateien.
Es sieht ungefähr so aus:
Der Beweis ist, wie Sie sehen können, Null. Die Post () -Funktion empfängt oder gibt überhaupt nichts zurück. http.Request? Nein, nicht gehört.
Wie funktioniert das gesamte Routing? Wenn Sie die berüchtigte Biene starten, wird eine weitere Datei generiert, KommentareRouter_controllers.go, die ein Beispiel für solch wunderbaren Code enthält:
func init() { beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"] = append(beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"], beego.ControllerComments{ Method: "Post", Router: `/`, AllowHTTPMethods: []string{"post"}, MethodParams: param.Make(), Filters: nil, Params: nil}) ... }
Vergessen Sie nicht, diese Datei nach jeder Änderung neu zu generieren und festzuschreiben. Bis vor kurzem war die Situation noch trauriger, und während der Tests wurde diese Datei automatisch generiert, sodass Sie bereits über die Probleme in der Produktion informiert waren. Es scheint, dass in neueren Versionen dieses seltsame Verhalten behoben wurde.
Komponententest
Und so kommen wir zum Thema Testen. Go wird im Gegensatz zu den meisten anderen Programmiersprachen mit einem sofort einsatzbereiten Testframework geliefert. Im Allgemeinen lautet die Philosophie von Go, dass sich der Test neben der Testdatei befindet. Aber wir sind in der MVC-Welt, spucken auf die Go-Philosophie, oder? Bitte seien Sie daher freundlich, alle Ihre Tests in den / test-Daddy zu legen, wie
DHH uns hinterlassen hat.
Und das ist keine Kleinigkeit, denn ich erinnere mich, dass ich mich im Ordner Go package == befinde. Und wenn der Test im selben Paket die private Methode aufrufen kann, ist der Test in einem anderen Paket nicht mehr vorhanden.
Aber okay, alles wäre auf die Ordnerstruktur beschränkt. Beego-Code ist im Prinzip sehr schwer zu testen, da alles darin ein Nebeneffekt ist.
So fragt Beego Router ab:
import ( _ "github.com/../../routers" )
Die gleiche Geschichte mit Middleware und mit Controllern, die ich zuvor erwähnt habe.
Die Dokumentation
Es ist wie ein Software-Architekt für mich auf einem Kuchen. Die BeeGo-Dokumentation ist so gut wie Ihr Chinesisch. Nein, die Kommentare auf Chinesisch im Code der letzten zwei Jahre wurden irgendwie beseitigt.
Jetzt gibt es auf Chinesisch nur noch wenige Pull-Anfragen:
Und vor allem in Fragen:
Anstelle einer Schlussfolgerung
Wenn Sie ein Team von Ruby / PHP / Python-Code-Autoren haben und diese dringend in Go übersetzen möchten, können Sie sie am schlechtesten dazu bringen, auf Go zum MVC-Framework zu wechseln. MVC als Ganzes ist ein mittelmäßiges Architekturmuster, und in Go ist es im Allgemeinen fehl am Platz. Oder wenn Sie absolut sicher sind, dass nichts als Go Sie retten wird, lassen Sie sie neu lernen und so schreiben, wie es in Go akzeptiert wird - so flach und explizit wie möglich. Oder wissen sie vielleicht besser, mit welchem Werkzeug sie ihre Aufgaben lösen können?