Jak zarządzać aplikacjami Django?

Question

Po prostu chciałem spróbować zbudować projekt z django. Dlatego mam (podstawowe) pytanie, jak zarządzać takim projektem. Ponieważ nie mogę znaleźć żadnych wskazówek, jak podzielić projekt na aplikacje.

Weźmy za przykład SO. Z jakich aplikacji skorzystasz? Powiedziałbym, że powinny być aplikacje "użytkownicy" i "pytania". Ale co, jeśli istniał system tematyczny z artykułami statycznymi. Być może oni również mogli otrzymać głosy. Jak zbudować strukturę aplikacji? Jedna aplikacja do "pytań", "głosów" i "tematów" lub tylko jednej "treści" aplikacji?

Nie mam pojęcia, co robić. Może dlatego, że nie wiem jeszcze zbyt wiele o Django, ale jestem zainteresowany ...

Answer 1

Powiem ci, jak się zbliżam do tego pytania: zazwyczaj siadam z kartką papieru i rysuję pudła (funkcjonalności) i strzałki (współzależności między funkcjami). Jestem pewien, że istnieją metodologie lub inne rzeczy, które mogą ci pomóc, ale moje podejście zwykle działa dla mnie (oczywiście YMMV).

Jednak wiedza o tym, jak powinna wyglądać strona, jest podstawowa. ;)

Answer 2

Powinieneś spróbować oddzielić projekt w jak największej liczbie aplikacji. W przypadku większości projektów aplikacja nie będzie zawierała więcej niż 5 modeli. Na przykład projekt taki jak SO miałby osobne aplikacje dla UsersProfiles, pytania, tagi (w tym django jest gotowy), itp. Jeśli byłby system ze statycznymi stronami, które byłyby oddzielną aplikacją (są gotowe w tym celu). Powinieneś również spróbować uczynić swoje aplikacje tak ogólnymi, jak to tylko możliwe, aby móc je ponownie wykorzystać w innych projektach. Jest dobry presentation na aplikacje wielokrotnego użytku.

Answer 3

Podobnie jak każdy zestaw zależności ... staraj się znaleźć najbardziej użyteczne, samodzielne aspekty projektu i tworzyć samodzielne aplikacje. Inne aplikacje Django będą miały funkcjonalność na wyższym poziomie i ponownie wykorzystają części skonfigurowanych najniższych poziomów aplikacji.

W moim projekcie mam aplikację kalendarza z własnym obiektem Event w jej modelach. Mam również skonfigurowaną bazę danych carpoolingu, a dla czasu odjazdu i czasu trwania używam obiektu Event kalendarza bezpośrednio w moich tabelach RideShare. Baza danych carpoolingu jest dostępna w kalendarzu i pobiera wszystkie ładne widoki eksportu i kalendarza .ics z aplikacji kalendarza "za darmo".

Istnieje kilka trików, aby uzyskać możliwość ponownego użycia Aplikacji, na przykład nazwanie katalogu szablonów: project/app2/templates/app2/index.html. Dzięki temu możesz odwołać się do app2/index.html z dowolnej innej aplikacji i uzyskać odpowiedni szablon. Wybrałem to, patrząc na wbudowane aplikacje wielokrotnego użytku w samym Django. Pinax ma trochę rozmiarów potwora, ale demonstruje również ładną konstrukcję aplikacji wielokrotnego użytku.

Jeśli masz wątpliwości, zapomnij o aplikacjach wielokrotnego użytku. Umieść wszystkie swoje wiadomości i ankiety w jednej aplikacji i przejdź przez jeden rev. Podczas procesu odkryjesz, jakie kroki są niepotrzebne, i które mogą zostać rozwiązane jako samodzielne rozwiązanie w przyszłości.

Answer 4

Nie ma sztywnych zasad, ale powiedziałbym, że lepiej jest błądzić po stronie bardziej wyspecjalizowanych aplikacji. W idealnym przypadku aplikacja powinna obsługiwać tylko jedną funkcję: "tagowanie" lub "komentowanie" lub "auth/auth" lub "posty". Ten typ projektowania pomoże także ponownie wykorzystać dostępne aplikacje typu open source zamiast wymyślać nowe koło (to znaczy, że Django może być wyposażony w aplikacje auth i comments, prawie na pewno może zrobić to, czego potrzebujesz, itd.).

Generic foreign keys pomaga rozdzielić aplikacje, takie jak oznaczanie lub komentowanie, które można zastosować do modeli z kilku innych aplikacji.

Answer 5

Dobre pytanie, które należy zadać sobie przy podejmowaniu decyzji, czy napisać aplikację, brzmi "czy mogę użyć tego w innym projekcie?". Jeśli myślisz, że możesz, to zastanów się, co by było zrobić, aby aplikacja była jak najbardziej niezależna; W jaki sposób można zmniejszyć zależności, aby aplikacja nie opierała się na konkretnym projekcie.

Niektóre ze sposobów można to zrobić to:

• podając wzajemnie aplikację własnym urls.py
• Umożliwienie typów modeli mają być przekazywane jako parametry aniżeli wyraźnie oświadczając, jakie modele są stosowane w swojej widoki. Ogólne widoki używają tej zasady.
• Spraw, aby szablony były łatwo zastępowane przez podanie parametru nazwa_kolumny w Twoim urls.py
• Upewnij się, że możesz wykonywać wyszukiwania odwrotnego adresu URL z obiektami i widokami. Oznacza to nazywanie widoków w urls.py i tworzenie metod get_absolute_url w swoich modelach.
• W niektórych przypadkach, takich jak Tagowanie, GenericForeignKeys może być używany do kojarzenia modelu w Twojej aplikacji z dowolnym modelem, niezależnie od tego, czy ma on w sobie "Lookout back".