Comments 50
Только по тегам понял, на каком языке этот фреймворк (хоть и догадывался по названию, но указывать язык надо).
> основные идеи были взяты из Ruby On Rails и улучшены!
Неплохо бы раскрыть эту фразу детальней…
Неплохо бы раскрыть эту фразу детальней…
Цель статьи была не сравнить фреймворки. Для этого нужна отдельная статья которую планирую написать и сравню в ней Django, Pylons и RoR. На вскидку могу лишь заметить, что в Pylons нет соглашений, все указывается явно.
Взяли и выкинули основную идеологическую концепцию рельсов и утверждаете что это улучшение? :) Странно. Я бы сказал более нейтрально: «взяли основные идеи RoR и питонифицировали».
Конечно это моё личное мнение, основанное на любви к питону :) Но вообще SQLAlchemy мне больше нравится, чем ActiveRecord. Routes тоже чуть получше(работа с поддоменами). И шаблоны тоже… вообщем долгая история :)
Мне тоже кажется, что тут больше любви к питону как у меня больше к руби :)
Например, мне
понятнее, чем
С ассоциациями то же — belongs_to и has_many это просто супер: как читается, то и означает.
Найти бы кого-то непредвзятого… :)
Например, мне
User.find(:first, :conditions => {:name => «Маша'})
понятнее, чем
session.query(User).filter_by(name=u»Маша").first()
С ассоциациями то же — belongs_to и has_many это просто супер: как читается, то и означает.
Найти бы кого-то непредвзятого… :)
Ассоациации? Алхимия это сложная наука, по этому придумали Эликсир! Употребляешь и все становится проще :)
А толку-то с непредвзятого? Это ведь субъективная штука, непредвзятый станет предвзятым, как только ознакомится с обоими подходами :).
Разве что, ему может не понравится то, что в :conditions надо писать практически raw sql.
Разве что, ему может не понравится то, что в :conditions надо писать практически raw sql.
>понятнее, чем…
Тут соверешенно дело не в понятности. Первое паттерн собственно ActiveRecord, второе паттерн DataMapper + UnitOfWork (очень на жавский Hibernate похоже). Каждый из паттернов имеет свои плюсы и минусы, подробнее читайте у Фаулера.
Тут соверешенно дело не в понятности. Первое паттерн собственно ActiveRecord, второе паттерн DataMapper + UnitOfWork (очень на жавский Hibernate похоже). Каждый из паттернов имеет свои плюсы и минусы, подробнее читайте у Фаулера.
да, но в руби DataMapper тоже свой есть, тем не менее и он более удобочитаемый, чем
session.query(User).filter_by(name=u»Маша").first()zoo = Zoo.first(:name => 'Luke')Нет! Библиотека DataMapper реализует паттерн ActiveRecord, так же как и собственно ActiveRecord. Это путаница в названиях. В рубийном DataMapper есть одно важное отличие от ActiveRecord (библиотеки) — он использует еще и решение IdentityMap.
martinfowler.com/eaaCatalog/activeRecord.html
martinfowler.com/eaaCatalog/dataMapper.html
martinfowler.com/eaaCatalog/unitOfWork.html
martinfowler.com/eaaCatalog/identityMap.html
Если лень читать фаулера, то могу вкратце набросать: в паттерне activerecord модель знает о том как себя сохранять, а класс является еще и фабрикой своих экземпляров. Однако есть проблема — невозможно тестировать/использовать модель без бд, т.е. нету «Persistence Ignorance». Решение DataMapper позволяет обойти это ограничение, однако оно существенно сложнее. Так что дело совсем не в читаемости.
Мне самому больше нравится решение ActiveRecord, оно проще, а проблему с тестированием легко можно решить с фикстурами. Но для реализации сложно бизнес логики все же лучше реализации DataMapper, такие как алхимия или хибернейт.
martinfowler.com/eaaCatalog/activeRecord.html
martinfowler.com/eaaCatalog/dataMapper.html
martinfowler.com/eaaCatalog/unitOfWork.html
martinfowler.com/eaaCatalog/identityMap.html
Если лень читать фаулера, то могу вкратце набросать: в паттерне activerecord модель знает о том как себя сохранять, а класс является еще и фабрикой своих экземпляров. Однако есть проблема — невозможно тестировать/использовать модель без бд, т.е. нету «Persistence Ignorance». Решение DataMapper позволяет обойти это ограничение, однако оно существенно сложнее. Так что дело совсем не в читаемости.
Мне самому больше нравится решение ActiveRecord, оно проще, а проблему с тестированием легко можно решить с фикстурами. Но для реализации сложно бизнес логики все же лучше реализации DataMapper, такие как алхимия или хибернейт.
Фаулера читать не лень :), в заблуждения вводят названия фреймворков (например, когда-то я думал, что ActiveRecord — это чисто название фреймворка, а не название паттерна изначально).
Пока ехал в метро, понял что session — это и есть UnitOfWork, а заодно и закрались сомнения относительно рубишного ДатаМаппера.
Спасибо за короткий анализ, у Фаулера его нет.
Может знаете, есть ли на руби правильная реализация ДатаМаппера?
Пока ехал в метро, понял что session — это и есть UnitOfWork, а заодно и закрались сомнения относительно рубишного ДатаМаппера.
Спасибо за короткий анализ, у Фаулера его нет.
Может знаете, есть ли на руби правильная реализация ДатаМаппера?
Действительно, схожесть с RoR увидел только в роутах…
А сравните с ASP и c RoR, кто ближе?
ASP это вообще совсем «не то». ASP это компонетный statefull фреймворк, а всякие Pylons и RoR это request/response-based и stateless.
Вот! ASP это фреймворк для WEB и RoR для WEB. Если вы берете классификацию по назначению, то оба они попали в одну корзину, а VCL скажем в другую. Если вы классифицируете по стэйтлесс и стэйтфул. То группировка изменится. Состояние в Django есть — это сессия и много еще разных моментов. В ASP я писал наследника от HTTP кто, то там (не помню уже), потом в массиве хранил пути и обработчике путей. При этом конечно 90% ASP было выкинуто к чертям, но это был RoR (точнее Django стиль).
Возможно я коряво излагаю свою мысль, но Django, Pylons, TG это все близкие родственники RoR. В противоположность разным WSGI фреймворкам которые работают на более низком уровне (ДА Я ЗНАЮ, что Django WSGI, но до такого уровня обычно никто не опускается). В этих фреймворках можно создать роуты, а можно обойтись вообще без них.
Возможно я коряво излагаю свою мысль, но Django, Pylons, TG это все близкие родственники RoR. В противоположность разным WSGI фреймворкам которые работают на более низком уровне (ДА Я ЗНАЮ, что Django WSGI, но до такого уровня обычно никто не опускается). В этих фреймворках можно создать роуты, а можно обойтись вообще без них.
>Состояние в Django есть — это сессия и много еще разных моментов
Ну сессии как бы везде есть. Говоря stateless или statefull я конечно же имел ввиду принцип построения визуальных компонентов. Т.е. используют ли компоненты активно сессии или нет. Хотя мир не черно-белый и в RoR есть такая штука, как flash, некое подобие компоненты с состоянием…
Ну сессии как бы везде есть. Говоря stateless или statefull я конечно же имел ввиду принцип построения визуальных компонентов. Т.е. используют ли компоненты активно сессии или нет. Хотя мир не черно-белый и в RoR есть такая штука, как flash, некое подобие компоненты с состоянием…
Или с типичным PHP проектом, где роутами занимается апач, а весь код в шаблоне
Ещё WebHelpers утащили оттуда. И мне очень помогает библиотека Pytils, который подглядели у Rutils оттуда же :-)
Интересный фреймворк, периодически поглядываю на него, но есть пара проектов на django, а вот что-то написать с использованием pylons как-то руки не доходят…
Расскажите для тех, кто не на рельсах, что за маршруты и чем они хороши.
Способ описания связи урлов и «ушей» приложения. Помощней, чем джанговская url.py, т.к. можно управлять маршрутом в зависимости от метода запроса, например. + (если всё как в РоР) можно создавать REST-маршруты «в одну строчку». В кратце так, наверное.
Урл-маршрутизация — разбор адресов, по которым обращается клиент и в зависимоти от них выполнение различных контроллеров (суть функций).
Так, например, в моём приложении, набрав www.example.com/order/5 можно увидеть заявку №5, а на www.example.com/orders можно увидеть весь список заявок. А на www.example.com/order/5/edit у меня скрывается форма редактирования заяки. Ну и так далее :-)
И этим у меня заведуют следующие строчки в routing.py (первая — не в тему):
Так, например, в моём приложении, набрав www.example.com/order/5 можно увидеть заявку №5, а на www.example.com/orders можно увидеть весь список заявок. А на www.example.com/order/5/edit у меня скрывается форма редактирования заяки. Ну и так далее :-)
И этим у меня заведуют следующие строчки в routing.py (первая — не в тему):
map.connect ("startpage", "/", controller="main", action="index")
map.connect ("orderlist", "/orders", controller="order", action="list")
# Заявки
map.connect ("order", "/order/{id}", controller="order", action="view", requirements = {'id': '\d+'})
map.connect (None, "/order/{id}/{action}", controller="order", requirements = {'id': '\d+'})
Ах, как коротко-то…
Скажу я — фреймворк хорош. Вот только, в отличие от RoR (как я понял) — в полстрочки здесь ничего не пишется. Программисту под контроль изначально отдаётся больше вещей.
И модульность здесь поставили во главу угла изначально, поэтому начинка может отличаться и изменяться. С одной стороны хорошо, а с другой — не очень.
Для заинтересовавшихся есть руководство (на английском): Pylons Book. Там всё расписано (хотя часть информации уже могла устареть и устарела)
Замечание автору: в версии 1.0 фреймворка (а точнее в последней версии Routes) функцию url_for объявили устаревшей и выкинули к чертям. Следует использовать функцию url импортируемую из pylons. Синтаксис аналогичен, начинка и поведение — отличаются.
Скажу я — фреймворк хорош. Вот только, в отличие от RoR (как я понял) — в полстрочки здесь ничего не пишется. Программисту под контроль изначально отдаётся больше вещей.
И модульность здесь поставили во главу угла изначально, поэтому начинка может отличаться и изменяться. С одной стороны хорошо, а с другой — не очень.
Для заинтересовавшихся есть руководство (на английском): Pylons Book. Там всё расписано (хотя часть информации уже могла устареть и устарела)
Замечание автору: в версии 1.0 фреймворка (а точнее в последней версии Routes) функцию url_for объявили устаревшей и выкинули к чертям. Следует использовать функцию url импортируемую из pylons. Синтаксис аналогичен, начинка и поведение — отличаются.
использую этот фреймворк в нескольких своих проектах.
В отличии от django позволяет использовать какой угодно ORM, какой угодно template engine, чем меня и привлёк.
и актуальная документация на ближайший релиз 1.0 уже имеется
В отличии от django позволяет использовать какой угодно ORM, какой угодно template engine, чем меня и привлёк.
и актуальная документация на ближайший релиз 1.0 уже имеется
С каких это пор джанга запрещает использовать сторонний шаблонизатор и ОРМ?
Да собственно никто не запрещает, с шаблонами просто, а вот ORM… весь contrib идет лесом, хотя можно и одновременно использовать разные ORM. Вообще не суть, у Django просто философия другая. Хотя Pylons с FormAlchemy уже рядом моячет по функциональности.
может быть я отстал от жизни, но, насколько я помню, в джанге отвязать родной ORM и привязать SQLAlchemy было невыполнимой задачей. Неужели уже эта задача выполнима?
Еще как выполнима. Кто вам мешает вместо:
писать
?
Отвалятся контрибы многие, но они не есть часть джанги.
class Model(models.Model):
...blah...
писать
class Model(Base):
...blah...
?
Отвалятся контрибы многие, но они не есть часть джанги.
из того, что написано в pylonsbook, можно сделать вывод, что разница в использовании других компонентов в Django и в Pylons всё-таки есть:
Слабое связывание и чистое разделение
— Веб-фрэймворки, такие как Django и Ruby on Rails стали крайне популярными в последние годы, потому что они обеспечивают структуру, позволяющую быстро создавать хорошие веб-сайты, определяя, то как структурированы данные.
Предоставляемые инструменты работы с данными могут как автоматически создавать код (scaffold в случае Ruby on Rails), так и создавать интерфейсы форм при запуске (в случае с Django).
Хотя эти фрэймворки поддерживают чистое разделение между кодом моделей, видов и контроллеров, они не такие слабосвязанные как в Pylons, потому что работоспособность приложения как единого целого во многом полагается на соединяющий код, находящийся в фрэймворке. Легко создать простое приложение при помощи этих фрэймворков, но настройка их поведения позднее может быть сложной, потому что это предполагает понимание того, как работает код предоставляемый фрэймворком, перед тем как вы поменяете его поведение. Чтобы было проще использовать фрэймворк, его код часто достаточно сложен, и в результате настройка может быть трудной.
Pylons более слабосвязанный. Поскольку он не предоставляет инструментов для автоматической генерации почти законченного сайта из определения модели, ему не нужен сложный соединяющий код, удерживающий всё вместе. Вместо этого, он предоставляет низкоуровневые API и методологии, позволяющие быстро и просто соединить вместе компоненты, которые вы сами выбираете.
Такой подход к слабому связыванию не означает, что вам нужно создавать код для всех частей. В соглашении по конфигурации Pylons считается, что вы захотите использовать стандартные настройки при создании нового проекта. Их можно легко изменить. Например, по умолчанию Pylons использует фрэймворк для работы с шаблонами Mako для генерации шаблонов из видов, но вы не обязаны его использовать. Вы легко можете использовать любой из других крупных языков шаблонов Python, включая Genshi, Jinja или даже Tal или Breve.
Слабое связывание и чистое разделение
— Веб-фрэймворки, такие как Django и Ruby on Rails стали крайне популярными в последние годы, потому что они обеспечивают структуру, позволяющую быстро создавать хорошие веб-сайты, определяя, то как структурированы данные.
Предоставляемые инструменты работы с данными могут как автоматически создавать код (scaffold в случае Ruby on Rails), так и создавать интерфейсы форм при запуске (в случае с Django).
Хотя эти фрэймворки поддерживают чистое разделение между кодом моделей, видов и контроллеров, они не такие слабосвязанные как в Pylons, потому что работоспособность приложения как единого целого во многом полагается на соединяющий код, находящийся в фрэймворке. Легко создать простое приложение при помощи этих фрэймворков, но настройка их поведения позднее может быть сложной, потому что это предполагает понимание того, как работает код предоставляемый фрэймворком, перед тем как вы поменяете его поведение. Чтобы было проще использовать фрэймворк, его код часто достаточно сложен, и в результате настройка может быть трудной.
Pylons более слабосвязанный. Поскольку он не предоставляет инструментов для автоматической генерации почти законченного сайта из определения модели, ему не нужен сложный соединяющий код, удерживающий всё вместе. Вместо этого, он предоставляет низкоуровневые API и методологии, позволяющие быстро и просто соединить вместе компоненты, которые вы сами выбираете.
Такой подход к слабому связыванию не означает, что вам нужно создавать код для всех частей. В соглашении по конфигурации Pylons считается, что вы захотите использовать стандартные настройки при создании нового проекта. Их можно легко изменить. Например, по умолчанию Pylons использует фрэймворк для работы с шаблонами Mako для генерации шаблонов из видов, но вы не обязаны его использовать. Вы легко можете использовать любой из других крупных языков шаблонов Python, включая Genshi, Jinja или даже Tal или Breve.
Тогда можно и bottle.py использовать.
Для SQLAlchemy есть неплохая надстройка Elixir
в порядке информации к размышлению, а не приглашения к холивару.
имхо, pylons очень мощный и гибкий, но достаточно монстрообразный фреймворк, особенно для небольших проектов. и в этом смысле, напоминает symfony.
думаю, джанга в этом смысле предпочтительнее и даже быстрее.
кроме того, в pylons нельзя использовать raw sql запросы, что иногда создает большие трудности.
по крайней мере, не удалось быстро найти как их использовать.
имхо, pylons очень мощный и гибкий, но достаточно монстрообразный фреймворк, особенно для небольших проектов. и в этом смысле, напоминает symfony.
думаю, джанга в этом смысле предпочтительнее и даже быстрее.
кроме того, в pylons нельзя использовать raw sql запросы, что иногда создает большие трудности.
по крайней мере, не удалось быстро найти как их использовать.
в pylons нельзя использовать raw sql запросы, что иногда создает большие трудности.
а каким боком тут pylons? он не предоставляет DBLayer сам по себе. и вас никто не заставляет пользоваться SQLAlchemy, можно использовать и прямое подключение к БД
пример raw:
Но чаще такое не нужно, это все можно методами описать.
Подробнее про sqlexpression.
>>> from sqlalchemy.sql import text
>>> s = text("""SELECT users.fullname || ', ' || addresses.email_address AS title
... FROM users, addresses
... WHERE users.id = addresses.user_id AND users.name BETWEEN :x AND :y AND
... (addresses.email_address LIKE :e1 OR addresses.email_address LIKE :e2)
... """)
sql>>> print conn.execute(s, x='m', y='z', e1='%@aol.com', e2='%@msn.com').fetchall()
Но чаще такое не нужно, это все можно методами описать.
Подробнее про sqlexpression.
спасибо. именно то, что нужно.
а подскажите еще, пожалуйста, как решается в ORM пробелма с операторами аггрегации?
типа group by
в свое время искал, но так ничего и не нашел.
а подскажите еще, пожалуйста, как решается в ORM пробелма с операторами аггрегации?
типа group by
в свое время искал, но так ничего и не нашел.
Подсказываю.
ORM:
SQLExpression:
ORM:
>>>session.query(User.name).group_by(User.name).count() SELECT count(1) AS count_1 FROM (SELECT users.name AS users_name FROM users GROUP BY users.name) AS anon_1 ()
SQLExpression:
>>> s = select([addresses.c.email_address, addresses.c.id]).distinct().\ ... order_by(addresses.c.email_address.desc(), addresses.c.id) >>> conn.execute(s).fetchall() SELECT DISTINCT addresses.email_address, addresses.id FROM addresses ORDER BY addresses.email_address DESC, addresses.id ()
кстати, начиная с SQLAlchemy 0.6 — вполне возможно использовать raw sql и маппить его:
>>> session.query(User).from_statement(«SELECT * FROM users where name=:name»).params(name='ed').all()
[<User('ed','Ed Jones', 'f8s7ccs')>]
www.sqlalchemy.org/docs/ormtutorial.html#using-literal-sql
>>> session.query(User).from_statement(«SELECT * FROM users where name=:name»).params(name='ed').all()
[<User('ed','Ed Jones', 'f8s7ccs')>]
www.sqlalchemy.org/docs/ormtutorial.html#using-literal-sql
Sign up to leave a comment.
Pylons Framework