Насколько ограничены веб-фреймворки

Question

Это общий вопрос о том, насколько ограничены фреймворки веб-разработки, такие как Django и ruby-on-rails.

Я планирую создать веб-сервис RESTful, который будет иметь чисто JSON / XML-интерфейс, без графического интерфейса. Служба будет полагаться на базу данных, однако для некоторых из наиболее важных операций не существует четкого способа сохранения объекта «модели» непосредственно в таблице базы данных. Кроме того, мне требуется полный контроль над тем, когда и как данные записываются в базу данных. Мне нужно будет поддерживать несколько соединений с базой данных, чтобы использовать некоторые соединения только для чтения, а другие только для записи.

Я посмотрел на "полные" MVC-фреймворки, такие как Django, и более простые, такие как web.py и pylons. У меня сейчас сложилось впечатление, что если я пойду с полной структурой, сначала все пойдет быстрее, но со временем я застряну, потому что буду ограничен рамками в том, что я могу сделать. Если я перейду к более основному фреймворку, потребуется гораздо больше времени, чтобы все заработало, но я буду свободен делать то, что мне нужно.

Это то, на что это похоже, но я подозреваю, что это может быть неправильное впечатление, учитывая, сколько сайтов написано в Django и Rails. Не могли бы вы высказать свое мнение. Я абсолютно не прав, и есть способ легко сделать что-нибудь с фреймворком, таким как Django или Rails, или, учитывая мои требования, я должен пойти с чем-то вроде web.py?

Спасибо!

Answer 1

Веб-фреймворки, как правило, оптимизируются под создание веб-сайтов, что облегчает выполнение большинства обычных сценариев использования. Как только вы начнете делать больше "готовых" вещей с помощью фреймворка, вы можете обнаружить, что тратите больше времени на работу с ним, чем экономите, используя его в первую очередь.

Здесь сложно обобщить (тем более, что я действительно углубленно работал только с Django), поэтому я предложу несколько советов, основанных на моем собственном опыте разработки JSON API с использованием Django:

Проще говоря, я не рекомендую использовать Django для написания REST API. По своему опыту, я действительно не нашел ничего, о чем стоило бы написать домой. Мне не нужна была система шаблонов Django, поэтому все, что я действительно использовал, это диспетчеризация URL и ORM. Даже тогда мне пришлось сделать несколько хаков, чтобы заставить диспетчера URL делать то, что я хотел - если бы я не использовал другие функции, было бы на самом деле быстрее использовать другую систему URL. В вашем случае ORM Django даже не подходит, так как он не поддерживает несколько баз данных (если вы не используете 1.2 альфа-версии ...). В сочетании с отсутствием хорошего сигнала запуска у Django, Django начинает выглядеть довольно плохо для этой работы.

Если бы я был на вашем месте, я бы покопался в поисках конкретных библиотек, которые делали то, что мне было нужно (ORM, WSGI и т. Д.), И просто использовал бы их, вместо того, чтобы пытаться согнуть и вбить Django во что-то, что соответствует моим потребностям.

На совершенно другой ноте вы можете взглянуть на Tornado в качестве возможного HTTP-интерфейса. Это и просто, и быстро.

Answer 2

Большинство веб сайтов хорошо подойдут для богатых фреймворков, таких как Rails или Django, но вы создаете веб сервис , и у него очень разные компромиссы.

Лично я предпочитаю использовать очень легкие фреймворки для веб-сервисов: в Python это означает полагаться прежде всего на WSGI (который является стандартным, а не фреймворком), с минимум высокомодульных компонентов, чтобы обеспечить некоторые небольшие дополнительные возможности, которые могут мне понадобиться в зависимости от деталей служб (WSGI очень хорошо разрешает модульную композицию «промежуточных компонентов»).

Моя личная любимая коллекция модульных компонентов WSGI: Werkzeug , с WebOb для объектов запросов и ответов; в настоящее время, если мне нужны шаблоны, я склонен использовать шаблоны Django , а если мне нужна реляционная БД, я предпочитаю писать SQL напрямую (хотя SQLAlchemy имеет свои сильные стороны! - ).

Но самое интересное в использовании модульных компонентов, а не интегрированных каркасов, состоит в том, что вы можете изменять каждый из этих вариантов (и комбинировать и подбирать по желанию в зависимости от ваших конкретных потребностей, предпочтений и вкусов! -).

Answer 3

Вы все еще можете использовать весь потенциал рассматриваемого языка, даже если вы также используете платформу. Фреймворк не является ограничивающим фактором, это в основном инструмент, облегчающий разработку определенных частей вашего приложения. Например, Django и rails абстрагируют некоторые функциональные возможности базы данных, поэтому вам придется беспокоиться только об объектах вашей модели. Это не значит, что вы не можете делать что-то самостоятельно ...

Answer 4

В среднем, чем полнее и полезнее веб-фреймворк, тем больше он ограничивается, когда вы пытаетесь сделать что-то иначе, чем то, что веб-фреймворк считает правильным. Некоторые веб-фреймворки стараются быть очень полезными и все же не ограничивающими, а некоторые делают это лучше, чем другие.

