Ich benutze Rails seit über 4 Jahren, also mag ich Schienen und mag Dinge wie den Rails Way und manchmal stürze ich mich unwissentlich auf die dunkle Seite.
Ich habe vor kurzem Clean Code von Onkel Bob abgeholt. Ich bin in Kapitel 6 und ein wenig verwirrt, ob wir als Rails-Entwickler die fundamentale Regel des OO-Designs brechen, also Demeter-Gesetz oder Verkapselung? Das Demeter-Gesetz besagt, dass ein Objekt die Innereien eines anderen Objekts nicht kennen sollte und dass es Methoden für Objekte, die von einer Methode zurückgegeben werden, nicht aufrufen sollte, weil dann ein Objekt zu viel über das andere Objekt weiß. p>
Aber sehr oft rufen wir Methoden von einem anderen Objekt auf. Zum Beispiel, wenn wir eine Beziehung wie 'Eine Bestellung gehört einem Benutzer' haben. Dann tun wir sehr oft order.user.name oder um zu verhindern, dass es wie ein Zugunglück aussieht, richten wir einen Delegierten ein, um order.name auszuführen.
Ist das nicht immer noch so, als würde man das Demeter-Gesetz oder die Kapselung brechen?
Die andere Frage ist: Ist ActiveRecord nur eine Datenstruktur oder ein Datenübertragungsobjekt, das mit der Datenbank verbunden ist?
Wenn ja, erstellen wir dann keine Hybridstruktur, d. h. ein halbes Objekt und eine halbe Datenstruktur, indem wir unsere Geschäftsregeln in ActiveRecord Models einfügen?
Schienen sind Schienen. Was gibt es sonst noch zu sagen? Ja, einige der Idiome in Rails verletzen gute Designprinzipien. Aber wir tolerieren das, weil es der Weg von Rails ist.
Nachdem das gesagt wurde, gibt es in den meisten Rails-Anwendungen viel zu viel Modellverwendung. Viel zu oft sehe ich View-Code direkt auf Modelle zugreifen. Ich sehe Geschäftsregeln in das aktive Datensatzobjekt gefaltet. Ein besserer Ansatz wäre, die Geschäftsregeln von den aktiven Datensätzen zu isolieren und die Datenansichten von den Modellen zu isolieren. Dies würde keine Rails-Idiome verletzen und Rails-Anwendungen viel flexibler und wartbarer machen.
Wenn Sie dem puristischen Ansatz zu sehr folgen, enden Sie in einem Durcheinander wie Java, wo es die richtigen Designmuster verwendet, aber niemand kann sich an die acht Codezeilen erinnern, die Sie brauchen, um eine Datei zu öffnen und zu lesen Inhalt.
Das ActiveRecord-Framework von Rails ist eine Implementierung von Martin Fowlers Active Record-Entwurfsmuster . Active Records in Rails sind sicherlich nicht nur dumme Datenstrukturen oder DTOs, weil sie Verhalten haben: Sie führen eine Validierung durch, sie können Ihnen sagen, ob sich ihre Attribute geändert haben usw. und Sie sind frei und in der Tat ermutigt , deine eigene Geschäftslogik darin einzufügen.
Schienen im Allgemeinen fördert gute Praxis, z. MVC und syntaktischer Essig machen schlechte Dinge schwierig und / oder hässlich.
Ja, ActiveRecord bricht die Kapselung absichtlich ab. Dies ist weniger eine Einschränkung von Rails als vielmehr eine Einschränkung des zugrunde liegenden Schemas. Martin Fowler, dessen Definition von ActiveRecord so ziemlich das von Rails verwendete Template war, sagt das auch im ActiveRecord-Kapitel von POEAA :
Ein weiteres Argument gegen Aktiv Record ist die Tatsache, dass es koppelt das Objektdesign für die Datenbank Design. Dies macht es schwieriger Design entweder als Projekt umgestalten geht weiter.
Dies ist ein allgemeiner Kritik von Rails von anderen Frameworks. Fowler selbst sagt, dass ActiveRecord hauptsächlich verwendet werden soll
... für Domain-Logik, die nicht zu komplex ... wenn Ihre Geschäftslogik ist komplex, Sie werden bald Ihre verwenden wollen direkte Beziehungen des Objekts, Sammlungen, Vererbung und so weiter. Diese werden nicht leicht auf Active Record abgebildet.
Fowler sagt weiter, dass für ernstere Anwendungen mit komplexer Domänenlogik das Data-Mapper-Muster besser ist Job der Trennung der Schichten, ist vorzuziehen. Dies ist einer der Gründe, warum Rails kommenden Umzug nach Merb wurde allgemein als positiver Zug für Rails gesehen, da Merb zusätzlich zu ActiveRecord das DataMapper-Muster verwendet.
Ich bin nicht sicher, Demeter ist die Hauptsorge mit ActiveRecord. Ich glaube eher, dass das Aufbrechen der Kapselung zwischen den Daten- und Domain-Ebenen das Prinzip der einheitlichen Verantwortung von Onkel Bob vereinfacht. Demeter denke ich ist eher ein konkretes Beispiel dafür, wie man dem Open / Closed Prinzip folgt. Aber ich denke, die allgemeine Idee hinter all diesen Dingen ist die gleiche: Klassen sollten eine Sache tun und gegenüber zukünftigen Veränderungen robust sein, was ActiveRecord zu einem gewissen Grad nicht tut.
Was das "Gesetz der Demeter" betrifft, ist das Konzept der Entfernung eine Sache, die ich nicht erwähnt habe. Damit meine ich: "Wie eng ist das Objekt beteiligt?" Es ist meiner Meinung nach, dass dies einen Unterschied machen würde, ob ich dem "Demeter-Gesetz" folgen möchte oder nicht.
Bei ActiveRecord sind die Objekte, die an den meisten LoD-Verletzungen beteiligt sind, untrennbar zu einer engen Beziehung verbunden. Das Ändern der internen Datenstruktur dieser Objekte erfordert eine Änderung in der Datenbank, um diese neue Struktur widerzuspiegeln. Die Tabellen einer Datenbank sind typischerweise zu einer einzigen Datenbank "verbunden", die sogar diese "Assoziationen" durch Fremdschlüsselbeschränkungen (oder zumindest Primär- und Fremdschlüssel) wiedergibt.
Also beschäftige ich mich im Allgemeinen nicht mit der Verfolgung von LoD zwischen meinen AR-Objekten. Ich weiß, dass sie aufgrund ihrer Natur eng miteinander verbunden sind.
Auf der anderen Seite würde ich mich mehr um LoD zwischen entfernteren Objekten sorgen, besonders solche, die MVC-Grenzen überschreiten, oder irgendein anderes Design-Gerät.
Tags und Links ruby ruby-on-rails activerecord oop