Warte uwagi: DataMapper

O DataMapperze, czyli ORM w Rubym, zaczęło być głośno przy okazji Merba. Mogłoby się wydawać, że ogłoszenie połączenia Railsów z Merbem, sprawi, że DataMapper przestanie być rozwijany. Tak się jednak nie stało i stał się on chyba drugim po ActiveRecordzie ORMem w Rubiowym środowskiu. W trakcie tegorocznego RailsConf została opublikowania wersja 1.0.

Przecież jest już ActiveRecord

Po co nam DataMapper? Po pierwsze oczywiście można ograniczyć się do stwierdzenia, że konkurencja jest dobra i wymusza rozwój. Ale kilka konkretnych cech, które mogą zachęcić do przyjrzenia się mu bliżej to:

  • Jeden rekord = jeden obiekt – każdy rekord w tabeli jest reprezentowany przed tylko jeden obiekt. Pozwala to na zwiększenie szybkości i oszczędza pamięć.
  • Czysty Rubynie da się używać SQL’a w DataMapperze, wszystko jest pisane w Rubym. Chroni to przed nadużywaniem zapytań SQL i daje większą niezależność od konkretnej bazy danych. Mimo, że można pisać SQL’owe zapytania, to twórcy uważają, że dostarczone helpery sprawiają, że w większości przypadków nie jest to konieczne.
  • Adaptery – nie jest wymagane korzystanie z relacyjnej bazy danych. Istnieje ponad 40 adapterów, umożliwiających podłączenie DataMappera między innymi do CouchDB, YAMLa, CVS, Sphinxa, albo np API google video.
  • Kolumny definiowane jawnie – wszystkie kolumny należy zdefiniować w modelu. Na pierwszy rzut oka wydaje się to niepotrzebnym wysiłkiem, ale dzięki temu znika ActiveRecordowa “magia” i wszystkie pola są od razu widoczne. Nie ma również potrzeba pisać migracji, wystarczy użyć metody auto_migrate, a baza zostanie uaktualniona do wersji przechowywanej w modelach.
  • Domyślne opóźnione ładowanie (lazy loading) – rekordy ładowane są w tle dopiero w momencie, gdy wymagany jest do nich dostęp, pozwala to DataMapperowi na zwiększanie wydajności, poprzez zastosowanie prostych reguł. Na przykład dzięki temu poniższa linijka wykona tylko dwa zapytania, niezależnie od tego ile rekordów jest w bazie.
 Zoo.all.each { |zoo| zoo.exhibits.to_a }

Oczywiście punkty te można potraktować zarówno jako wady i zalety, zależy czego oczekujemy od ORMa. Ale jeśli jeszcze nie jesteście przekonani by spróbować, można zajrzeć na stronę Why DataMapper.

Jak wypróbować?

Najprościej po prostu zacząć od przewodnika na oficjalnej stronie. Miłej zabawy.



Komentarze

  1. Comment Arrow

    W Rails 3, ActiveRecord też posiada opóźnione ładowanie. Ma także, skopiowaną z Sequela, bardzo wygodną metodę .to_sql() pozwalającą na podejrzenie generowanego SQL’a bez żadnego łączenia się z bazą.

    Migracje to nie tylko aktualizacja struktury tabel. Można także dokonywać innych operacji, z ładowaniem danych włącznie. I ważne, że można je wykonywać w określonej kolejności. W sumie chodzi o taką modyfikację bazy aby nie zniszczyć wcześniejszych danych.

    Adaptery do DataMappera to dobra rzecz, ale ActiveRecord ma prawie to samo tylko że w pluginach. Co daje taki sam dostęp do CouchDB, MongoDB, Sphinxa czy Solra.

    No i najważniejsze, że ActiveRecord jest częścią frameworka a nie zewnętrzną biblioteką. To jest duża zaleta, bo już nie raz można było widzieć, jak zewnętrzne pluginy są opóźnione z kompatybilnością z najnowszymi zmianami we frameworku.




O autorze

Aleksander Dąbrowski

Od 2008 zawodowo programuje w Ruby i Railsach. Jest maniakiem prostych i eleganckich rozwiązań, nie boi się usuwania brzydkiego kodu. Uwielbia dzielić się wiedzą, a w wolnych chwilach naprawia samochody.