Kapownik - Piotr Sinda

Narzędzia użytkownika

Narzędzia witryny

Ślad: • django
pl:python:django

Różnice

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

Odnośnik do tego porównania

Poprzednia rewizja po obu stronachPoprzednia wersja
Nowa wersja		Poprzednia wersja
pl:python:django [2023/12/02 12:46] – [Gdzie przetwarzać i przygotowywać dane?] sindappl:python:django [2023/12/22 20:36] (aktualna) – [Django] sindap
Linia 6: Linia 6:
   * Opcje Meta [[:pl:python:meta|Meta ogólnie]]   * Opcje Meta [[:pl:python:meta|Meta ogólnie]]
   * Opcje [[:pl:python:metawmodelach|Meta w modelach]]   * 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? ===== ===== Wiele aplikacji w jednym projekcie czy każda w osobnym projekcie? =====
  
Linia 79: Linia 81:
 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. 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.
pl/python/django.1701517577.txt.gz · ostatnio zmienione: przez sindap
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki