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.app
przestrzeń 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 ...
Odpowiedzi:
Co Cię powstrzymuje
myproduct.myproduct
? Aby to osiągnąć, musisz z grubsza to zrobić: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.py
etc - 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:
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.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
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 efektumyproduct_app
.Po ukończeniu korzystania z
startproject
istartapp
nic nie stoi na przeszkodzie, aby połączyć „projekt” i „aplikację” w tym samym pakiecie Pythona. Projekt to tak naprawdę tylkosettings
moduł, a aplikacja to tak naprawdę tylkomodels
moduł - wszystko inne jest opcjonalne.W przypadku małych witryn całkowicie uzasadnione jest posiadanie czegoś takiego:
źródło
INSTALLED_APPS
liście. Oto przykład: stackoverflow.com/a/59739912/399435Przeczytał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.
źródło
Znalazłem następujące posty na blogu bardzo przydatne na temat aplikacji i projektów django:
Zasadniczo masz dużo swobody dzięki django do organizowania kodu źródłowego swojego produktu.
źródło
Nie ma nic takiego, jak niedozwolone. To twój projekt, nikt cię nie ogranicza. Wskazane jest zachowanie rozsądnej nazwy.
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 coproject
definiować projekt jakoproject.app
, myślę, że powinieneś rozważyć kilka kwestii:Jeśli chodzi o większość prac wykonywanych w aplikacji, myślę, że tak jest w przypadku większości projektów django.
źródło
main
konwencji - 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ć.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.
źródło