Django: „projekty” a „aplikacje”

Mam dość złożony „produkt”. Przygotowuję się do kompilacji za pomocą Django. Unikam używania terminów „projekt” i „aplikacja” w tym kontekście, ponieważ nie jestem pewien, jakie jest ich konkretne znaczenie w Django.

Projekty mogą mieć wiele aplikacji. Aplikacje mogą być współużytkowane przez wiele projektów. W porządku.

Nie odkrywam na nowo bloga ani forum - nie widzę, aby jakakolwiek część mojego produktu mogła być ponownie wykorzystana w jakimkolwiek kontekście. Intuicyjnie nazwałbym tę „aplikację”. Czy wtedy wykonuję całą pracę w jednym folderze „aplikacji”?

Jeśli tak ... jeśli chodzi o project.appprzestrzeń nazw Django , mam skłonność do korzystania myproduct.myproduct, ale oczywiście nie jest to dozwolone (ale aplikacja, którą tworzę, to mój projekt, a mój projekt to aplikacja!). Dlatego wierzę, że być może powinienem podejść do Django, budując jedną aplikację na „znaczący” model, ale nie wiem, gdzie narysować granice w moim schemacie, aby podzielić je na aplikacje - mam dużo modeli o relatywnie złożonych relacjach.

Mam nadzieję, że istnieje wspólne rozwiązanie tego ...

Co Cię powstrzymuje myproduct.myproduct? Aby to osiągnąć, musisz z grubsza to zrobić:

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

i tak dalej. Czy pomogłoby to, gdybym powiedział, views.pyże nie trzeba dzwonić views.py? Pod warunkiem, że możesz nazwać na ścieżce Pythona funkcję (zwykle pakiet.package.views.function_name), zostanie ona obsłużona. Proste. Wszystkie te „projekty” / „aplikacje” to tylko pakiety Pythona.

Jak masz to zrobić? A raczej, jak mogę to zrobić? Dobrze, jeśli tworzysz znaczący kawałek funkcjonalności wielokrotnego użytku, jak mówią, edytor znaczników, to podczas tworzenia „aplikacji najwyższego poziomu”, które mogą zawierać widgets.py, fields.py, context_processors.pyetc - wszystko może chcesz importować.

Podobnie, jeśli możesz stworzyć coś w rodzaju bloga w formacie, który jest dość ogólny podczas instalacji, możesz zawinąć go w aplikację, z własnym szablonem, folderem zawartości statycznej itp., I skonfigurować instancję projektu django, aby z niego korzystać zawartość aplikacji.

Nie ma twardych i szybkich zasad mówiących, że musisz to zrobić, ale jest to jeden z celów ram. Fakt, że wszystko, łącznie z szablonami, pozwala na dołączenie z jakiejś wspólnej bazy, oznacza, że ​​Twój blog powinien dobrze pasować do każdej innej konfiguracji, po prostu dbając o własną część.

Jednak aby odpowiedzieć na twoje aktualne obawy, tak, nic nie mówi, że nie możesz pracować z folderem projektu najwyższego poziomu. To właśnie robią aplikacje i możesz to zrobić, jeśli naprawdę chcesz. Nie robię tego jednak z kilku powodów:

• Domyślna konfiguracja Django tego nie robi.
• Często chcę utworzyć główną aplikację, więc tworzę jedną, zwykle nazywaną website. Jednak w późniejszym czasie mógłbym chcieć opracować oryginalną funkcjonalność tylko dla tej witryny. Aby uczynić go usuwalnym (niezależnie od tego, czy kiedykolwiek to robię), zwykle tworzę osobny katalog. Oznacza to również, że mogę upuścić tę funkcjonalność po prostu odłączając ten pakiet od konfiguracji i usuwając folder, zamiast skomplikowanego usuwania odpowiednich adresów URL z globalnego folderu urls.py.
• Bardzo często, nawet gdy chcę uczynić coś niezależnym, musi on gdzieś żyć, a ja będę się nim opiekować / uniezależnić. Zasadniczo powyższy przypadek, ale dla rzeczy zamierzam zrobić rodzajowy.
• Mój folder najwyższego poziomu często zawiera kilka innych rzeczy, w tym między innymi skrypty wsgi, skrypty SQL itp.
• Rozszerzenia zarządzania django opierają się na podkatalogach. Dlatego sensowne jest odpowiednie nazwanie pakietów.

Krótko mówiąc, powód, dla którego istnieje konwencja, jest taki sam jak każda inna konwencja - pomaga to innym osobom pracującym z twoim projektem. Jeśli widzę fields.py, od razu oczekuję, że kod podklasuje pole django, podczas gdy widzę inputtypes.py, że nie jestem tak jasny, co to znaczy, bez patrzenia na to.

