wtorek, 9 października 2012

ORM - "The Vietnam of Computer Science"

...cytat Teda Newarda rozbawił mnie szczerze - ale to śmiech przez łzy. Martin Fowler natomiast pyta: Ale co w zamian?

Możemy uciec się do rozwiązań typu Datoms (Encja, Atrybut, Wartość, Timestamp) lub bardziej "semantycznego" Event Sorcingu.

Jednak są to rozwiązania specyficznych klas problemów (podróże w czasie, wektory uczące dla Sztucznych Sieci Neuronowych) lub problemów skali Googl/Twitter/Facebbok - mimo, że nie pracujemy w tych firmach, to lubimy się na nie powoływać w swych elaboratach architektonicznych:)

Natomiast w typowych systemach biznesowych wystarczy przyjęcie prostych i racjonalnych zasad doboru odpowiedniego młotka do odpowiedniej klasy problemu:
  • Obiekty persystentne to Agregaty, których granice są wyznaczane wg dobrych praktyk DDD: np. modelowanie niezmienników oraz modelowanie jednostki zmiany biznesowej
  • Do persystencji Agregatów używamy ORM, ponieważ dobrze zakreślone granice agregatów (w tym unikanie zbędnych połączeń) rozwiązują większość problemów
  • Do wydajnego odczytu danych przekrojowych nie używamy ORM - nie służą do tego typu zadań 
Proste, łatwe i... przyjemne:)
W razie problemów z wydajnością warto spróbować różnych form separacji z podejścia: Command-query Responsibility Segregation.

//==========================

Więcej w archiwalnym poście, natomiast rozwinięcie w najbliższym numerze programistamag.pl



6 komentarzy:

Michał Bartyzel pisze...

A jak widzisz w kontekście tego wpisu swój komentarz do tego posta http://mbartyzel.blogspot.com/2011/03/po-co-orm.html ?

Sławek Sobótka pisze...

Z CRUDEami jest prosta sytuacja, więc podtrzymuję.

Natomiast przy złożonych domenach problemy, o których pisałem - wynikające z LazyLoadingu i Operacji Kaskadowych można zniwelować/zredukować dzięki:
- CqRS - bo odczyt wartości to inna "bajka" operowanie na "miejscach" danych
- Dobrej definicji Agregatu - aby nie naciąć się na sytuację gdy opóźnione pobranie danych zwróci nam stan z innego momentu w czasie niz moment pobrania Agregatu

ikioloak pisze...

A co sądzisz o bazach dokumentowych jak MongoDB? Czy nie wydaje się bardziej naturalne dla zapisywaniu agregatów w formie dokumentu niż rozstrzelonego na dziesiątki tabel? Fowler obecnie zdaje się że proponuje to rozwiązanie jako bardzo rozsądne.

Sławek Sobótka pisze...

Osobiście nie mam tutaj doświadczenia produkcyjnego (z Mongo), ale jeżeli Agregat (jego granica) jest zaprojektowany zgodnie z DDD, to jak najbardziej ma to sens. A "rozstrzelanie na dziesiątki tabel" nie dość, że traci sens, to jeszcze sprawia pewne przykre problemy związane ze spójnością danych gdy używamy Lazy Lodingu. Napiszę o tym posta we wtorek/środę.

Natomiast jeżeli chodzi o wyszukiwanie, to i tak jeżeli chcemy osiągnąć wydajność, to read model jest zwykle nieodzowny.

Paweł Kaczor pisze...

Bazy NoSQL jak najbardziej nadają się do przechowywania agregatów: http://martinfowler.com/bliki/AggregateOrientedDatabase.html

Tomasz Skutnik pisze...

<disclaimer>
Dewelopuję i sprzedaję produkt konkurencyjny dla Hibernate.
</disclaimer>

Zgadzam się z Tedem Newardem. ORM (w sensie Hibernate/TopLink/JPA) to Wietnam. Większość młodych chłopców nie wraca, a Ci co przeżyli cierpią na PTSD. Na głos popierają a po cichu, gdzie tylko się da używają Spring JDBC Template i tym podobnych.

Podoba mi się też metafora młotka. Można wtedy dobrać sobie najlepsze narzędzie do problemu. W systemach biznesowych relacyjna baza danych, nie oszukujmy się, to jednak "must be".

Nasze (programistów) dyskusje wciąż krążą wokół tematu "Chciałbym mieć coś pozbawionego wad Hibernate/JPA/TopLink, ale nie mam nic w zamian. Nie będę przecież pisać całego systemu w czystym SQL/JDBC." Wszystkie te burzliwe dyskusje rozpalają się i gasną regularnie bo wszyscy wciąż szukają alternatywy.

<reklama>
Ale, kto szuka ten znajduje :)
</reklama>