Kohana Framework: ORM

Kontynuując naszą Kohanową serię, dziś kolejny wpis. W poprzednim artykule poruszyliśmy kwestię podstawowej konfiguracji naszej aplikacji oraz pseudo systemu szablonów, poznaliśmy widoki i przygotowaliśmy się do dalszej przygody z Kohana Framework. Dzisiaj pójdziemy krok dalej, poznamy warstwę naszej aplikacji odpowiedzialną za komunikację z bazą danych.

ORM – Mapowanie obiektowo-relacyjne

Choć tytuł brzmi groźnie dla początkujących programistów uspokoję was. Nie ma się czego obawiać, ORM – bo tak brzmi skrót od tej długiej nazwy po angielsku to nic innego jak obiektowe odwzorowanie architektury naszej aplikacji na bazę danych, najczęściej relacyjną. W skrócie, dla każdej tabeli w bazie danych tworzymy zwyczajny model, który dziedziczy po klasie ORM. Ustawiając parametry modelu, zyskujemy pełną obsługę danych w tej tabeli w postaci dodawania, edytowania, usuwania, pobierania rekordów. ORM to odwzorowanie struktury tabel bazy danych na obiektowe klasy lub odwrotnie.

Ale po co komu ORM?

ORM powstało dawno temu, gdy wizjonerzy programowania obiektowego mieli plan zbudowania w pełni obiektowej struktury bazy danych, tak by można było w łatwy i szybki sposób operować na danych zgromadzonych na serwerach. Jest wielu entuzjastów tej techniki, przeciwników pewnie jeszcze więcej, głównie dlatego, że przez wielu programistów ORM uznawany jest za mało wydajną formę prezentacji danych. Tutaj trzeba się zgodzić, proste, klepane z palca zapytania są na pewno szybsze w wykonywaniu niż zapełnianie pamięci obiektami modeli, wykonywanie dynamicznych mapowań, zapytań itd.

Jest jednak jedna podstawowa zaleta w przypadku ORM – szybkość tworzenia. Trzeba też nadmienić, że mechanizmy ORM ewoluowały od czasów ich prototypów, nie wspominając już o przepaści jaką dzielą nowe systemy ORM takie jak: Doctrine, Propel od ORM zastosowanym w Kohana. Ten ostatni jest co prawda bardzo mały, prosty i zwinny, lecz nie do końca najlepiej wydajny. Głównie dlatego, że wymienieni przeze mnie Doctrine i Propel zapisują modele/encje wraz ze strukturą tabel oraz setterami i getterami. Ale mniejsza z tym, zajmijmy się naszą aplikacją!

Tworzymy pierwszy Model ORM

Czas utworzyć nasz pierwszy model ORM. Z racji, że w naszej bazie danych istnieje tylko jedna tabela pages utworzymy więc dla niej model. Należy pamiętać o konwencji nazewnictwa, zapewni nam porządek w projekcie i ułatwi komunikację miedzy relacjami.

Gdy chcemy w bazie danych utworzyć tabelę przechowującą strony CMS (strona z ang. „page”), tworzymy tabelę o nazwie zapisanej w liczbie mnogiej pages.
Model zaś w liczbie pojedynczej Page.php

Zmienna prywatna $_table_name określa nazwę tabeli w bazie danych. Jeśli zachowamy się zgodnie z konwencją nazewnictwa nie musimy dodawać tej adnotacji, ale dla pewności warto pozostawić. Zgodnie z funkcjami QueryBuildera mamy do dyspozycji mnóstwo pomocniczych narzędzi generujących wynik zapytania.

Przykład 1

Pobranie stron, których wartość kolumny „is_active” jest równa 1

To jest przykład, musimy mieć w tabeli kolumnę „is_active”.

 

Przykład 2

Pobranie maksymalnie 10 stron, których wartość kolumny „is_active” jest równa 1 oraz posortowanie ich od najnowszych.

Oczywiście biorąc pod uwagę, że w tabeli są takie kolumny jak: created_at, is_active.

 

Przykład 3

Pobranie stron, których wartość kolumny „category” jest równa „article” lub „page”.

Oczywiście biorąc pod uwagę, że w tabeli są takie kolumny jak: category.

 

Przykład 4

Pobranie strony o numerze ID równym 156 oraz pobranie strony w której wartość kolumny „slug” jest równa „nasza-oferta”.

Oczywiście biorąc pod uwagę, że w tabeli są takie kolumny jak: category.

Zapisywanie danych za pomocą ORM

