организация приложений django - PullRequest
5 голосов
/ 07 июня 2010

Я читал некоторый учебник по django, и кажется, что все функции представления должны идти в файле с именем "views.py", а все модели - в "models.py". Я боюсь, что в моем файле view.py может оказаться много функций просмотра, и то же самое можно сказать и о модели.

Правильно ли я понимаю приложения django?

Приложения Django позволяют разделять общие функции на разные приложения и сводить к минимуму размер файлов представлений и моделей? Например: мой проект может содержать приложение для рецептов (создание, обновление, просмотр и поиск) и приложение для друзей, приложение для комментариев и т. Д.

Могу ли я переместить некоторые из моих функций просмотра в другой файл? Таким образом, у меня есть только CRUD в одном файле?

Ответы [ 4 ]

7 голосов
/ 07 июня 2010

Во-первых, большие файлы довольно часто встречаются в python. Python - это не java, который имеет один класс на файл, а один модуль на файл.

Далее views, даже в качестве используемого стандарта, представляет собой модуль Python . Модуль не должен быть одним файлом. Это может быть каталог, содержащий много файлов, и __init__.py

А потом, views.py - это всего лишь соглашение. Вы , программист приложения ссылается на него, а сам django нигде не ссылается. Таким образом, вы можете поместить его в столько файлов и передать соответствующие функции, которые необходимо передать, в запрос urls.py

1 голос
/ 01 августа 2013

Мне также очень не нравятся длинные файлы.

Конечно, то, что вы читаете в других ответах, правда, но я использую некоторую очень изящную эквивалентность Python:

views.py

и

views/__init__.py

в значительной степени функционально равны. Я имею в виду, что если оба содержат def my_view(), то

from views import my_view

будет работать одинаково в обоих случаях!

Оттуда легко структурировать ваши длинные файлы в более мелкие, сохраняя при этом соглашение об именах, к которому привык каждый разработчик django:

views/__init__.py
views/largemodel_view.py

затем в __init__.py не забудьте импортировать представления из largemodel_view.py.

В больших приложениях я делаю то же самое с моделями, хотя вы должны помнить, чтобы установить Meta.app_name:

class MyModel(models.Model):
    ...

    class Meta:
        app_name = 'yourappname'

потому что django не будет магически поднимать его для администратора (но все равно будет загружать его, благодаря Python!)

так что мои приложения обычно выглядят примерно так:

project/settings/__init__.py
                /..othersettings..
       /app_1/models/__init__.py
                    /...
             /views/__init__.py
                   /...
             /templates/
             /static/
             urls.py
       /urls.py

и т.д.

хотя, конечно, ограничений нет (URL-адреса тоже могут быть разделены и т. Д.)

1 голос
/ 07 июня 2010

Им не нужно заходить в views.py. На них должны быть ссылки там.

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

То же самое относится к models.py.

Приложения Django позволяют нам разделять общие функциональность в разные приложения и сохранить размер файла видов и моделей до минимума? Например: мой проект может содержать приложение для рецептов (создание, обновление, просмотр и поиск) и приложение для друзей, приложение для комментариев и т. д. на.

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

0 голосов
/ 07 июня 2010

Ответ на этот вопрос может оказаться полезным для вас.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...