Фреймворк, который не мешает

Прочитал в статье про RoR на Never-Invited.com:

Только нужно понимать одну вещь: Rails облегчает стандартные вещи. Если вам нужно что-то уникальное от начала и до конца, то Rails будет скорее мешать. Как, впрочем, и любой другой framework.

Секундочку! Я никогда не писал ничего в Rails, поэтому не могу сказать, насколько это правильно для него. Но вот для Django (который попадает под определение "любой другой фреймворк") это совершенно неверно. Я даже, пожалуй, соглашусь, что это — мешать сделать нестандартное — черта очень многих фреймворков, но это ни в коем случае не обязательное зло, присущее любому.

Одна из вещей, которая меня "купила" в Django — это великолепная демонстрация того, как работает слабая связность компонентов. Помимо того, что любой компонент Django можно заменить на что-то другое, так еще и Django не навязывает (хоть и рекомендует) никакой определенной архитектуры построения приложения. Это ваше приложение, стройте его, как считаете нужным.

Пример. Есть у меня проект некоего фотосервиса, позволяющего заказывать печать фотографий. По изначальной задумке он должен был являться фронт-ендом к некой внутренней БД компании: принимать заказы на вебе и отправлять их туда. Кроме того, он должен узнавать зарегистрированных клиентов и показывать им, скажем, персональные скидки. Это тут же означает, что я не могу пользоваться стандартной Django'овской системой авторизации клиентов, потому что она предполагает хранение своих клиентов у себя в базе, а мне нужны клиенты из внутренней базы.

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

То есть да, часть автоматизма, предлагаемого фреймворком, оказалась потерянной, но никаких дополнительных трудностей из-за него я не приобрел. Только плюсы: я фактически скопировал из кода Django все подходы к выставлению клиента в приложении :-).