Przedstawiam krótki instruktarz opisujący zapisywanie danych bezpośrednio do bazy danych za pomocą modelu ORM. W przykładzie wziąłem pod uwagę wymyślony model o nazwie Client oraz tabeli clients, która ma następujące kolumny:

  • id – to jest oczywiście klucz podstawowy tabeli, auto_increment, primary_key
  • name – varchar(255)
  • phone – varchar(100)
  • email – varchar(100)
  • city – varchar(100)

Zadanie 1: Dodaj do bazy danych nowego klienta: „Maciej Nowak”, o numerze telefonu: 332-058-212, adresie e-mail: maciej@nowak.tld, który mieszka we Wrocławiu

Zapisywanie danych możemy wykonać gdziekolwiek, tzn. możemy napisać do tego osobną funkcję, która zautomatyzuje nam ten proces, lub robić to w akcji kontrolera, operując na danych przesyłanych z formularza za pomocą POST – ale o tym innym razem.

Rozwiązanie zadania 1

Prawda, że proste? Tworzenie aplikacji przy użyciu modeli ORM jest wręcz błyskawiczne. W połączeniu z doświadczeniem, przestrzeganiem norm i standardów, wzorców, z pewnością efektem naszej pracy będzie dobrze napisana aplikacja.

Konkluzja

Dziś poznaliśmy podstawy zasady działania ORM, który w kolejnych wpisach będzie odgrywał kluczową rolę przy budowie naszej aplikacji. W kolejnym wpisie nauczymy się posługiwać relacjami modelu: jeden-do-jednego, jeden-do-wielu. Po omówieniu obsługi warstwy bazy danych, ORM przejdziemy do praktycznego kodowania naszego systemu CMS. Opierając się o zdobytą w tym kursie wiedzę, napiszemy przy wsparciu Kohanowego modułu ORM oraz Auth, prosty mechanizm autoryzacji użytkownika (rejestracja/logowanie), oraz przystąpimy do panelu dodawania podstron. To wszystko zrobimy właśnie w oparciu o ORM.

Zachęcam wszystkich do śledzenia źródeł tego tutoriala w serwisie Github.com

Programista, administrator - miłośnik nowych technologii. Jak każdy fachowiec w branży nie oprę się porannej kawie w towarzystwie świeżej prasy. Hobbystycznie fotografuję, psuję, naprawiam, lutuję. Czego nie lubię? Nieskromnych ludzi i brzydkiego kodu.

  • Filip Górny

    Kohana jest świetna dla początkujących i idealna na szybkie zrealizowanie prościejszych projektów. Niestety uczy bardzo złych praktyk co – widząc po sobie – trudno wykorzenić latami.

    Idealnym przykładem jest właśnie opisany ORM.

    • sbl

      ORM sam w sobie nie jest złym nawykiem 🙂 Kohanowy ORM jest słaby moim zdaniem. Do podstawowych zastosowań wystarcza, nie jest na pewno optymalny. Różnicę zobaczysz za jakiś czas, gdy skończę serię z Kohaną i zacznę z Symfony 2 (Doctrine/Propel).

      • Filip Górny

        Nie chodzi mi o ORM ale architekture całego modelu.
        Brak podziału na DTO/DAO prędziej czy później zaboli.
        Z Doctrine nie ma co tego cuda porównywać.

        • sbl

          Dlatego w tekście wspomniałem o wielkiej przepaści Kohanowego ORM a Doctrine/Propel.
          ORM zastosowany w Kohana jest proporcjonalny do jej możliwości 🙂 niczego dużego na KO się nie stawia.

          • Potfur

            Zdziwił byś się.

  • piotrooo

    Ten ORM z obiektami ma wspólną tylko nazwę.

  • Hm… nie mam i nie miałem w zasadzie styczności z frameworkami, ale po lekturze pewnej książki, miałem na to zupełnie inne widzenie – ręczne tworzenie schematów i dopiero generowanie klas (właśnie wspominane tu przez innych Doctrine czy Propel), no a tu jest wszystko „z automatu”. Niemniej z tego co widzę, to też nie musi być wcale takie dobre, więc nie będę się bezgranicznie zachwycał i poczekam na więcej informacji 🙂

    • sbl

      Automaty są złe i dobre. Ludzie mówią, że generowane settery,gettery,managery encji itd w Doctrine lub Propel przyspieszają pracę bo ogranicza się zbędne zapytania, zwalnia pamięć, wszystko szybciej działa itd. Musiałbyś się pobawić tym by samemu oszacować co jest dobre. W poniedziałek będzie kolejny wpis o ORM, relacje więc opiszę to trochę szerzej.

  • Pingback: Kohana Framework: ORM – relacje | webMASTAH()

  • Jordan

    Interesting article. Do you heard about ORM Designer (www.orm-desginer.com)? It works in combination with Doctrine or another ORM frameworks and its very useful for generating ORM definitions automatically and visualising data model. Have a look at it 😉

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL