Różnice

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

--- pl:python:django [2023/12/02 12:51] – [Gdzie przetwarzać i przygotowywać dane?] 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 121: / Linia 123: @@
 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.