Różnice

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

--- pl:python:django [2023/12/02 12:54] – [Zasada "thin views, fat models"] 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 142: / Linia 144: @@
 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.