Web框架的限制

Question

這是關於如何限制Web開發框架（如Django和ruby-on-rails）的一般性問題。

我打算構建一個REST風格的Web服務，它將有一個純粹的JSON/XML接口，沒有GUI。該服務將依賴數據庫，但是對於一些更重要的操作，沒有明確的方式將「模型」對象直接保存到數據庫表中。另外，我需要完全控制數據寫入數據庫的時間和方式。我將需要維護多個數據庫連接，以便僅將一些連接用於讀取，而將其他連接用於寫入。

我看過「完整的」MVC框架，如Django和更基本的這樣的web.py和塔。我現在的印象是，如果我最初使用完整的框架，事情會變得更快，但最終我會陷入困境，因爲我將受到我所能做的框架的限制。如果我使用更基本的框架，將需要更長的時間才能使所有內容都能正常運行，但我可以自由地做我需要的。

這是看起來像，但我懷疑這可能是一個不正確的印象，因爲有多少網站是用Django和Rails編寫的。你能否提出你的意見？我完全錯了，有一種方法可以輕鬆完成像Django或Rails這樣的框架，或者根據我的要求，我應該使用類似web.py的東西？

謝謝！

Answer 1

Web框架往往圍繞網站建設優化，使得大多數正常使用情況下，更簡單的實現。一旦你開始在框架中做更多的「開箱即用」的東西，你可能會發現你花更多的時間去解決它，那麼你首先會節省使用它。

很難一概而論這裏（尤其是因爲我真的只有深入Django的了），所以我會使用基於我自己的經驗開發一個JSON API提供一些建議Django的：

簡單的放，我不推薦使用Django來編寫REST API。以我自己的經驗，我真的沒有發現任何值得寫作的東西。我不需要Django的模板系統，所以我真正使用的是URL調度和ORM。即使如此，我還得做一些攻擊來讓URL調度器做我想做的事情 - 如果我沒有使用其他功能，事實上它會更快地使用不同的URL系統。在你的情況下，Django的ORM甚至不適合，因爲它不支持多個數據庫（除非你使用1.2 alphas ...）。由於Django缺乏良好的啓動信號，Django開始看起來相當糟糕。如果我在你的鞋子裏，我會爲特定的庫做些什麼（ORM，WSGI等），然後使用它們，而不是試圖彎曲和敲擊Django，使其適合我的需求。

在一個完全不同的說明，你可能想看看Tornado作爲一個可能的HTTP前端。它既簡單又快捷。

Answer 2

與自己的能力相比，你會受到更多的限制，而不同的開發團隊正致力於大型項目的共享所有這些共同部分。

Answer 3

整體而言，Rails與您所需要的一樣有幫助。如果您需要使用直接的SQL加載集合，那很簡單。如果你想在同一行中使用所有內置的ActiveRecord Fu，你可以。 REST風格的路由非常簡單，但如果REST特定的Rails風格不能滿足您的需求，則路由是完全可配置的。在Rails應用程序中，您可以根據需要使用盡可能多的或儘可能少的默認值，並且可以在所有級別重新配置。

Answer 4

即使您也使用框架，仍然可以充分利用所討論語言的潛力。框架並不是一個限制因素，它基本上是一種簡化應用程序某些部分開發的工具。例如，Django和rails抽象出一些數據庫功能，所以你只需要擔心你的模型對象。這並不意味着你不能自己做東西......

Answer 5

如果你不使用Rails的表示層，你會錯過很大一部分。將對象轉儲到json/xml所需的功能非常小，您可以從中獲得唯一的實際剩餘優勢，即ActiveRecord和路由，如果您無法想象您的數據乾淨地適合模型，那麼不會留下太多。

我認爲你真的只需要一個簡約的框架來照顧一些基礎知識。在請求/響應處理和路由方面爲您提供了一些細節，並且讓您不知所措。類似於Sinatra之類的Python可能會成爲你的衚衕。我在Scala中使用了一個名爲Step的類似框架，用於基於xml/json的web服務，我關心性能（並且沒有進行演示）。

