• Przykład aplikacji DBAudioCD
• Typy pól w modelach Typy pól
• Opcje pól w modelach Opcje pól
• Opcje Meta Meta ogólnie
• Opcje Meta w modelach
• Opcje Meta w formularzach

W kontekście jednego projektu biznesowego Django dla jednej firmy, powszechnie stosowaną praktyką jest tworzenie jednego dużego projektu Django, który zawiera wiele aplikacji. Każda aplikacja reprezentuje różne funkcjonalności, moduły lub komponenty systemu. Dzięki temu podejściu, całość projektu biznesowego jest zorganizowana w ramach jednej struktury projektowej.

Korzyści z tego podejścia obejmują:

1. Łatwość organizacji: Możesz zorganizować projekt według różnych modułów lub funkcjonalności, a każda aplikacja może reprezentować jedną z tych części.

2. Współdzielenie kodu: W ramach jednego projektu łatwiej jest współdzielić kod między różnymi aplikacjami. Dostęp do wspólnego kodu, takiego jak modele, funkcje pomocnicze czy widoki, jest bardziej zintegrowany.

3. Utrzymanie jednej bazy danych: Jednym projektem łatwiej zarządzać jedną bazą danych, zwłaszcza jeśli różne aplikacje mają ze sobą powiązane dane.

4. Integracja: Aplikacje w ramach jednego projektu mogą łatwiej współpracować i wymieniać dane. Komunikacja między aplikacjami jest bardziej bezpośrednia.

5. Łatwiejsze zarządzanie infrastrukturą: Zarządzanie jednym projektem może być prostsze niż wieloma projektami, zwłaszcza jeśli chodzi o kwestie infrastruktury, konfiguracji serwerów itp.

6. Wspólna autoryzacja i uwierzytelnianie: Wspólne mechanizmy autoryzacji i uwierzytelniania można zaimplementować na poziomie projektu, co ułatwia zarządzanie dostępem do różnych funkcji.

Jednakże, w przypadku bardziej rozległych projektów, w których różne części systemu są zupełnie niezależne i wymagają oddzielnych zasobów, niektóre firmy decydują się na stosowanie mikrousług (microservices). Każda mikrousługa jest wtedy oddzielnym projektem Django, co umożliwia niezależne rozwijanie, testowanie i wdrożenie poszczególnych części systemu.

Ostateczna decyzja zależy od konkretnej sytuacji, struktury biznesowej, wymagań projektu oraz preferencji zespołu programistycznego. Warto przemyśleć, jakie podejście najlepiej odpowiada specyfice danego projektu.

W Django, domyślnie korzysta się z jednej wspólnej tabeli użytkowników (`auth_user`) dla całego projektu, niezależnie od tego, ile aplikacji jest w nim zawartych. Wspólna tabela użytkowników jest zazwyczaj przechowywana w bazie danych i obsługiwana przez mechanizm uwierzytelniania Django.

Jednakże, w przypadku, gdy potrzebujesz dostosowanej logiki uwierzytelniania i chcesz, aby każda aplikacja miała swoje niezależne tabele użytkowników, możesz to zrealizować, implementując niestandardowy model użytkownika w każdej aplikacji.

Przykładowo, w pliku models.py danej aplikacji możesz zdefiniować niestandardowy model użytkownika:

from django.contrib.auth.models import AbstractUser
from django.db import models
 
class MyAppUser(AbstractUser):
    # dodatkowe pola dla niestandardowego modelu użytkownika
    custom_field = models.CharField(max_length=100)

Następnie, musisz skonfigurować Django, aby używał Twojego niestandardowego modelu użytkownika. W pliku settings.py projektu dodaj:

AUTH_USER_MODEL = 'myapp.MyAppUser'

Gdzie 'myapp' to nazwa Twojej aplikacji, a 'MyAppUser' to nazwa niestandardowego modelu użytkownika.

Ważne: Zmiana modelu użytkownika po utworzeniu bazy danych może być skomplikowana. Jeśli projekt jest już w zaawansowanym stadium, zmiana modelu użytkownika może wymagać manualnej modyfikacji bazy danych.

Pamiętaj, że taka konfiguracja wprowadza własną logikę uwierzytelniania dla każdej aplikacji, co oznacza, że użytkownicy z jednej aplikacji nie będą automatycznie miały dostępu do zasobów związanych z użytkownikami z innej aplikacji. To również wprowadza dodatkową odpowiedzialność za zarządzanie niestandardowymi modelami użytkowników, w tym ich migracjami i ewentualnymi aktualizacjami.

W Django, wybór metody obliczeń, czyli gdzie przetwarzać i przygotowywać dane, zależy od konkretnego kontekstu i specyfiki projektu. Django oferuje elastyczność w zakresie tego, gdzie i w jaki sposób przetwarzać dane. Poniżej przedstawiam kilka ogólnych zaleceń, ale ważne jest dostosowanie podejścia do wymagań i charakteru projektu.

