Ich bin seit letztem Jahr an Startups beteiligt und entwickle mit dem Python-Framework Django. Fast fünf Jahre lang gab es eine Entwicklungslücke, daher entschied ich mich optimistisch zu sein: "Ist das die Entwicklung von heute?" Es war jedoch voll von verschiedenen Anti-Mustern und Tauchpunkten.
Die frühere ehemalige verantwortliche Person und die vorherige verantwortliche Person haben angehalten, und der Anhang wurde umgedreht. Wenn ich mir den verbleibenden Code ansehe, kann ich nicht anders, als darüber nachzudenken.
Unter solchen Umständen möchte ich die Geschichte des Refactorings und die Geschichte des Refactorings von nun an zusammenfassen.
Es scheint, als würde es nicht aufhören, wenn ich anfange zu reden, aber es gab zwei enttäuschende Dinge in Bezug auf die Architektur.
Es scheint eine einfache App zu sein, bei der die Ansicht nur die Daten abruft, die ursprünglich durch Stapelverarbeitung erstellt wurden. Mit dem Hinzufügen von Funktionen werden jetzt jedoch verschiedene Berechnungen in der Ansicht durchgeführt.
Es scheint, dass die vorherige Person versucht hat, etwas zu tun, aber die Logik blieb in der Ansicht, und das Modell hatte Logik. Sie können Zirkelverweise in zwei verschiedenen Paketen erstellen. Ich habe die Operation nicht bestätigt. Es war schrecklich.
Ich habe die Tatsache beiseite gelegt, dass ich nicht genug Zeit hatte, ~~ die verantwortliche Person war dumm ~~, und es hängt von der Situation und den Menschen ab.
Zunächst nimmt Django eine einfache Konfiguration mit einer 1: 1-Tabelle und einem Modell an. Es ist ein bisschen von der ursprünglichen Bedeutung entfernt, aber es ist wahrscheinlich das Active Record-Muster.
Diese Konfiguration wird problematisch, wenn die App komplexer wird.
Wenn die Funktionalität komplexer wird, ändert sich die Tabelle. Es stimmt möglicherweise nicht mit dem ursprünglich erwarteten Modell überein.
Mit Django rufen Sie das Modell in der Regel direkt aus der Ansicht auf.
Wenn Sie Informationen aus mehreren Tabellen kombinieren, schreiben Sie in der Regel Logik in die Ansicht. Wenn Sie komplizierte Berechnungen durchführen, ist es schwierig zu verstehen, wo die Verantwortung liegt, und zu fragen: "Was? Ist dies das verantwortliche Modell?"
Model-View-Controller ist in erster Linie ein Präsentationsschichtmuster. Es scheint, dass das Modell mit dem Architekturmuster der Datenquelle gemischt ist, was verwirrend ist. (Ich glaube ich verstehe einfach nicht)
Ich ging zurück zu den Grundlagen und begann mit der Überlagerung. Zu dieser Zeit bezog ich mich auf das domänengesteuerte Design und das Muster der Unternehmensarchitektur (obwohl es einen schlechten Ruf hat).
Persönlich hatte ich den Inhalt des Unternehmensarchitekturmusters satt.
http://www.amazon.co.jp/dp/4798121967 http://www.amazon.co.jp/dp/4798105538
Es gibt einige Muster, aber es war leicht zu verstehen, wie man sie in 4 Schichten unterteilt.
Wiederum war es für Django persönlich verwirrend, dass das Modell der Präsentationsschicht, die Domänenschicht und die Datenschicht in einem waren. Es wurde ein Schlüssel, um diesen Bereich zu teilen.
Geändert, um einen Dienst für eine Ansicht bereitzustellen. Ich möchte nicht, dass die Methodenparameter kompliziert sind, also lasse ich sie die Datenübertragungsobjekt-ähnlichen Parameter verarbeiten.
Der Dienst ist auch in zwei Typen unterteilt.
Eine ist, grundlegende CRUD zu behandeln. Die Namenskonvention lautet auch XxxService.
Die andere besteht darin, mehrere Objekte zu kombinieren, um komplizierte Berechnungen und Verarbeitungen durchzuführen. Die Namenskonvention ist auch XxxEngine.
Ich habe es nicht gut verstanden, auch wenn ich verschiedene Erklärungen gelesen habe, also habe ich mich auf den folgenden Code bezogen. http://www.infoq.com/jp/news/2015/04/ddd-trading-example https://github.com/archfirst/bullsfirst-server-java
Es ist auch ineffizient, jedes Mal eine Instanz des Dienstes zu erstellen, also habe ich es zu Singleton gemacht.
http://code.activestate.com/recipes/579090-yet-another-singleton-pattern-in-python-using-clas/
Dies ist eine zukünftige Ausgabe.
Es gab einige ähnliche Dinge in XxxEngine. Dies ist ein Dunst, der Ihnen eine bessere Sicht gibt, wenn Sie ihn durch das Strategiemuster trennen.
Ich beschloss, Djangos Modell als Datenschicht zu betrachten.
In Zukunft denke ich darüber nach, eine Domänenschicht einzuführen. Implementieren Sie die Domänenlogik in einer Klasse, die vom Django-Modell erbt.
Früher wurde beim Konvertieren von einer Tabelle in ein Objekt POJO (Plain Old Java Object) zugeordnet. Um die Logik als Domänenmodell zu implementieren, wurde eine Klasse verwendet, die POJO geerbt hat. Mit dieser Referenz denke ich darüber nach, POMO (mein geprägtes Wort w: Plain Old Model Object) zu erben und es zu einem Domänenmodell zu machen.
Ich finde es immer noch subtil, aber die aktuelle Situation ist so.
Als ich die Geschichte der Einführung der Service-Schicht in Rails sah, dachte ich: "Es gibt Leute, die das Gleiche denken" und fasste zusammen, was ich in Django dachte / antwortete.
Was mich diesmal jedoch beunruhigte, war das Problem, über das im Muster der Unternehmensanwendung gesprochen wurde. Heutzutage gibt es viele Dinge, die das Framework verbirgt und nicht kennt. Aber als ich versuchte, die Grenzen des Frameworks zu erweitern, hielt ich es für wichtig, die Grundlagen zu kennen.
Recommended Posts