2010-08-31 2 views
4

Я в ситуации, когда мне нужно объединить два приложения Django в одно приложение для повторного использования. Также не очень большие, но они, конечно, не тривиальные приложения и для сохранения удобочитаемости/здравомыслия. Я стараюсь, чтобы оба приложения были разделены до некоторой степени.Я правильно организовал свое приложение для django?

Я мог бы настроить каждое приложение как суб-пакет (который был бы питоническим способом для достижения этой цели), или я могу придерживаться соглашений Django и разделить функциональность по отдельности в каждом случае.

A вещий 'суб-пакет' подход:

package 
|-- __init__.py 
|-- views.py 
|-- models.py  # imports models from both sub-packages 
|-- tests.py  # imports TestCase instances from both sub-packages 
|-- etc.   # shared stuff 
|-- a 
| |-- __init__.py 
| |-- views.py 
| |-- models.py 
| |-- tests.py 
| `-- etc.  # a-specific code 
`-- b 
    |-- __init__.py 
    |-- views.py 
    |-- models.py 
    |-- tests.py 
    `-- etc.  # b-specific code 

Или успокоить богов Django более прямо:

package 
|-- __init__.py 
|-- views 
| |-- __init__.py 
| |-- a.py 
| `-- b.py 
|-- models 
| |-- __init__.py # imports models from a and b 
| |-- a.py 
| `-- b.py 
|-- tests 
| |-- __init__.py # imports TestCase instances from a and b 
| |-- a.py 
| `-- b.py 
`-- etc. # shared/additional files 

Хотя я склоняюсь к бывшим в тот момент (который чувствует немного легче), моя кишка говорит мне, что, хотя обе работы (и оба связаны с импортом «хаков», чтобы соответствовать структуре Django), лучший выбор зависит от содержания a и b - в частности, сколько общего кода или приложений - конкретный. Не всегда нужно постоянно повторять шаблон __ init__.py, a.py, b.py в каждом подкаталоге!

Я заинтересован в том, чтобы узнать, что более уместно у людей с большим опытом работы с Python!

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

ответ

2

Плоский лучше, чем вложенный.

«Композитное» приложение, построенное из двух приложений однорангового соединения, прекрасно. Это работает хорошо.

И это способствует повторному использованию, позволяя двум компонентам быть «plug-and-play» в более крупном приложении.

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

+0

Для удобства чтения для непрофессионала вы могли бы прояснить, кто из них «плоский», а какой «вложен», и какой из них лучше? – thomaspaulb

+0

Afaik the zen ссылается на код python, а не на структуру файлов, не так ли? – dietbacon

1

Я не эксперт в python, но мне всегда нравятся отдельные приложения и другие артефакты, насколько я могу.

Я следую за подходом, описанным в этом blog для моего собственного проекта django, и для этого требуется немного настройки на django. Это послужило мне до сих пор.

Прямая ссылка на github project

+0

Спасибо за ссылку! – adamnfish

1

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

package 
|-- __init__.py 
|-- models.py  # models are in one file 
|-- etc.   # shared stuff 
|-- tests 
| |-- __init__.py 
| |-- tests_orders.py 
| |-- tests_clients.py 
| |-- 
| `-- etc. 
|-- views 
| |-- __init__.py 
| |-- orders.py 
| |-- clients.py 
| |-- 
| `-- etc. 

Для более крупных проектов, имеющих вид функций в одном файле это боль (для меня).

Это то, что работает для некоторых проектов, над которыми я работаю - надеюсь, кто-то найдет это полезным.

Смежные вопросы