Kiedy stworzyć nową aplikację (z startapp) w Django?

Przeszukałem to w Google, ale nadal mam problem z tym, co Django definiuje jako „aplikacje”.

Czy powinienem utworzyć nową aplikację dla każdej funkcji w witrynie, mimo że korzysta ona z modeli z głównego projektu?

Czy macie dobrą regułę, kiedy oddzielić nową aplikację, a kiedy zachować funkcjonalność razem z „głównym projektem” lub innymi aplikacjami?

James Bennett ma wspaniały zestaw slajdów pokazujących, jak organizować aplikacje wielokrotnego użytku w Django.

Wolę myśleć o aplikacjach Django jako o modułach lub komponentach wielokrotnego użytku niż o „aplikacjach”.

Pomaga mi to w hermetyzowaniu i oddzielaniu pewnych funkcji od siebie, poprawiając możliwość ponownego użycia, jeśli zdecyduję się udostępnić określoną „aplikację” całej społeczności, oraz łatwość konserwacji.

Moje ogólne podejście polega na podzieleniu określonych funkcji lub zestawów funkcji na „aplikacje”, tak jakbym zamierzał udostępniać je publicznie. Najtrudniejsze jest tutaj ustalenie, jak duże jest każde wiadro.

Dobrą sztuczką, której używam, jest wyobrażenie sobie, jak moje aplikacje byłyby używane, gdyby zostały udostępnione publicznie. To często zachęca mnie do zmniejszenia kubełków i wyraźniejszego określenia jego „celu”.

Oto zaktualizowana prezentacja z 6 września 2008 r.

DjangoCon 2008: aplikacje wielokrotnego użytku @ 7:53

Slajd: Reusable_apps.pdf

Zaczerpnięte ze slajdu

Czy powinna to być jego własna aplikacja?

• Czy jest to całkowicie niezwiązane z celem aplikacji?
• Czy jest to prostopadłe do tego, co robię?
• Czy będę potrzebować podobnych funkcji w innych witrynach?

Jeśli któryś z nich brzmi „Tak”? Następnie najlepiej podzielić go na osobną aplikację.

Mam tendencję do tworzenia nowych aplikacji dla każdego logicznie oddzielnego zestawu modeli. na przykład:

• Profile użytkowników
• Posty na forum
• Posty na blogu

Zasada, którą kieruję się jest taka, że ​​powinna to być nowa aplikacja, jeśli chcę ponownie użyć tej funkcji w innym projekcie.

Jeśli wymaga głębokiego zrozumienia modeli w twoim projekcie, prawdopodobnie bardziej spójne będzie przyklejenie go do modeli.

Dwie najlepsze odpowiedzi na to pytanie, które znalazłem w sieci, to:

1. The Reusable Apps Talk ( slajdy ) ( wideo ) wspomniana również w innych odpowiedziach. Bennett, autor i współautor Django, regularnie publikuje aplikacje, z których mogą korzystać inni, i ma mocny pogląd na wiele małych aplikacji.
2. Doordash's Tips for Django at Scale, który daje przeciwną radę i mówi w ich przypadku, że migrowali do jednej aplikacji po uruchomieniu wielu oddzielnych aplikacji. Napotkali problemy z wykresem zależności migracji między aplikacjami.

Oba źródła zgadzają się, że w następujących sytuacjach należy utworzyć oddzielną aplikację:

• Jeśli planujesz ponownie użyć swojej aplikacji w innym projekcie Django (zwłaszcza jeśli planujesz opublikować ją dla innych do ponownego wykorzystania).
• Jeśli aplikacja ma niewiele zależności między nią a inną aplikacją lub nie ma ich wcale. Tutaj możesz sobie wyobrazić aplikację działającą jako własną mikrousługę w przyszłości.

„Aplikacja” może oznaczać wiele różnych rzeczy, wszystko sprowadza się do gustu. Na przykład, powiedzmy, że tworzysz bloga. Twoja aplikacja może być całym blogiem lub możesz mieć aplikację „administratora”, aplikację „witryny” dla wszystkich widoków publicznych, aplikację „rss”, aplikację „usług”, aby programiści mogli łączyć się z blogiem w swoich własne drogi itp.

Osobiście uczyniłbym sam blog aplikacją i wyłapałbym w nim funkcjonalność. Blog mógłby być wówczas dość łatwo ponownie wykorzystany w innych witrynach internetowych.

Zaletą Django jest to, że rozpoznaje każdy plik models.py na dowolnym poziomie twojego drzewa katalogów jako plik zawierający modele Django. Zatem podzielenie funkcjonalności na mniejsze „podaplikacje” w samej „aplikacji” nie sprawi, że nic trudniejszego.