Które ORMy obsługują style przepływu pracy

Question

Pracowałem z kilkoma różnymi ORMami w kilku różnych językach - Wydaje się, że nie ma zgody co do tego, jaki rodzaj źródła powinien być źródłem i jaki powinien być wygenerowany .

Rozważ te thingies:

• jednostki: zwykły stary obiekt. Robi rzeczy .
• Mapper: Obiekt, który tworzy encję z DB lub utrzymuje ją ponownie.
• Tabela: Tabela bazy danych.
• Model: Oddzielny model opisujący obiekt streszczenie thingy.
• Okablowanie: A opis powiązania części tabeli i obiektu .

To daje nam te style workflow:

• model napędzany: Piszesz modelu, a żywa, Mapper i Tabela są generowane.
• Entity Driven: Napiszesz klasę, a Mapper i Table zostaną wygenerowane.
• Sterowanie za pomocą tabeli: Tworzysz tabelę, a encja i mapper są generowane.
• Podłączenie: Piszesz Class, Table i Okablowanie, generowany jest Mapper.

na pytania:

• Czy istnieje inny styl ja nie zauważył?
• Które ORMy wspierają jakie style?
• Czy istnieje standardowe słownictwo do tego? (I po prostu składa się z powyższym.)

Answer 1

Z tego co widziałem do tej pory, za pomocą .NET Entity Framework obsługuje wszystkie powyższe i NHibernate obsługuje co określają jako modelowego, Entity-Driven i Podłączenie (bez korzystania z dodatkowych bibliotek zewnętrznych).

NHibernate to port Hibernate języka Java, więc zakładam, że obsługują te same przepływy.

Answer 2

Popularny aktywny wzór rekordu nie ma pełnego okablowania i złożoności mapowania. Klasa modelu implementuje rekordy wierszy bezpośrednio za pomocą metod wymieszania i metod domenowych.

W bibliotece ActiveRecord biblioteki Ruby on Rails sama klasa działa również jako model dla tabeli, z metodami klasy find() itp. Tak więc zazwyczaj pisze się tylko jedną klasę na tabelę.

Ruby AR odzwierciedla na stole dynamicznie (do nazwy tabeli, nazwy kolumn i typów), więc następujące wystarczy po utworzeniu schematu bazy danych w jakiś sposób:

class MyTable << ActiveRecord::Base; end 

row = MyTable.find(7) 
row.my_column1 = "foo" 
row.save() 

http://ar.rubyonrails.org/

Answer 3

Przepraszam, jeśli to może być trochę nie na temat, ale jest zbyt duży, aby zmieścić się w komentarzu, więc ostrzegaj z wyprzedzeniem, jeśli inni nie sądzą, że pomoże to tematowi, że go usunę.

Kluczowym pytaniem jest, czy ty i twoja aplikacja właścicielem i są tylko klient że accesess bazy danych.

Jeśli potrzebujesz obejść istniejącą bazę danych, to poza blokiem generowanie bazy danych z modelu prawdopodobnie nie wchodzi w grę.

Jeśli zostanie utworzony przez twój system, będzie dostępny dla innych systemów (co oznacza, że ​​nie możesz po prostu zmienić losowo bazy danych, aby wdrożyć logikę, lub nawet bardziej ekstremalnie, inne pola/tabele mogą zostać dodane do ułatwienia Aplikacje innych producentów), należy zastanowić się nad tym, jakie przepływy pracy pozwolą na wyodrębnienie szczegółów bazy danych ze swojej implementacji, aby zapobiec konieczności dokonywania większych przeróbek.

Wymagania te mogą ulec zmianie przez cały okres eksploatacji projektów, ponieważ możesz zacząć jako jedyny konsument, a w przyszłości inne aplikacje mogą uzyskiwać bezpośredni dostęp do tej samej bazy danych. Może to być miejsce, w którym masz przepływ pracy "Entity Based", jak go nazywasz, gdzie masz warstwę, która reprezentuje rzeczywiste tabele DB, a modele, które reprezentują twoje dane używane w twoim systemie, są pobierane z wszelkich zmian do tych.

Czasami potrzeby ulegają zmianie, dlatego ORM i przepływ pracy, których używasz, powinny być uważne i przynajmniej częściowo zdolne do przetrwania w przyszłości, która może być poza twoimi rękami. Wyobraź sobie otoczenie przedsiębiorstwa (aka politycznego). Pewnego dnia pojawia się DBA i mówi: "cały dostęp do danych jest teraz przez SPROC". Tego typu sytuacje popychają Cię do "mapowania", jak to nazwałeś.