Po ukończeniu korzystania z startprojecti startappnic nie stoi na przeszkodzie, aby połączyć „projekt” i „aplikację” w tym samym pakiecie Pythona. Projekt to tak naprawdę tylko settingsmoduł, a aplikacja to tak naprawdę tylko modelsmoduł - wszystko inne jest opcjonalne.

W przypadku małych witryn całkowicie uzasadnione jest posiadanie czegoś takiego:

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py

Spróbuj odpowiedzieć na pytanie: „Co robi moja aplikacja?”. Jeśli nie możesz odpowiedzieć w jednym zdaniu, być może możesz podzielić go na kilka aplikacji z czystszą logiką.

Przeczytałem tę myśl gdzieś wkrótce po tym, jak zacząłem pracować z django i stwierdzam, że dość często zadaję sobie to pytanie i to mi pomaga.

Twoje aplikacje nie muszą być wielokrotnego użytku, mogą na siebie polegać, ale powinny zrobić jedną rzecz.

Znalazłem następujące posty na blogu bardzo przydatne na temat aplikacji i projektów django:

• http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
• http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/

Zasadniczo masz dużo swobody dzięki django do organizowania kodu źródłowego swojego produktu.

Jeśli tak ... jeśli chodzi o przestrzeń nazw project.app Django, moja skłonność to użycie myproduct.myproduct, ale oczywiście nie jest to dozwolone

Nie ma nic takiego, jak niedozwolone. To twój projekt, nikt cię nie ogranicza. Wskazane jest zachowanie rozsądnej nazwy.

Nie widzę, aby jakakolwiek część mojego produktu była wielokrotnego użytku w jakimkolwiek kontekście. Intuicyjnie nazwałbym tę „aplikację”. Czy wtedy wykonuję całą pracę w jednym folderze „aplikacji”?

W ogólnym projekcie django istnieje wiele aplikacji (aplikacji contrib), które są naprawdę używane w każdym projekcie.

Powiedzmy, że twój projekt wykonuje tylko jedno zadanie i ma tylko jedną aplikację (nazywam to main nazywam ponieważ projekt obraca się wokół niego i jest trudny do podłączenia). Ten projekt również nadal używa innych aplikacji.

Teraz, jeśli powiesz, że twój projekt używa tylko jednej aplikacji ( INSTALLED_APPS='myproduct'), to po co projectdefiniować projekt jako project.app, myślę, że powinieneś rozważyć kilka kwestii:

• Istnieje wiele innych rzeczy, które obsługuje kod inny niż aplikacja w projekcie (podstawowe pliki statyczne, podstawowe szablony, ustawienia .... tj. Zapewnia podstawę).
• W ogólnym podejściu project.app django automatycznie definiuje schemat SQL na podstawie modeli.
• Twój projekt byłby znacznie łatwiejszy do zbudowania przy użyciu konwencjonalnego podejścia.
• Możesz zdefiniować różne nazwy adresów URL, widoków i innych plików według własnego uznania, ale nie widzę takiej potrzeby.
• W przyszłości może być konieczne dodanie niektórych aplikacji, co byłoby naprawdę łatwe w przypadku tradycyjnych projektów django, które w przeciwnym razie mogą stać się równie lub trudniejsze i uciążliwe.

Jeśli chodzi o większość prac wykonywanych w aplikacji, myślę, że tak jest w przypadku większości projektów django.

Tutaj twórcy Django sami zauważają tę różnicę . Myślę, że myślenie o aplikacjach, ponieważ muszą one być wielokrotnego użytku w innych projektach jest dobry . Również dobrym sposobem myślenia o aplikacjach w Django są nowoczesne aplikacje internetowe.

Wyobraź sobie, że tworzysz dużą dynamiczną aplikację internetową w oparciu o JavaScript .

Następnie możesz utworzyć w aplikacji django o nazwie np. „FrontEnd” <- w cienkiej aplikacji wyświetlisz zawartość.

Następnie tworzysz niektóre aplikacje zaplecza. Np. Aplikacja o nazwie „Komentarze”, która przechowuje komentarze użytkowników. Aplikacja „Komentarze” sama nie wyświetli niczego. Będzie to tylko API dla żądań AJAX Twojej dynamicznej strony JS .

W ten sposób zawsze możesz ponownie użyć aplikacji „Komentarze”. Możesz zrobić to jako open source bez otwierania źródła całego projektu. I zachowujesz czystą logikę swojego projektu.