Django: „projekty” a „aplikacje”

202

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 ...

Dolph
źródło
1
Dokumenty wyjaśniają różnicę między „aplikacją” a „projektem” tutaj: docs.djangoproject.com/en/dev/ref/applications/…
guettli

Odpowiedzi:

56

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.


źródło
24
+1 ... „Co powstrzyma cię przed użyciem myproduct.myproduct?” - Polecenie „startapp” Django faktycznie zatrzymuje cię, jak sądzę, jako konwencję. Lubię konwencje, szczególnie w kontekście wysiłków zespołu, ale wolę zrozumieć logikę, która się za nimi kryje :)
Dolph
@Dolph ah, prawda? Nie używałem go od pierwszego użycia, ponieważ mam własne polecenie tworzenia projektu, który najpierw tworzy modele, a następnie automatycznie generuje rzeczy CRUD dla tych modeli. Mimo to tak, konwencje są dobre. Przestrzegam konwencji django, choćby dlatego, że w dużej mierze mają one sens.
1
Dodam, że użycie tej samej nazwy dla projektu i aplikacji w nim również powoduje problemy manage.py, powodując, że nie może poprawnie zaimportować ustawień projektu. To mi się przydarzyło i rozwiązałem to, refaktoryzując aplikację do efektu myproduct_app.
BHSPitMonkey
89

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
claymation
źródło
18
Podsumowanie +1: projekt ma settings.py, aplikacja ma models.py. Są to te same struktury poziomu. Kiedyś myślałem, że projekt jest o jeden poziom wyższy niż aplikacja, zgaduję, że się myliłem
Philip007,
2
@Claymation, co należy uwzględnić w ustawieniach (jako aplikacja), aby „migracja python manage.py makemigration” lub „migracja python manage.py” wyświetlała plik „models.py” w katalogu „mój produkt”?
mlwn
1
@mlwn Zdaję sobie sprawę, że spóźniłem się z odpowiedzią na to pytanie, ale sam jestem w podobnej sytuacji i szukałem wielu odpowiedzi. Aby odpowiedzieć na twoje pytanie, wystarczy, że umieścisz swój projekt na INSTALLED_APPSliście. Oto przykład: stackoverflow.com/a/59739912/399435
Karthic Raghupathi
@KarthicRaghupathi, dzięki .. :) miło widzieć komentarze, na które odpowiedziano po czterech latach .. wiwaty
mlwn
69

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.

Narty
źródło
8
Nadal mam problemy z przygotowaniem własnej aplikacji. Wydaje mi się, że moja główna aplikacja jest trochę ciężka, ale jednocześnie nie byłbym w stanie przeformułować jej w coś podobnego do czegoś luźno sprzężonego. Skłaniam się ku myśleniu, że oddzielenie moich głównych głównych istot nie byłoby poprawą, gdyby nadal silnie od siebie zależały, i nie ma potrzeby ponownego użycia lub uogólnienia na horyzoncie. Skłaniam się ku „nie przedwcześnie refaktoryzuj” jako interpretacji „nie przedwcześnie optymalizuj”
acjay
8

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.

Crodjer
źródło
1
+1, szczególnie w przypadku mainkonwencji - ma to dla mnie sens dla oryginalnego projektu takiego jak ten. Planuję dodawać aplikacje „wielokrotnego użytku” później, ale obecnie nie jestem w stanie tego skupić.
Dolph
2

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.

Qback
źródło