Kapownik - Piotr Sinda

Ta strona jest tylko do odczytu. Możesz wyświetlić źródła tej strony ale nie możesz ich zmienić.
====== Django ======

  * Przykład aplikacji [[:pl:python:dbaudiocd|DBAudioCD]]
  * Typy pól w modelach [[:pl:python:fieldsinmodel|Typy pól]]
  * Opcje pól w modelach [[:pl:python:optionsfields|Opcje pól]]
  * Opcje Meta [[:pl:python:meta|Meta ogólnie]]
  * Opcje [[:pl:python:metawmodelach|Meta w modelach]]
  * [[:pl:python:metawforms|Opcje Meta w formularzach]]
  * [[:pl:python:views|O widokach ogólnie]]
  * [[:pl:python:importmdb2models|Import danych z bazy MS Access]]
  * [[:pl:python:serwerdjango|Serwer Django]]
===== Wiele aplikacji w jednym projekcie czy każda w osobnym projekcie? =====

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.

===== Czy dany projekt Django musi mieć wspólną tabele uzytkowników? =====

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:\\

<code python>
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)
</code>

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

<code python>
AUTH_USER_MODEL = 'myapp.MyAppUser'
</code>

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.

===== Gdzie przetwarzać i przygotowywać dane? =====

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" =====

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:

<code python>
# 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()
</code>

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.

===== Czasem nie wszystko da się wykonać po stronie modeli =====

Choć zasada ''thin views, fat models'' sugeruje umieszczanie jak największej ilości logiki biznesowej po stronie modeli, istnieją sytuacje, w których przetwarzanie danych nie da się wykonać w warstwie modelu. Oto kilka scenariuszy, w których może to być zalecane:

1. **Interakcje między wieloma modelami:**
  * Jeśli operacja wymaga współpracy i interakcji między wieloma modelami, może być bardziej odpowiednie umieszczenie logiki w warstwie widoku. Widok będzie odpowiedzialny za koordynację i zarządzanie operacjami, które dotyczą różnych modeli.

2. **Operacje związane z formularzami i danymi wejściowymi:**
  * Logika obsługi formularzy, walidacja danych wejściowych, oraz związane z nimi operacje (np. zapis do bazy danych) zazwyczaj znajdują się w warstwie widoku. To dlatego, że dane wejściowe użytkownika są bezpośrednio związane z operacjami w warstwie prezentacji.

3. **Złożone operacje biznesowe:**
  * Jeśli operacja biznesowa jest zbyt skomplikowana lub nie może być łatwo przedstawiona jako jedna akcja na jednym modelu, może to sugerować umieszczenie logiki w warstwie widoku. Na przykład, gdy operacja obejmuje kilka etapów lub interakcji z zewnętrznymi serwisami.

4. **Operacje na żądaniach HTTP:**
  * Jeżeli operacje wymagające przetwarzania danych są bezpośrednio związane z żądaniami HTTP, takie jak analiza nagłówków, manipulacje związane z sesją, czy obsługa różnych metod HTTP, to jest to właściwe miejsce do umieszczania tej logiki.

5. **Optymalizacje wydajnościowe:**
  * W niektórych przypadkach, przetwarzanie danych w warstwie modelu może prowadzić do nieoptymalnego kodu, zwłaszcza jeśli operacje te są kosztowne pod względem zasobów. W takich przypadkach optymalizacje wydajnościowe mogą wymagać umieszczenia logiki w warstwie widoku, gdzie dostępne są narzędzia do kontroli przepływu i zarządzania zasobami.

Pamiętaj, że ostateczna decyzja o umieszczeniu logiki w warstwie modelu czy widoku zależy od konkretnego kontekstu projektu i wymagań funkcjonalnych. Ważne jest zachowanie zasady czytelności kodu i unikanie nadmiernego rozbijania kodu, co mogłoby utrudnić zrozumienie i utrzymanie systemu.

===== Warto wspomnieć o innych zasadach: =====

W programowaniu w Django istnieje kilka innych zasad i praktyk, które są powszechnie stosowane w celu zachowania czytelności kodu, zwiększenia elastyczności systemu oraz ułatwienia utrzymania. Oto kilka z nich:

==== 1. DRY (Don't Repeat Yourself) ====

  * Zasada DRY nakazuje unikanie powtarzania tego samego kodu. Jeśli pewna funkcjonalność występuje w wielu miejscach, warto ją zrefaktorować do jednego miejsca, aby zmniejszyć ryzyko błędów, ułatwić utrzymanie i uniknąć redundancji.

==== 2. Fat URLs, Thin Views ====

  * Zasada ta podkreśla, aby unikać zbyt rozbudowanych adresów URL i przenosić logikę związaną z analizą adresów URL do widoków. Adresy URL powinny być przejrzyste i jednoznaczne, a złożone operacje powinny być obsługiwane w warstwie widoku.

==== 3. Separacja obowiązków (Separation of Concerns) ====

  * Rozdzielanie odpowiedzialności pomiędzy różne komponenty systemu. Modele powinny zajmować się danymi i logiką biznesową, widoki obsługą żądań HTTP i przetwarzaniem danych, a szablony prezentacją. To pomaga w utrzymaniu klarowności i modularności kodu.

==== 4. KISS (Keep It Simple, Stupid) ====

  * Zasada KISS sugeruje, że rozwiązania powinny być jak najprostsze. Unikaj nadmiernego skomplikowania kodu, jeśli nie jest to konieczne. Prosta implementacja jest łatwiejsza do zrozumienia i utrzymania.

==== 5. Consistent Naming Conventions ====

  * Konsekwentne stosowanie konwencji nazewniczych. Nazwy klas, funkcji, zmiennych i innych elementów kodu powinny być nazywane zgodnie z przyjętymi konwencjami. W Django stosuje się zasady PEP 8.

==== 6. Aplikacje jako niezależne komponenty ====

  * Tworzenie aplikacji Django jako niezależnych, wielokrotnie używanych komponentów, które można ponownie wykorzystać w innych projektach. Każda aplikacja powinna mieć jasno zdefiniowany zakres funkcjonalny.

==== 7. Test-Driven Development (TDD) ====

  * Praktyka polegająca na tworzeniu testów jednostkowych przed napisaniem właściwej implementacji. TDD może pomóc w zwiększeniu jakości kodu i ułatwieniu utrzymania.

==== 8. Zasada Atomic Design w szablonach ====

  * Stosowanie zasady Atomic Design do projektowania szablonów. Podział szablonów na atomowe komponenty (np. button, form, input) ułatwia budowanie spójnych interfejsów.

==== 9. Optymalizacje wydajnościowe ====

  * Rozważanie optymalizacji wydajnościowej kodu, szczególnie w obszarach, które mają wpływ na szybkość odpowiedzi aplikacji. Użycie cache, optymalizacja zapytań do bazy danych, czy stosowanie indeksów to przykłady praktyk mających na celu poprawę wydajności.

Zasady te są ogólnymi wytycznymi, a ich zastosowanie zależy od konkretnego kontekstu projektu. Optymalny wybór zasad zależy od charakterystyki projektu, zespołu programistycznego oraz wymagań biznesowych.