И общая рекомендация: Не боритесь с фреймворком. Вы проиграете. Поэтому важно выбрать среду, которая поможет вам с тем, что вы хотите сделать, но не навязывает вам что-либо еще. Для вашего веб-сервиса это не должно быть проблемой. Существует множество минималистичных веб-фреймворков, по крайней мере, в мире Python (это все, что меня волнует). Бобо, BFG, Pylons, Werkzeug и т. Д., И т. Д. Ничто из этого не помешает вам.

Также не забывайте, что вы часто можете использовать несколько фреймворков, если они будут работать рядом. Особенно с использованием техник, таких как Ловкость / XDV. Например, Plone.org - это в основном Plon (отличная) отличная система управления контентом, но крайне ограниченная, если вы хотите заняться чем-то другим. Так что частью сайта является Trac, отличный трекер ошибок Python. Все интегрировано, чтобы выглядеть одинаково.

Answer 5

Если вы знаете, что не собираетесь использовать ORM или создавать пользовательский интерфейс, то вы просто исключили около 90% того, для чего в первую очередь вы хотели бы использовать среду веб-приложений. Например, если вы посмотрите на набор функций Django: какие его части вы бы использовали для реализации веб-службы, которую вы не смогли бы получить с помощью чего-то более простого, например Werkzeug или CherryPy?

Принципиальными различиями между созданием веб-службы и созданием любого старого черного ящика, который принимает входные данные и производит выходные данные, являются различные технические ограничения, накладываемые API на основе HTTP, проблема отсутствия состояния и проблема идемпотентности. Фреймворк веб-приложений поможет вам в этих вопросах, но не сильно.

Answer 6

Вы записали никаких требований , вы записали технологических решений . Это нечто совершенно другое. Чего вы хотите достичь? Тогда мы сможем помочь вам с как их достичь.

Answer 7

Я использую Ruby / Rails уже много лет, и в отличие от почти всех других языков / фреймворков, которые я использовал (в течение почти 15 лет Java, PHP, ColdFusion, ASP и т. Д. И т. Д.), Он исчезает, когда вы нужно это.

Похоже, что вы могли бы извлечь выгоду из "облегченного" фреймворка, такого как Sinatra, но с предстоящим выпуском Rails 3 преимущества станут менее заметными. Rails 3 делает все настраиваемым ... фактически, Rails теперь будет просто определенным набором плагинов и расширений, лежащих на бесконечно гибком ядре.

Меня интересует это утверждение:

"Служба будет полагаться на базу данных, однако для некоторых из наиболее важных операций не существует четкого способа сохранения объекта «модели» непосредственно в таблице базы данных. "

Не уверен, что вы подразумеваете под этим утверждением ... в какой-то момент вы что-то делаете в базе данных, верно?

В большинстве нетривиальных приложений вы редко привязываете одну модель к концу запроса ... у вас может быть довольно сложная сеть моделей, которые возвращаются или обновляются.

Если вы работаете с JSON, я бы определенно предложил взглянуть на базу данных, такую ​​как MongoDB. MongoDB полностью основан на хранении данных JSON и, следовательно, может очень хорошо соответствовать вашему приложению.

Answer 8

Если вы не используете уровень представления Rails, вы упускаете большую его часть.Функциональность, необходимая для выгрузки объектов в json / xml, настолько мала, что единственными реальными оставшимися преимуществами, которые вы могли бы извлечь из этого, были бы ActiveRecord и маршрутизация, и если вы не можете представить, что ваши данные точно соответствуют модели, то это не оставляет много.

Я думаю, вам действительно нужен минималистский фреймворк, чтобы позаботиться о некоторых основах.Что-то, что предоставляет вам некоторые тонкости в обработке запросов / ответов и маршрутизации и убирает с дороги.Эквивалент Python для чего-то вроде Sinatra может оказаться в вашем распоряжении.Я использую подобный фреймворк в Scala под названием Step для веб-сервисов на основе xml / json, где меня интересует производительность (и презентация не ведется).

Я смотрю на web.py,Похоже, что он покрывает уровень функциональности, аналогичный Sinatra / Step.Я чувствую, что это более подходящее направление, чем некоторые из более полнофункциональных фреймворков.Я не пожалел о своем выборе Step, кодовая база настолько комична, что ее невозможно не понять, и это облегчает ее легкое расширение, если в этом есть необходимость.

Answer 9

Rails полезен или не так, как вам нужно, в целом. Если вам нужно загрузить коллекцию прямым SQL, это просто. Если в одной строке вы хотите использовать все встроенные ActiveRecord Fu, вы можете. RESTful маршрутизация чрезвычайно проста, но, опять же, если конкретный вариант REST Rails не отвечает вашим потребностям, маршрутизация полностью настраивается. В приложении Rails вы можете использовать столько значений по умолчанию, сколько вам нужно, и реконфигурация доступна на всех уровнях.

Answer 10

Дайте попробовать Spring 3.0: Смотрите это сообщение