Różnice

Różnice między wybraną wersją a wersją aktualną.

--- pl:python:django [2023/12/01 07:48] – [Wiele aplikacji w jednym projekcie czy każda w osobnym projekcie?] sindap
+++ pl:python:django [2023/12/22 20:36] (aktualna) – [Django] sindap
@@ Linia 6: / Linia 6: @@
   * Opcje Meta [[:pl:python:meta|Meta ogólnie]]
   * Opcje [[:pl:python:metawmodelach|Meta w modelach]]
-  * Opcje [[:pl:python:metawforms|Meta w formularzach]]
+  * [[: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? =====
@@ Linia 58: / Linia 60: @@
 \\
 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.
+. **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.
+. **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.
+. **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ą.
+. **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.
+. **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:
+. **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.
+. **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.
+. **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.
+. **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.
+. **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.