我在瀏覽web.py，它似乎覆蓋了與Sinatra/Step類似的功能級別。我覺得這是比一些更完整的功能框架更合適的方向。我並沒有後悔我對Step的選擇，因爲代碼基本上非常小，不可能不瞭解它，如果有需要，可以輕鬆擴展。

Answer 6

我已經使用Ruby/Rails多年了，而且不像我用過的所有其他語言/框架（跨越了近15年的Java，PHP，ColdFusion，ASP等等），它都能夠避開你需要它。

這聽起來像你可能會從像西納特拉一個「更輕」框架中受益，但與即將發佈的Rails 3發佈的好處正變得越來越明顯。 Rails 3讓所有東西都可配置......事實上，Rails現在只是一組特殊的插件和擴展，它們都是一個無限靈活的核心。

我有興趣在此聲明：

「，該服務將依賴於數據庫但對於一些比較重要的操作 的有持久化的沒有明確的方式‘直接模式’對象成數據庫表「。

不知道你的意思是這個聲明......在某些時候你有東西進入數據庫，對吧？

在最不平凡的應用程序，你很少有單一的模式綁定到請求的結束...你實際上可能的是被退回或更新機型相當複雜的網絡。

如果您正在使用JSON的工作，我肯定會建議在尋找像的MongoDB數據庫。 MongoDB完全基於存儲JSON數據，因此可能會非常適合您的應用程序。

Answer 7

大多數Web站點將很適合像導軌或Django的豐富框架 - 但你正在構建一個網絡服務，並且具有非常不同的權衡。

就個人而言，我更喜歡使用非常光框架的Web服務，在Python，這意味着主要在WSGI依賴（這是一個標準，而不是框架），最小高度模塊化的組件，以提供一些小我可能需要的額外服務取決於服務的詳細信息（WSGI非常擅長允許模塊化的「中間件」組件）。

我個人最喜歡的模塊化WSGI組件的集合是Werkzeug，請求和響應對象的WebOb;如果我需要模板，那麼現在我傾向於使用Django Templates，如果我需要關係數據庫，我更喜歡直接編寫SQL（儘管SQLAlchemy有其優點！）。

但是，使用模塊化組件而不是集成框架很酷的事情是，您可以改變每一種選擇（並根據您的確切需要，偏好和品味隨意混搭） - ） 。

Answer 8

您已經寫下沒有要求，您已經寫下了技術決定。這完全不同。 你想實現什麼？那麼我們或許可以幫助你用如何來實現它們。

Answer 9

給一個嘗試到Spring 3.0：See this post

Answer 10

在平均水平，更完整的和有益的網絡框架，更多的限制是，當你試圖做的事情不是這樣的Web框架認爲是另一種方式正確的方式。一些網絡框架試圖提供非常有用的幫助，而不是限制性的，有些做得比其他更好。

而且一般建議有：不要打架。你會輸。所以選擇一個框架可以幫助你處理你想做的事情，但是不強制執行其他任何事情。對於你的web服務案例，這應該不成問題。至少在Python世界裏（這是我所關心的），有很多極簡主義的Web框架。 Bobo，BFG，Pylons，Werkzeug等等，這些都不會妨礙你一點。

另外不要忘記，你經常可以通過並排運行幾個框架。尤其是使用諸如敏捷/ XDV等技術。例如Plone.org主要是Plon（杜）一個優秀的內容管理系統，但是如果你想做其他事情，則會受到極大的限制。因此，該網站的一部分是Trac，這是卓越的Python錯誤跟蹤器。它們看起來都是一樣的。

Answer 11

如果您知道您不打算使用ORM或創建用戶界面，那麼您剛剛取消了首先使用Web應用程序框架的90％。例如，如果您查看Django的功能集，那麼您將使用哪些部分來實現Web服務，而您無法使用更簡單的Web服務，如Werkzeug或CherryPy？

構建Web服務和構建任何接受輸入併產生輸出的舊黑盒之間的主要區別在於，基於HTTP的API所帶來的各種技術限制，無狀態問題以及冪等問題。 Web應用程序框架將爲您提供一些幫助，但不是太多。