1. Po stronie bazy danych:

• Wykonywanie obliczeń po stronie bazy danych może być efektywne, szczególnie gdy operacje są złożone i wymagają wykorzystania funkcji bazy danych. Django umożliwia korzystanie z funkcji F() i Q() w zapytaniach, co pozwala na delegowanie części obliczeń do bazy danych.
• Przykładowo, używanie funkcji agregujących, takich jak Count(), Sum(), Avg(), może być efektywne do uzyskiwania statystyk bezpośrednio z bazy danych.
• Jednak zbyt skomplikowane obliczenia mogą być trudne do zaimplementowania w czystym SQL, a wtedy lepszym rozwiązaniem może być pobranie surowych danych i przetwarzanie ich po stronie serwera Django.

2. W widokach (views):

• Przetwarzanie danych w widokach daje pełną kontrolę nad logiką biznesową i pozwala na dostosowywanie wyników zapytań z bazy danych przed przekazaniem ich do szablonu.
• W przypadku bardziej zaawansowanej logiki, takiej jak agregacja danych z różnych źródeł czy filtrowanie w zależności od kontekstu, przetwarzanie w widokach może być bardziej odpowiednie.

3. W szablonach (templates):

• Szablony są używane do prezentacji danych użytkownikowi, a niekoniecznie do przetwarzania ich w celu uzyskania nowych informacji.
• Jeśli przetwarzanie danych polega na transformacjach wizualnych czy formatowaniu, to szablony mogą być odpowiednim miejscem do takich operacji.
• Jednak w przypadku bardziej zaawansowanej logiki, zwłaszcza takiej, która nie jest bezpośrednio związana z prezentacją, warto rozważyć przeniesienie obliczeń do widoków.

Ostateczny wybór zależy od specyfiki projektu, wymagań funkcjonalnych, efektywności oraz czytelności kodu. Czasami optymalne rozwiązanie może polegać na kombinacji różnych podejść, w zależności od konkretnego przypadku użycia. Warto również pamiętać o zasadzie thin views, fat models zachęcającej do umieszczania jak największej ilości logiki biznesowej w warstwie modelu.

Zasada thin views, fat models to jedna z zasad programowania stosowanych w projektach opartych na architekturze Django. Ta zasada skupia się na rozdziale odpowiedzialności między widokami (views) a modelami w ramach wzorca projektowania MVC (Model-View-Controller), którego Django jest implementacją.

1. Thin Views (Chude Widoki):

• Zasada thin views oznacza, że widoki (views) powinny być „chude”, czyli powinny zawierać jak najmniej logiki biznesowej i przetwarzania danych.
• Widoki powinny skupiać się głównie na obsłudze żądań HTTP, pobieraniu danych z formularzy, przekierowywaniu użytkowników itp.
• Unikaj umieszczania zbyt dużej ilości kodu związanego z przetwarzaniem danych w widokach. Zamiast tego, deleguj tę odpowiedzialność do warstwy modelu.

2. Fat Models (Grube Modele):

• Zasada fat models oznacza, że modele (models) powinny być „grube”, czyli powinny zawierać jak najwięcej logiki biznesowej i operacji związanych z danymi.
• Modele powinny być miejscem, w którym umieszcza się funkcje związane z przetwarzaniem i walidacją danych, operacje na danych, oraz wszelkie inne funkcje biznesowe związane z encją modelu.
• Unikaj umieszczania w modelach logiki prezentacyjnej czy logiki obsługi żądań HTTP. Modele powinny skupić się na zarządzaniu danymi i biznesową logiką związaną z danymi.

Przykład w kontekście Django:

# Przykład "thin view"
from django.shortcuts import render
from .models import MyModel
 
def my_view(request):
    data = MyModel.objects.all()
    return render(request, 'my_template.html', {'data': data})
 
# Przykład "fat model"
from django.db import models
 
class MyModel(models.Model):
    name = models.CharField(max_length=100)
    description = models.TextField()
 
    def process_data(self):
        # Przetwarzanie danych, np. generowanie opisu na podstawie nazwy
        # Ta logika biznesowa powinna być umieszczona w modelu
        self.description = f"This is {self.name}."
        self.save()

W powyższym przykładzie widok (my_view) jest prosty i wykonuje podstawową operację pobrania danych z modelu. Z kolei logika biznesowa związana z przetwarzaniem danych została umieszczona w modelu (process_data).

Zasada thin views, fat models przyczynia się do lepszej czytelności kodu, łatwiejszego utrzymania i testowania, oraz zwiększa ponowne wykorzystanie kodu, ponieważ logika biznesowa jest skoncentrowana w warstwie modelu.