Wiosna nadchodzi – sprzątamy w modelu

Odezwało się kilka głosów, iż sensowności wcielania w projekt Grailsowy rozwiązań opartych na Hibernate najtężsi filozofowie by się nie doszukali. Zgodnie zatem z zaleceniami czytelników bloga postanowiłem jasno rozgraniczyć Hibernate od rozwiązania oferowanego nam przez Grails – GORM.

W tym miejscu jeszcze tylko uprzedzę i przypomnę raz jeszcze, gdyż kilkunastokrotnie otrzymywałem mejle z pytaniami. Pisanie notek na blogu odbywa się równolegle z czytaniem odpowiedniej literatury (zarówno papierowej jak i online). Taką formułę bloga wybrałem dlatego, gdyż dopracowanych artykułów poświęconym konkretnym zagadnieniom w sieci można znaleźć masę. Najczęściej są one pisane przez praktyków, którzy daną technikę/technologię wykorzystują w codziennej pracy. Tym samym zapomnieli już dawno, z czym mieli problemy na początku. Dzięki mojemu podejściu (jednoczesnego pisania z poznawaniem omawianych zagadnień) z pewnością powtarzam się w niektórych miejsach, albo też piszę kod, który może pozostawiać sporo do życzenia. Ale to chyba najlepsza metoda nauki – obserwować popełniane błędy i wyciągać z nich wnioski. Dotyczy to zarówno mej skromnej osoby, jak i znacznego procenta czytelników.

Na początek może podstawowe wyjaśnienie – GORM to skrót od Grails Object-Relational Mapping. Pojęcie ORM myślę, że nie musi być rozjaśniane. Specyfiką rozwiązania zastosowanego we frameworku jest wykorzystanie sprawdzonego rozwiązania w tej dziedzinie jakim jest Hibernate z tym tylko, że w przypadku GORMa, framework po prostu wrappuje go w składnię groovy. Tak przynajmniej twierdzi mądra książka. W poprzednim wpisie chcąc, albo też nie chcąc zmieszałem te dwa rozwiązania (niepotrzebnie jak mi wskazano). Zatem bierzemy się za wiosenne porządki w kodzie.

Zaczniemy zatem od konfiguracji. GORM jest nadbudową na Hibernate, zatem proces konfiguracji jest w pełni obsługiwany przez mechanizmy frameworka. Czyli plik hibernate.cfg.xml jest zasadniczo niepotrzebny. Jedynym odnośnikiem dla korzystania z baz danych jest konfiguracyjny plik DataSource.groovy. Nie zmienił się on od czasu poprzedniego wpisu. Co więcej – zgodnie z radami komentujących poprzedni artykuł – wyrzuciłem katalogi z bibliotekami z folderu /lib i zostawiłem tam tylko connector do MySQLa (czysty plik JAR). Plik PreInit.groovy tym samym również poszedł w odstawkę.

Sam kod klas domenowych został rozszerzony poprzez jawne zadeklarowanie pola id, a także stworzenie konstruktora inicjalizującego wszystkie te wartości. To na pewno nie jest potrzebne!. Zmieniłem nazwę klasy na Htj_Links, dzięki czemu łatwiej będzie mi się orientować w kodzie (prefixy do nazw tabeli raczej nie ulegają zmianie). Kod mojej klasy domenowej po zmianach wygląda tak:

class Htj_Links {

static mapping = {
table 'htj_links'
id column: 'link_id'
}

String address;
String description;

I w kontrolerze (jakimkolwiek bądź) można sobie wklepać takie coś:

def lineczki = Htj_Links.list()
lineczki.each{ println(it.address) }

I na konsolce radosnie widac efekty wyciagniecia wszystkich elementów z bazy (słownie jednego testowego rekordu). Przyznaję jednakże – robi wrażenie. To tyle na razie – w następnym wpisie posprzątamy w kontrolerach i w widokach.

Advertisements

3 thoughts on “Wiosna nadchodzi – sprzątamy w modelu

  1. xis

    Cześć,
    Rzeczywiście GORM to świetny ułatwiacz życia 🙂 Jako uzupełnienie Twojego wpisu mogę dodać, że plik hibernate.cfg.xml niestety czasem jest jednak przydatny – (na szczęście w sytuacji wyjątkowej) gdy chcemy w naszej Grailsowej aplikacji Mwykorzystać “stare” encje javowego Hibernate.To już jednak wariacja i celowe “wyskakiwanie z ram” frameworku – jakkolwiek miłe jest, że grails umożliwia i to (w poprzednim wpisie pokazałeś, że nie tylko to).
    Pozdrawiam

  2. Mateusz

    Hmmm, ja bym zostawił nazwę klasy Links, skoro już definiujesz w mapping właściwość table. Jeśli natomiast chcesz, żeby klasa się nazywała Htj_Links i tabelka również, to już nie musisz tego dodatkowo definiować, Twoja klasa domenowa upraszcza się jeszcze trochę 🙂

    Dodatkowo w Grails panuje zasada “konwencja ponad konfigurację”. Jedną z konwencji jest nazywanie klucza głównego “id”, a klucza obcego “_id”. W przypadku Twojej klasy klucz główny wygląda teraz jak klucz obcy, co mogłoby zmylić kogoś, kto Twojej aplikacji będzie się przyglądał. Oczywiście nie jest to złe i jeśli potrzebujesz lub masz taką ochotę to możesz to dowolnie zmieniać – to jest właśnie duży plus, że można mieć nad wszystkim kontrolę.

    Bardzo fajnie ułożyły się te dwa posty 🙂 Doskonałe porównanie pełnej kontroli nad aplikacją, z najprostszą i najszybszą w implementacji wersją. Brawo 🙂

  3. chlebik Post author

    Co do nazwy klasy zgodzę się. Co do klucza głównego i obcych to tutaj ta konwencja troche mnie wkurza. Sam kiedyś pisałem (nieświadomie) aplikacje, gdzie główny klucz zawsze nazywał się ID. Problem w tym, że po kilku JOINach trudno już potem dojść z jakiej tabeli ID oznacza ID w zwróconym wyniku. Stąd przyjęta (choćby u mnie w zespole) konwencja, iż wszystkie klucze główne mają strukturę np: ZAMÓWIENIE_ID, PRODUKT_ID. Tak z pewnością działa to w PHP, kiedy tworzy się jawnie obiekty z wartości pobranych z bazy – ORMy czy GORM w szczególności zwracają już wtedy gotowy obiekt opakowany w metody i tak dalej, zatem i może nie jest to za bardzo konieczne (jawne deklarowanie LINK_ID). Jednakże przyzywczajenie robi swoje, no i też często buduje się aplikację na zastanej już bazie – i dobrze jest wiedzieć jak sobie potencjalnie z tym poradzić.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s