Dies ist eine allgemeine Frage zur Begrenzung von Web-Entwicklungs-Frameworks wie Django und Ruby-on-Rails.
Ich plane einen RESTful Web Service, der eine reine JSON / XML Schnittstelle, keine GUI hat. Der Dienst wird sich auf eine Datenbank stützen, jedoch gibt es für einige der wichtigeren Operationen keine klare Möglichkeit, ein "Modell" -Objekt direkt in einer Datenbanktabelle zu belassen. Außerdem benötige ich die volle Kontrolle darüber, wann und wie die Daten in die Datenbank geschrieben werden. Ich muss mehrere Datenbankverbindungen verwalten, um einige Verbindungen nur für Lesevorgänge und andere nur für Schreibvorgänge zu verwenden.
Ich habe mir die "vollständigen" MVC-Frameworks wie Django und einfachere wie web.py und Pylons angeschaut. Der Eindruck, den ich derzeit habe, ist, dass, wenn ich mit dem vollen Rahmen anfange, die Dinge schneller gehen werden, aber letztendlich werde ich stecken bleiben, weil ich durch den Rahmen in dem eingeschränkt werde, was ich tun kann. Wenn ich mit einem grundlegenderen Rahmen gehe, dauert es viel länger, um alles in Gang zu bringen, aber ich werde tun können, was ich brauche.
So sieht es aus, aber ich vermute, dass es ein falscher Eindruck ist, wenn man bedenkt, wie viele Seiten in Django und Rails geschrieben sind. Könnten Sie bitte Ihre Meinung mitteilen? Bin ich total falsch und es gibt einen Weg, einfach alles mit einem Framework wie Django oder Rails zu machen oder meinen Anforderungen zu entsprechen, sollte ich mit etwas wie web.py gehen?
Danke!
Web-Frameworks neigen dazu, das Erstellen von Websites zu optimieren, wodurch die meisten normalen Anwendungsfälle einfacher zu erreichen sind. Sobald Sie beginnen, mehr "out of the box" -Stücke mit einem Framework zu erstellen, werden Sie möglicherweise feststellen, dass Sie mehr Zeit damit verbringen, daran zu arbeiten, als Sie es von Anfang an speichern.
Hier ist es schwer zu verallgemeinern (vor allem da ich wirklich nur intensiv mit Django gearbeitet habe), deshalb werde ich einige Tipps geben, basierend auf meinen eigenen Erfahrungen bei der Entwicklung einer JSON API mit Django:
Einfach gesagt, ich empfehle nicht, Django zu verwenden, um eine REST-API zu schreiben. Nach meiner eigenen Erfahrung habe ich wirklich nichts gefunden, worüber ich nach Hause schreiben könnte. Ich brauchte Djangos Template-System nicht, also nutzte ich nur die URL-Verteilung und ORM. Selbst dann musste ich ein paar Hacks machen, um den URL-Dispatcher dazu zu bringen, das zu tun, was ich wollte - wenn ich keine anderen Features verwendet hätte, wäre es tatsächlich schneller gewesen, ein anderes URL-System zu verwenden. In Ihrem Fall wäre Djangos ORM nicht einmal geeignet, da es nicht mehrere Datenbanken unterstützt (außer Sie verwenden 1.2 Alphas ...). Verbinde das mit Djangos Fehlen eines guten Startsignals, und Django sieht für den Job ziemlich schlecht aus.
Wenn ich in Ihren Schuhen wäre, würde ich mich nach bestimmten Bibliotheken umsehen, die das getan haben, was ich brauchte (ORM, WSGI usw.) und sie einfach benutzen, anstatt zu versuchen, Django in etwas zu verbiegen, das meinen Bedürfnissen entspricht.
Ganz anders könnte es sein, dass Sie Tornado als mögliches HTTP-Frontend betrachten möchten. Es ist einfach und schnell.
Die meisten web Websites eignen sich gut für Rich Frameworks wie Rails oder Django - aber Sie bauen einen Webservice auf, der sehr unterschiedliche Kompromisse bietet.
Persönlich bevorzuge ich sehr Light-Frameworks für Web-Services: In Python bedeutet dies, dass man sich primär auf WSGI
Meine persönliche Lieblingssammlung modularer WSGI-Komponenten ist Werkzeug , mit WebOb für Anfrage- und Antwortobjekte; Wenn ich heute Vorlagen brauche, tendiere ich dazu, Django Templates zu verwenden, und wenn ich eine relationale DB brauche Ich ziehe es vor, SQL direkt zu schreiben (obwohl SQLAlchemy seine Stärken hat! -).
Aber die coole Sache über die Verwendung von modularen Komponenten anstelle von integrierten Frameworks ist, dass Sie jede einzelne dieser Optionen ändern können (und Mix-and-Match je nach Ihren genauen Bedürfnissen, Vorlieben und Geschmack! -).
Sie können immer noch das volle Potenzial der betreffenden Sprache nutzen, auch wenn Sie auch ein Framework verwenden. Ein Framework ist kein einschränkender Faktor, es ist im Grunde ein Werkzeug, um die Entwicklung bestimmter Teile Ihrer Anwendung zu erleichtern. Django und Rails beispielsweise abstrahieren einige Datenbankfunktionen, sodass Sie sich nur um Ihre Modellobjekte kümmern müssen. Das bedeutet nicht, dass du auch nicht selbstständig Sachen machen kannst ...
Im Durchschnitt gilt, je vollständiger und hilfreicher das Web-Framework ist, desto beschränkter ist es, wenn Sie versuchen, die Dinge anders zu machen als die Art, wie das Web-Framework denkt, dass es der richtige Weg ist. Einige Web-Frameworks versuchen, sehr hilfreich und immer noch nicht restriktiv zu sein, und manche tun das besser als andere.
Und die allgemeine Empfehlung lautet: Kämpfe nicht gegen den Rahmen. Du wirst verlieren. Daher ist es wichtig, ein Framework zu wählen, das Ihnen bei den Dingen hilft, die Sie tun möchten, aber nichts anderes erzwingt. Für Ihren Webservice-Fall sollte dies kein Problem darstellen. Es gibt eine Menge minimalistischer Web-Frameworks, zumindest in der Python-Welt (was mir wichtig ist). Bobo, BFG, Pylone, Werkzeug, etc, etc. Keines davon wird dir ein bisschen in die Quere kommen.
Vergessen Sie auch nicht, dass Sie oft mehrere Frameworks zusammen verwenden können, indem Sie sie nebeneinander laufen lassen. Vor allem mit Techniken wie Dexterity / XDV. Plone.org zum Beispiel ist hauptsächlich Plon (duh) ein exzellentes Content-Management-System, aber extrem restriktiv, wenn Sie etwas anderes machen wollen. Ein Teil der Seite ist Trac, der ausgezeichnete Python Bug Tracker. Es ist alles integriert, um gleich auszusehen.
Rails ist so hilfreich oder nicht so, wie Sie es brauchen, insgesamt. Wenn Sie eine Sammlung mit SQL-Anweisungen laden müssen, ist dies einfach. Wenn Sie in der gleichen Zeile alle integrierten ActiveRecord Fu verwenden möchten, können Sie. RESTful-Routing ist sehr einfach, aber wenn das spezielle Rails-REST-Profil nicht Ihren Anforderungen entspricht, ist das Routing vollständig konfigurierbar. In einer Rails-App können Sie so viele oder so wenig Standardeinstellungen verwenden, wie Sie benötigen, und die Neukonfiguration ist auf allen Ebenen verfügbar.
Wenn Sie nicht die Präsentationsschicht von Rails verwenden, verpassen Sie einen großen Teil davon. Die Funktionalität, die benötigt wird, um Objekte nach json / xml zu dumpen, ist so klein, dass nur ActiveRecord und Routing die Vorteile sind. Wenn Sie sich nicht vorstellen können, dass Ihre Daten ein Modell sauber anpassen, bleibt nicht viel übrig .
Ich denke, dass Sie wirklich nur einen minimalistischen Rahmen brauchen, um einige der Grundlagen zu pflegen. Etwas, das Ihnen beim Request / Response-Handling und -Routing einige Feinheiten bietet und Ihnen den Weg aus dem Weg räumt. Das Python-Äquivalent von etwas wie Sinatra könnte dir in die Quere kommen. Ich benutze einen ähnlichen Rahmen in Scala namens Schritt für xml / json-basierte Webservices, wo mir die Leistung wichtig ist (und es gibt keine Präsentation) .
Ich schaue auf web.py, es scheint eine ähnliche Funktionalität wie Sinatra / Step zu bieten. Ich denke, das ist eine geeignetere Richtung als einige der Frameworks mit mehr Funktionen. Ich habe meine Wahl von Step nicht bedauert, die Codebase ist so komisch klein, dass es unmöglich ist, sie nicht zu verstehen, und das macht es leicht, sie leicht zu erweitern, wenn Sie es brauchen.
Ich habe Ruby / Rails seit Jahren benutzt, und im Gegensatz zu fast jeder anderen Sprache / Framework, die ich verwendet habe (über fast 15 Jahre Java, PHP, ColdFusion, ASP usw.), kommt es bei Ihnen nicht aus dem Weg brauche es dazu.
Es klingt, als ob Sie von einem "leichteren" Framework wie Sinatra profitieren könnten, aber mit der bevorstehenden Veröffentlichung von Rails 3 werden die Vorteile weniger ausgeprägt. Rails 3 macht alles konfigurierbar ... in der Tat wird Rails jetzt nur ein bestimmter Satz von Plugins und Erweiterungen sein, die auf einem unendlich flexiblen Kern sitzen.
Ich bin an dieser Aussage interessiert:
"Der Dienst wird jedoch für einige der wichtigeren Vorgänge auf eine Datenbank angewiesen sein Es gibt keine klare Möglichkeit, ein "Modell" -Objekt direkt in einer Datenbanktabelle zu speichern. "
Nicht sicher, was Sie mit dieser Aussage meinen ... Irgendwann ist etwas in der Datenbank, oder?
In den meisten nicht-trivialen Anwendungen haben Sie selten ein einzelnes Modell, das an das Ende einer Anfrage gebunden ist ... Sie könnten tatsächlich ein ziemlich komplexes Netzwerk von Modellen haben, die zurückgegeben oder aktualisiert werden.
Wenn Sie mit JSON arbeiten, würde ich Ihnen definitiv eine Datenbank wie MongoDB empfehlen. MongoDB basiert ausschließlich auf der Speicherung von JSON-Daten und passt daher möglicherweise sehr gut zu Ihrer Anwendung.
Sie haben keine Anforderungen notiert , Sie haben Technologieentscheidungen niedergeschrieben. Das ist etwas ganz anderes. Was möchten Sie erreichen? Dann können wir Ihnen vielleicht mit wie helfen, sie zu erreichen.
Wenn Sie wissen, dass Sie kein ORM verwenden oder eine Benutzerschnittstelle erstellen möchten, haben Sie nur etwa 90% von dem entfernt, wofür Sie ein Webanwendungsframework überhaupt verwenden würden. Wenn Sie sich beispielsweise den Funktionsumfang von Django anschauen, welchen Teil davon würden Sie verwenden, um einen Web-Service zu implementieren, den Sie nicht mit etwas viel Einfachem wie Werkzeug oder CherryPy erhalten konnten?
Die Hauptunterschiede zwischen dem Erstellen eines Webdienstes und dem Erstellen einer alten Blackbox, die Input und Output benötigt, sind die verschiedenen technischen Beschränkungen, die durch die HTTP-basierte API auferlegt werden, das Problem der Staatenlosigkeit und das Problem der Idempotenz. Ein Webanwendungs-Framework wird Ihnen bei diesen Problemen ein wenig helfen, aber nicht viel.
Sie werden viel mehr von Ihren Fähigkeiten eingeschränkt sein als von einer heterogenen Gemeinschaft von Entwicklern, die an einem großen Projekt arbeiten, um all diese gemeinsamen Teile zu teilen.
Tags und Links python django ruby-on-rails rest