Dlaczego DataMapper korzysta z mixinów a dziedziczenia?

Question

Więc jestem po prostu ciekawy temat to:

DataMapper używa mixin dla swoich modeli

class Post 
    include DataMapper::Resource 

Podczas gdy aktywny rekord używa dziedziczenie

class Post < ActiveRecord::Base 

Czy ktoś wie, dlaczego zdecydował się zrobić DataMapper w ten sposób (lub dlaczego AR zdecydował się nie)?

Answer 1

Myślę, że chodzi o to, że ActiveRecord uważa, że ​​aspekt bazy danych jest kluczową cechą klasy modelu, więc dziedziczy to zachowanie. DataMapper wygląda tak, jakby uważał, że baza danych jest poparta, aby być tylko aspektem klasy, którą można dodać do klasy.

To moje przypuszczenie. Yehuda Katz może powiedzieć ci definitywnie.

Answer 2

Umożliwia dziedziczenie z innej klasy, która nie jest klasą DM.

Umożliwia także dodawanie funkcji DM do klasy w locie. Oto metoda klasy z modułu Pracuję teraz:

def datamapper_class 
    klass = self.dup 
    klass.send(:include, DataMapper::Resource) 
    klass.storage_names[:default] = @table_name 
    klass.property(:id, DataMapper::Types::Serial) 
    klass.property(:created_at, DateTime, :nullable => false) 
    klass.property(:updated_at, DateTime, :nullable => false) 
    columns_with_types { |n, t| klass.property(n, t, :field => n.to_s) } 
    klass 
end 

To pozwala mi wziąć udział w zajęciach SAXMachine (bardzo lekkie) i przekształcić go w klasie DataMapper w locie, i zrobić DataMappery rzeczy z nim . Mógłbyś to zrobić nawet do pojedynczej klasy obiektu.

Lubię wyobrażać sobie, że obniża to mój ślad pamięci podczas importowania obiektów 100K z XML (nie używam DM do masowego importu) i mieszam tylko w bardziej złożonych funkcjach baz danych, kiedy ich potrzebuję

Answer 3

To jest naprawdę kwestia wyboru dziedziczenia kontra Kompozycja.

Ja osobiście faworyzuję kompozycję, która wydaje się być bardziej naturalnym sposobem konstruowania klas i obiektów.

Skład daje większą kontrolę nad zachowaniami, które chcesz uwzględnić w klasie. Jeśli chodzi o dziedziczenie, dostajesz wszystko lub nic. Kompozycja pozwala czipie wybrać pożądane zachowania.

Answer 4

Wzorzec DataMapper ma zapewniać warstwę, która umożliwia oderwanie modelu obiektu domeny od schematu. ActiveRecord ujednolica model obiektu i relacyjną strukturę bazy danych.

za Martin Fowler:

Obiekty i relacyjnych baz danych mają różne mechanizmy danych strukturę. Wiele części obiektu, takich jak kolekcje i dziedziczenie, nie występuje w relacyjnych bazach danych. Podczas budowania modelu obiektowego z dużą logiką biznesową warto korzystać z tych mechanizmów, aby lepiej organizować dane i zachowania, które się z nimi wiążą. Prowadzi to do wariantów schematów; to znaczy, że schemat obiektu i schemat relacyjny nie pasują do siebie.

Nadal trzeba przesyłać dane między dwoma schematami, a transfer danych staje się sam w sobie złożony. Jeśli obiekty znajdujące się w pamięci wiedzą o relacyjnej strukturze bazy danych, zmiany w jednym mają tendencję do marszczenia się do drugiej.

Mapowanie danych to warstwa oprogramowania, która oddziela obiekty znajdujące się w pamięci od bazy danych. Jego obowiązkiem jest przekazywanie danych między nimi, a także izolowanie ich od siebie. Z Data Mapper obiekty w pamięci nie muszą nawet wiedzieć, że istnieje baza danych; nie potrzebują kodu interfejsu SQL, a na pewno nie znają schematu bazy danych. (Schemat bazy danych jest zawsze nieświadomy obiektów, które go używają.) Ponieważ jest to forma Mappera (473), sam program Data Mapper jest nawet nieznany dla warstwy domeny.

Answer 5

ActiveRecord nie powinien naprawdę używać dziedziczenia, ale powinien zawierać moduł dodający zachowanie (głównie trwałość) do modelu/klasy. ActiveRecord używa po prostu niewłaściwego paradygmatu!

Z tego samego powodu bardzo podoba mi się MongoId nad MongoMapper, ponieważ pozostawia deweloperowi szansę wykorzystania dziedziczenia jako sposobu modelowania czegoś znaczącego w domenie problemu.

To smutne, że prawie nikt w społeczności Railsów nie używa "Dziedziczenia Rubinowego" w sposób, w jaki powinien być używany - do definiowania hierarchii klas, a nie tylko do dodawania zachowania.