В целом если вы видели один MVC фреймворк, вы видели их все. Переходя с Rails на Django (и наоборот) вы, может быть, ожидаете увидеть какие-то различия, но на самом деле всё в точности то же самое.
Однако при более подробном всматривании и ощупывании всплывает этакий программистский вариант "ложных друзей переводчика". И там, и там есть applications ("приложения"), migrations ("миграции"), views ("представления", здесь перевод не устоявшийся и их обычно "вьюхами" и называют). Но все эти штуки в обоих фреймворках либо существенно отличаются, либо обозначают просто разные вещи.
Вот планирую в небольшом цикле заметок остановиться именно на таких различиях, а сходство больше и не упоминать.
В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.
В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.
На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).
Если в папке app/models/car.rb лежит класс Car, то вам достаточно в коде написать Car, и Rails его найдут.
В Django всё не так просто.
Во-первых, вам всегда надо вручную импортировать классы из пакетов: from car_service.models import Car. В этом есть плюс: IDE всегда знает, откуда что взялось. Минус: существенное увеличение boilerplate-а и когнитивной нагрузки на его обслуживание.
В строке импорта выше car_service это, в терминах Python, имя пакета (имя выбрано произвольно: допустим, мы делаем бэкофис для автомастерской). А в терминах DJango, это имя "приложения" (application). models.py – имя файла, где лежит исходный код класса Car. Да, в Django в один файл принято запихивать десяток классов. Это одно из многих проявлений знаменитого питоновского акцента на красоту и элегантность кода.
Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (INSTALLED_APPS) в settings.py (файл настроек проекта). (Кстати, термин application здесь в итоге близок тому, как он понимается в экосистеме Elixir/Phoenix.) В терминах Rails этому car_service нет прямого аналога, иногда что-то подобное можно назвать "ресурсом" (resource, в терминах REST), иногда bounded context (опять же в Phoenix более прямые аналоги).
Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле car_service/models.py, а модель User в папке accounts/models.py.
В целом если вы видели один MVC фреймворк, вы видели их все. Переходя с Rails на Django (и наоборот) вы, может быть, ожидаете увидеть какие-то различия, но на самом деле всё в точности то же самое.
Однако при более подробном всматривании и ощупывании всплывает этакий программистский вариант "ложных друзей переводчика". И там, и там есть applications ("приложения"), migrations ("миграции"), views ("представления", здесь перевод не устоявшийся и их обычно "вьюхами" и называют). Но все эти штуки в обоих фреймворках либо существенно отличаются, либо обозначают просто разные вещи.
Вот планирую в небольшом цикле заметок остановиться именно на таких различиях, а сходство больше и не упоминать.
В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.
В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.
На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).
Если в папке app/models/car.rb лежит класс Car, то вам достаточно в коде написать Car, и Rails его найдут.
В Django всё не так просто.
Во-первых, вам всегда надо вручную импортировать классы из пакетов: from car_service.models import Car. В этом есть плюс: IDE всегда знает, откуда что взялось. Минус: существенное увеличение boilerplate-а и когнитивной нагрузки на его обслуживание.
В строке импорта выше car_service это, в терминах Python, имя пакета (имя выбрано произвольно: допустим, мы делаем бэкофис для автомастерской). А в терминах DJango, это имя "приложения" (application). models.py – имя файла, где лежит исходный код класса Car. Да, в Django в один файл принято запихивать десяток классов. Это одно из многих проявлений знаменитого питоновского акцента на красоту и элегантность кода.
Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (INSTALLED_APPS) в settings.py (файл настроек проекта). (Кстати, термин application здесь в итоге близок тому, как он понимается в экосистеме Elixir/Phoenix.) В терминах Rails этому car_service нет прямого аналога, иногда что-то подобное можно назвать "ресурсом" (resource, в терминах REST), иногда bounded context (опять же в Phoenix более прямые аналоги).
Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле car_service/models.py, а модель User в папке accounts/models.py.
Matt Hussey, editorial director of NEAR Protocol (and former editor-in-chief of Decrypt) responded to the news of the Telegram group with “#meIRL.” Other crimes that the SUCK Channel incited under Ng’s watch included using corrosive chemicals to make explosives and causing grievous bodily harm with intent. The court also found Ng responsible for calling on people to assist protesters who clashed violently with police at several universities in November 2019. How to Create a Private or Public Channel on Telegram? It’s easy to create a Telegram channel via desktop app or mobile app (for Android and iOS): Telegram desktop app: In the upper left corner, click the Menu icon (the one with three lines). Select “New Channel” from the drop-down menu.
from us
